נדרשים עדכונים כדי לתקן את הפגיעה באבטחה של אישור eMudhra

ב-19 באוקטובר 2026, Google גילתה שרשות אישורים (eMudhra) נפרצה. כדי לטפל בבעיית האבטחה הזו, פרסמנו מיד תיקוני אבטחה לכמה תחומים בסביבה העסקית שלנו.

בדף הזה מוסבר אילו סוגי אפליקציות מושפעים מהפריצה לאישור של eMudhra ומה צריך לעשות כדי לטפל בבעיה. אנחנו מספקים גם מידע מפורט על בעיית האבטחה.

סוגי האפליקציות שמושפעים מהשינוי והפעולות הנדרשות

בגלל אופי הבעיה, היא השפיעה על הרבה סוגים שונים של אפליקציות. אם סוג האפליקציה שלכם מופיע כאן, סביר להניח שהיא הושפעה מהבעיה. כדי לדעת מה צריך לעשות, קראו את הקטע הרלוונטי.

גם פלטפורמות אחרות שנתמכות על ידי הקהילה מושפעות (לדוגמה, אפליקציות React Native שמטרגטות פלטפורמות של אפל ומשתמשות ב-Firestore).

אפליקציות Flutter

אפליקציות Flutter הושפעו בדרכים שונות. כדי להבין אילו פעולות צריך לבצע, קראו את הקטע הרלוונטי.

אפליקציות Flutter שמטרגטות ל-Android, ל-Windows או ל-Linux

דפדפנים ומערכות הפעלה דחפו רשימות חסימה של אישורי ביניים במקרי חירום, אבל dart:io ב-Android, ב-Windows וב-Linux מאמת שרשראות של אישורי TLS באמצעות מנוע BoringSSL משלו, ולא קורא רשימות חסימה של אישורי ביניים של מערכת ההפעלה. מידע נוסף על ייעוץ האבטחה הזה

אם יש לכם אפליקציות Flutter או Dart שמטרגטות את Android, ‏Windows או Linux, בצעו את הפעולות הבאות:

  1. משדרגים לגרסאות הבאות של Dart ו-Flutter:

    • ‫Dart 3.13.7 ואילך
    • ‫Flutter בגרסה 3.47.8 ואילך (עם Dart בגרסה 3.13.7 ואילך)

  2. בונים מחדש את האפליקציה.

  3. פורסים מחדש את האפליקציה או את הקובץ הבינארי. פורסים מחדש את האפליקציות או הקבצים הבינאריים של Android, ‏ Windows ו-Linux, כדי שיכללו את העדכונים עם תיקון האבטחה.

אפליקציות Flutter שמטרגטות פלטפורמות של אפל או של Windows וגם משתמשות ב-Cloud Firestore

אם יש לכם אפליקציית Flutter שמטרגטת פלטפורמות של אפל (לדוגמה, iOS) והאפליקציה משתמשת ב-Cloud Firestore, אתם צריכים לבצע את הפעולות הבאות:

  1. קובעים את גרסת הפלאגין שמתאימה לאפליקציה. בהתאם לגרסת הפלאגין הנוכחית, בוחרים גרסת פלאגין שמתאימה לאפליקציה.

    ‫פלאגין FlutterFire‏ (flutterfire) – iOS, ‏macOS או Windows

    גרסאות הפלאגין המושפעות גרסאות הפלאגין עם תיקון האבטחה
    ‫cloud_firestore 7.0.0 וגרסאות קודמות
    (לא כולל 6.10.1 ו-6.10.2)
    • אפשרות 1: cloud_firestore 7.1.0 (FlutterFire BoM 5.1.0 ואילך)
    • אפשרות 2:
      • ‫iOS ו-macOS: ‏cloud_firestore 6.10.1 (FlutterFire BoM 4.20.1)
      • ‫Windows: ‏ cloud_firestore 6.10.2 (FlutterFire BoM 4.20.2)

  2. מעדכנים את האפליקציה. מריצים את flutter pub upgrade כדי לעדכן את הפלאגין cloud_firestore לגרסה הרצויה.

  3. בונים מחדש את האפליקציה.

  4. מפרסמים מחדש את האפליקציה. מפרסמים מחדש את האפליקציה עם גרסת ה-SDK המעודכנת (לדוגמה, ב-App Store של אפל או בערוצי ההפצה למחשב).

אחרי שמפרסמים מחדש את האפליקציה, צריך לעודד את משתמשי הקצה לעדכן לגרסה העדכנית של האפליקציה. מכיוון שחבילת אישורי הבסיס של TLS מקומפלת לתוך הקובץ הבינארי של האפליקציה, עדכוני מערכת ההפעלה או שינויים בצד השרת לבדם לא מתקנים גרסאות build של אפליקציות שהותקנו בעבר.


אפליקציות לפלטפורמות של אפל (מותאמות) שמשתמשות ב-Cloud Firestore

אם יש לכם אפליקציה מקורית לפלטפורמות של אפל (לדוגמה, iOS) והאפליקציה משתמשת ב-Cloud Firestore, בצעו את הפעולות הבאות:

  1. קובעים את גרסת ה-SDK שמתאימה לאפליקציה. בהתאם לגרסת ה-SDK הנוכחית, בוחרים גרסת SDK שמתאימה לאפליקציה.

    ‫SDK של Firebase ל-Apple פלטפורמות (ספציפית, FirebaseFirestore)

    גרסאות ה-SDK המושפעות גרסאות SDK עם תיקון האבטחה
    ‫13.1.0 וגרסאות קודמות
    (לא כולל 12.19.3)
    • אפשרות 1: 13.1.1 ואילך
    • אפשרות 2: 12.19.3

  2. מעדכנים את האפליקציה. פועלים לפי ההוראות של ערוץ ההפצה:

    • ‫SPM: מעדכנים את גרסת יחסי התלות של החבילה firebase-ios-sdk ב-Xcode או ב-Package.swift.

    • הפצה של קובץ ZIP: מורידים את Firebase.zip לגרסה הרצויה מ-GitHub Releases ומחליפים את החבילות הקיימות של .xcframework בפרויקט.

    • ‫Carthage: מעדכנים את ה-Cartfile כך שיטרגט את הגרסה הרצויה, ומעדכנים את יחסי התלות דרך Carthage.

  3. מפרסמים מחדש את האפליקציה. מפרסמים מחדש את האפליקציה עם גרסת ה-SDK המעודכנת (לדוגמה, ב-App Store של אפל או בערוצי ההפצה למחשב).

אחרי שתפרסמו מחדש את האפליקציה, תצטרכו לעודד את משתמשי הקצה לעדכן לגרסה העדכנית של האפליקציה. מכיוון שחבילת אישורי הבסיס של TLS מקומפלת לתוך הקובץ הבינארי של האפליקציה, עדכוני מערכת הפעלה או שינויים בצד השרת לבדם לא מתקנים גרסאות build של אפליקציות שהותקנו בעבר.


אפליקציות Unity שמטרגטות פלטפורמות של אפל או של מחשבים וגם משתמשות ב-Cloud Firestore

אם יש לכם אפליקציית Unity שמטרגטת פלטפורמות של אפל (לדוגמה, iOS) וגם האפליקציה משתמשת ב-Cloud Firestore, אתם צריכים לבצע את הפעולות הבאות:

  1. קובעים איזו גרסת SDK חדשה מתאימה לאפליקציה. בהתאם לגרסת ה-SDK הנוכחית, בוחרים גרסת SDK שמתאימה לאפליקציה.

    ‫Firebase SDK ל-Unity (גרסה firebase-unity-sdk) – iOS או מחשב (Linux, ‏ macOS, ‏ Windows)

    גרסאות ה-SDK המושפעות גרסאות SDK עם תיקון האבטחה
    ‫14.0.0 וגרסאות קודמות
    (לא כולל 13.17.1)
    • אפשרות 1: 14.1.0 ואילך
    • אפשרות 2: 13.17.1

  2. מעדכנים את האפליקציה. מורידים את Firebase Unity SDK בגרסה הרצויה מדף הגרסאות ב-GitHub.

  3. מקשרים ובונים מחדש את האפליקציה. מקשרים ובונים מחדש את האפליקציות ל-iOS ולמחשב.

  4. מפרסמים מחדש את האפליקציה. מפרסמים מחדש את האפליקציה עם גרסת ה-SDK המעודכנת (לדוגמה, ב-Apple App Store או בערוצי ההפצה למחשב).

אחרי הפרסום מחדש של האפליקציה, צריך לעודד את משתמשי הקצה לעדכן לגרסה העדכנית של האפליקציה. מכיוון שחבילת אישורי הבסיס של TLS מקומפלת לקובץ הבינארי של האפליקציה, עדכוני מערכת ההפעלה או שינויים בצד השרת לבדם לא מתקנים גרסאות build של אפליקציות שהותקנו בעבר.


אפליקציות C++‎ שמטרגטות פלטפורמות של Apple או של מחשבים וגם משתמשות ב-Cloud Firestore

אם יש לכם אפליקציית C++‎ שמטרגטת פלטפורמות של אפל (לדוגמה, iOS) והאפליקציה משתמשת ב-Cloud Firestore, בצעו את הפעולות הבאות:

  1. קובעים איזו גרסת SDK חדשה מתאימה לאפליקציה. בהתאם לגרסת ה-SDK הנוכחית, בוחרים גרסת SDK שמתאימה לאפליקציה.

    ‫Firebase SDK ל-C++‎‏ (firebase_cpp_sdk) – iOS או מחשב (Linux, ‏ macOS, ‏ Windows)

    גרסאות ה-SDK המושפעות גרסאות SDK עם תיקון האבטחה
    ‫14.0.0 וגרסאות קודמות
    (לא כולל 13.13.1)
    • אפשרות 1: 14.1.0 ואילך
    • אפשרות 2: 13.13.1

  2. מעדכנים את האפליקציה. מורידים את Firebase C++ SDK לגרסה הרצויה מדף הגרסאות ב-GitHub.

  3. מקשרים ובונים מחדש את האפליקציה. מקשרים ובונים מחדש את האפליקציות ל-iOS ולמחשב.

  4. מפרסמים מחדש את האפליקציה. מפרסמים מחדש את האפליקציה עם גרסת ה-SDK המעודכנת (לדוגמה, ב-App Store של אפל או בערוצי ההפצה למחשב).

אחרי שמפרסמים מחדש את האפליקציה, צריך לעודד את משתמשי הקצה לעדכן לגרסה העדכנית של האפליקציה. מכיוון שחבילת אישורי הבסיס של TLS מקומפלת לתוך הקובץ הבינארי של האפליקציה, עדכוני מערכת ההפעלה או שינויים בצד השרת לבדם לא מתקנים גרסאות build של אפליקציות שהותקנו בעבר.


אפליקציות ל-Android (מותאמות ספציפית) שמשתמשות בפלאגין Firebase App Distribution של Gradle

אם יש לכם אפליקציית Android מקורית שמשתמשת בפלאגין Firebase App Distribution Gradle, בצעו את הפעולות הבאות:

  1. קובעים את גרסת הפלאגין החדשה שמתאימה לאפליקציה. אפשר להשתמש בפלאגין בגרסה 5.3.1 ואילך.

  2. מעדכנים את קובץ Gradle. בקובץ Gradle ברמת הבסיס (ברמת הפרויקט) (<project>/build.gradle.kts או <project>/build.gradle), מעדכנים את הפלאגין של App Distribution ל-Gradle לגרסה 5.3.1 ואילך:

    Kotlin 

    plugins {
    // ...
    // Update the version in the dependency for the App Distribution Gradle plugin.
    // Make sure the version is 5.3.1 or higher.
    id("com.google.firebase.appdistribution") version "5.3.1" apply false
}

    Groovy 

    plugins {
    // ...
    // Update the version in the dependency for the App Distribution Gradle plugin.
    // Make sure the version is 5.3.1 or higher.
    id 'com.google.firebase.appdistribution' version '5.3.1' apply false
}

    buildscript (מדור קודם) 

    buildscript {
    dependencies {
        // ...
        // Update the version in the dependency for the App Distribution Gradle plugin.
        // Make sure the version is 5.3.1 or higher.
        classpath 'com.google.firebase:firebase-appdistribution-gradle:5.3.1'
    }
}

  3. לנקות ולאמת את תהליכי העבודה של CI/CD. מוודאים שצינורות עיבוד הנתונים האוטומטיים של ה-build והפריסה (כמו GitHub Actions,‏ GitLab CI או Jenkins) שולפים את הגרסה המעודכנת של הפלאגין כשמבצעים משימות כמו ./gradlew appDistributionUpload<Variant>.


מידע מפורט על מה שקרה

ב-19 באוקטובר 2026, Google גילתה שהמפתחות הפרטיים של כמה אישורים של רשות אישורים (CA) ביניים שהונפקו על ידי רשות אישורים של צד שלישי (eMudhra) נחשפו ובוטלו לאחר מכן (לפרטים נוספים, ראו את הפוסט בבלוג האבטחה של Google).

מערכות הפעלה ודפדפני אינטרנט הפיצו עדכונים כדי להסיר את האמון באישורים האלה במאגרי האישורים של המערכת, אבל המוצרים המושפעים מאמתים חיבורי Transport Layer Security ‏ (TLS) באמצעות חבילת אישורי בסיס מוטמעת שמקומפלת לקובץ הבינארי.

תוקפים יכולים להשתמש במפתחות של רשות האישורים שנחשפו כדי לזייף אישורי HTTPS שנראים לגיטימיים, ולכן אפליקציות שמושפעות מהבעיה לא יזהו את הביטול וימשיכו לסמוך על פרטי הכניסה המזויפים. כתוצאה מכך, תוקפים ברשת יכולים לבצע התקפות אדם בתווך כדי להתחזות לשרתי בק-אנד אמיתיים, כולל Firestore וכל נקודות הקצה של HTTPS שאפליקציות Flutter/Dart או הפלאגין Gradle של הפצת אפליקציות יוצרים איתן קשר, וליירט, לגנוב או לשנות בחשאי נתוני משתמשים רגישים.

כדי להגן על החיבורים של הלקוחות מפני רשות האישורים שנפגעה, הסרנו את אישורי הבסיס שמקושרים לאישורי הביניים של eMudhra שנפגעו, במקומות הבאים:

  • ערכות SDK של Cloud Firestore ל-Apple, ל-Flutter, ל-Unity ול-C++‎

    ה-backend של Cloud Firestore לא הושפע, וגם לא חלקים אחרים של המוצר Cloud Firestore.

  • ערכת ה-SDK של Flutter והפלאגין FlutterFire ל-Cloud Firestore

  • הפלאגין של Firebase App Distribution Gradle

    ה-backend של App Distribution לא הושפע, וגם לא חלקים אחרים של המוצר App Distribution.