رجوع

2026/10/30

حُميت المتصفحات خلال ساعات، فماذا عن Java في المؤسسات؟ كيف استجابت LOGIQ لحادثة شهادات eMudhra

حظرت المتصفحات شهادات eMudhra الوسيطة المخترقة خلال ساعات، لكن لكل JDK مخزن ثقة خاص به. ما الذي أصدرته Azul وBellSoft، وما الذي فعلته LOGIQ، وما الذي يجب فحصه الآن.

أهم النقاط

  • في 17 أكتوبر 2026، تلقت Mozilla بلاغًا يفيد بأن المفاتيح الخاصة لثماني شهادات CA وسيطة تابعة لـ eMudhra قد تعرضت للاختراق. وحظرتها المتصفحات خلال فترة تراوحت بين ساعات وأيام. وتقول eMudhra إنها ليست على علم بأي دليل على استغلال هذه المفاتيح.
  • لا تعتمد Java على قرارات الثقة الخاصة بالمتصفح أو بنظام التشغيل. فكل JDK، وكل صورة حاوية أو تطبيق يتضمن JDK، يحمل مخزن ثقة خاصًا به. ويحتاج كل منها إلى تحديث مستقل.
  • أصدرت Azul تحديثين لـ Zulu خارج الدورة المعتادة، في 21 أكتوبر و24 أكتوبر. وجاء التحديث الثاني لأن الإصلاح الأول لم يكن كافيًا، لذا لم يعد الحل المؤقت الصادر في 21 أكتوبر كافيًا بمفرده.
  • تدرج BellSoft إصدارات Liberica مُصلَحة لـ Java 8 و11 و17 و21 و25 و27. وقد حصلت LOGIQ على هذه الإصدارات عبر قناة دعم BellSoft الخاصة بنا وأتاحتها لعملائنا.
  • ما يجب فعله: حدِّد كل بيئة تشغيل Java لديك، وتحقق من المورّد ورقم الإصدار بدقة، وانتقل إلى الإصدار المُصلَح من ذلك المورّد، واختبر اتصالات TLS، وواصل متابعة الإصدارات الصادرة خارج الدورة المعتادة.

ماذا حدث

في يوم السبت 17 أكتوبر 2026، في الساعة 20:06 بالتوقيت العالمي المنسق (UTC)، تلقت Mozilla بلاغًا يفيد بأن المفاتيح الخاصة لثماني شهادات وسيطة تابعة لـ eMudhra قد تعرضت للاختراق. فحظرت Mozilla الشهادات الثماني في Firefox عبر OneCRL، وهي قائمة الإبطال المركزية لديها، ووصل التحديث إلى المستخدمين ذوي الإعدادات القياسية بحلول الساعة 22:59 UTC، أي بعد أقل من ثلاث ساعات. وقد أعلنت Mozilla عن الحادثة علنًا في 20 أكتوبر. كما أصدرت إصدارات فرعية من Firefox للمستخدمين الذين منعت إعداداتهم تحديث OneCRL، وأزالت شهادة الجذر التي وقّعت الشهادات الوسيطة من مخزن الثقة NSS.

يتمثل الخطر في تزوير الشهادات. فأي شخص يحوز أحد هذه المفاتيح يمكنه إصدار شهادة HTTPS لموقع لا يتحكم فيه. وإذا تمكن أيضًا من التموضع بين العميل وذلك الموقع، فبإمكانه انتحال صفة الموقع وقراءة حركة البيانات أو تعديلها.

لا يوجد حتى الآن أي دليل على حدوث ذلك. ففي بيانها بشأن الحادثة، تقول eMudhra إن الشهادات الوسيطة الثماني أُبطلت في 18 أكتوبر، وإن أيًّا منها لم يُصدر أي شهادات للكيانات النهائية، وإنها “ليست على علم بأي دليل على أن المفاتيح الضعيفة قد استُرجعت أو استُغلت من قِبل أي طرف قبل الإفصاح عن المشكلة”. وتصف eMudhra السبب بأنه مفاتيح ضعيفة وُلِّدت خلال مراسم توليد مفاتيح أُجريت في عام 2025. وتقول إنها لم تتأكد بعد من السبب الجذري الدقيق، وإن تحقيقها لا يزال جاريًا. وقد سحبت برامج شهادات الجذر في المتصفحات الثقة من شهادة جذر eMudhra التي تعلو هذه الشهادات الوسيطة كإجراء احترازي.

لذا فإن هذا المقال يتناول سدّ نافذة تعرّض للخطر، وليس هجومًا مؤكدًا.

لماذا تحتاج Java إلى إصلاح خاص بها

تمتلك المتصفحات وأنظمة التشغيل آليات تلقائية لإيقاف الثقة في جهة إصدار شهادات، وقد استخدمتها بسرعة. ووفقًا لرواية Azul للحادثة، حظرت Chrome الشهادات في اليوم نفسه، وApple في 19 أكتوبر، وMicrosoft في 20 أكتوبر.

لا ترث Java أيًّا من ذلك. إذ يحدد JDK الشهادات التي يثق بها استنادًا إلى ملفاته الخاصة:

  • مخزن ثقة خاص به. يأتي كل JDK مع ملف cacerts خاص به. ولا يؤدي تحديث حزمة شهادات نظام التشغيل، أو إعادة تشغيل المتصفح، إلى تغييره.
  • لا فحص للإبطال افتراضيًا. كما تذكر وثائق Azul، تثق Java في شهادات الجذر التي ترتبط بها هذه الشهادات الوسيطة، و”لا تتحقق من الإبطال افتراضيًا”. لذا فإن إبطال eMudhra للشهادات الوسيطة لا يحمي، في حد ذاته، عميل Java.
  • نسخ متعددة. قد يشغّل الخادم الواحد JDK النظام، وJDK مضمّنًا داخل تطبيق، وبيئة تشغيل مبنية بـ jlink، وعدة صور حاويات، لكل منها نسخته الخاصة من مخزن الثقة. وتظل كل نسخة معرّضة للخطر إلى أن يتم تحديثها أو إعادة بنائها.

وبالتالي، قد تظل خدمة Java التي تُجري اتصالات TLS صادرة تقبل شهادة مزورة حتى بعد أن تصبح جميع المتصفحات في المؤسسة محمية. وهذه هي الفجوة التي يتناولها هذا المقال.

تحديثان طارئان من Azul

أصدرت Azul تحديثين لـ Azul Zulu خارج الدورة المعتادة بعد إصدارها الفصلي لشهر أكتوبر:

  • 21 أكتوبر: يضيف التحديث الأول خارج الدورة الشهادات الوسيطة الثماني المخترقة إلى قائمة الحظر في JDK (blocked.certs في JDK 11 وما بعده، وblacklisted.certs في الإصدارات الأقدم). ويشمل Zulu 27 و25 و21 و17 و11 و8 و7 و6. وتسجله قائمة CVE لدى Azul تحت المعرّف CVE-2026-91403. ولبيئات التشغيل التي تعذّر تحديثها فورًا، نشرت Azul أيضًا حلًا مؤقتًا يدويًا يستبدل ملف قائمة الحظر.
  • 24 أكتوبر: وجدت Azul أن قائمة الحظر لم تُغلق المشكلة بالكامل. ويُصلح التحديث الثاني خارج الدورة الثغرة CVE-2026-114820 (في JSSE، بدرجة أساسية 9.1) عبر إزالة شهادات CA معيّنة من cacerts كليًا. وحتى وقت كتابة هذا المقال، تتوفر هذه الإصدارات لخط CPU الخاص بالتحديثات الأمنية فقط لدى Azul، سواء على قاعدة CPU لشهر أكتوبر 2026 (مثل Zulu 21.53.114 و17.69.114 و11.91.114 و8.97.0.112) أو على قاعدة CPU لشهر يوليو 2026. وتقول Azul إن إصدارات PSU “ستتبع على الأرجح” في تحديث منفصل.

يغيّر تحديث 24 أكتوبر التوصيات. إذ تحذّر صفحة الحل المؤقت لدى Azul الآن من أنه “لم يعد يعالج المشكلة بالكامل”، وتطلب Azul من جميع العملاء التحديث إلى أحدث إصدار. فإذا كنت قد طبّقت تحديث 21 أكتوبر أو الحل المؤقت، فلا تزال بحاجة إلى إصدار 24 أكتوبر. وفي مقالها الخاص، تقول Azul إن الأمر استغرق نحو 12 ساعة من قرار إعادة البناء حتى وصول إصدارات التحديثات الأمنية فقط إلى أيدي العملاء.

ما الذي أصدرته BellSoft لـ Liberica JDK

نشرت BellSoft إصدار Liberica JDK الدوري لشهر أكتوبر 2026 في 21 أكتوبر. ويُدرج هذا الإصدار الفصلي 52 ثغرة CVE مُصلَحة، ويتضمن إصدارات CPU لـ Java 6 و7 (6u521 و7u521). ولا تتناول ملاحظات الإصدار مشكلة eMudhra.

تتناول BellSoft مشكلة eMudhra في دليل منفصل بعنوان “Distrusting compromised eMudhra intermediates in Java” (آخر تحديث في 27 أكتوبر). ويُدرج الدليل الإصدارات المُصلَحة من Liberica JDK وهي 8u513+9 و11.0.33.0.3+7 و17.0.21.0.3+5 و21.0.13.0.3+5 و25.0.5.0.3+5 و27.0.1.0.3+5. وللأنظمة التي لا يمكن تحديثها بعد، يقدّم الدليل إجراءً مؤقتًا للتخفيف: إزالة شهادات الجذر المتأثرة من مخزن الثقة. ويحذّر من أن ذلك قد يُعطّل سلاسل شهادات مشروعة، وينبغي اختباره أولًا.

ثمة نقطتان مهمتان عند المقارنة بين المورّدين:

  • قوائم CVE ليست متطابقة. تنشر كل من Azul وBellSoft قائمة CVE خاصة بها لدورة أكتوبر، وتختلف الأعداد والملاحظات. فمعرّفا CVE الخاصان بـ Azul المذكوران أعلاه مأخوذان من سجلات Azul، ولا يذكرهما دليل BellSoft. راجع ملاحظات الإصدار الخاصة بمورّدك لمعرفة الإصلاحات الدقيقة في إصدارك، ولا تفترض أن قائمة أحد المورّدين تنطبق على JDK من مورّد آخر.
  • Java 6 و7 ليسا ضمن قائمة BellSoft الخاصة بـ eMudhra. تتوفر أحدث إصدارات BellSoft من Java 6 و7، لكن قائمة الإصدارات المُصلَحة في دليلها الخاص بـ eMudhra تبدأ من Java 8. فإذا كنت تستخدم Liberica 6 أو 7، فاستفسر عمّا إذا كان إصدارك يتضمن التغيير في مخزن الثقة قبل الاعتماد عليه، أو طبّق إجراء التخفيف الذي يقدّمه المورّد. أما Azul فتُدرج إصدارات 24 أكتوبر لـ Zulu 6 و7.

كيف استجابت LOGIQ

نقوم بتوزيع إصدارات Java من BellSoft وAzul على عملائنا، ونساعدهم على الانتقال من إصدارات Oracle JDK القديمة. وفيما يلي ما قمنا به، مع حالة كل بند حتى وقت كتابة هذا المقال (29 أكتوبر).

ما تم إنجازه

  • 21–22 أكتوبر: مراجعة إشعارات المورّدين. تلقينا وراجعنا إشعار Azul الصادر في 21 أكتوبر بشأن التحديث خارج الدورة، وإشعار BellSoft بإصدار أكتوبر 2026. وفتحنا في اليوم نفسه مهام التنزيل والمستودع لكلا المورّدين. وتعاملنا مع الإصدارين بشكل منفصل، ولم نفترض أن الإصدار الفصلي من BellSoft يتضمن إصلاح eMudhra نفسه الموجود في إصدار Azul.
  • 23 أكتوبر: تجهيز إصدارات Liberica الفصلية. نزّلنا إصدارات Liberica JDK لشهر أكتوبر 2026 من بوابة الدعم لدى BellSoft، وأضفناها إلى المستودع الذي ينزّل منه عملاؤنا.
  • 24–25 أكتوبر: متابعة التحديث الثاني من Azul. تلقينا إشعار Azul الصادر في 24 أكتوبر، بما في ذلك توصيتها بالتحديث حتى لو كان إصدار 21 أكتوبر مثبّتًا بالفعل.
  • 27–28 أكتوبر: الحصول على إصدارات Liberica المُصلَحة عبر BellSoft. طلبنا من BellSoft، من خلال علاقة الدعم التجاري بيننا، إتاحة أحدث الإصدارات على بوابة الدعم الخاصة بنا. وقد رفعتها BellSoft في 28 أكتوبر، بما في ذلك الإصدارات المُصلَحة لـ Java 8 و11 و17 و21 و25 و27 وأحدث إصدارات Java 6 و7. ونظرًا لأن بعض العملاء لا يزالون بحاجة إلى Java 8 بنظام 32 بت، طلبنا أيضًا من BellSoft إضافة مثبّتات 8u513+9 بنظام 32 بت لـ Windows وLinux إلى بوابتنا. وأضافتها BellSoft في اليوم نفسه.
  • 28–29 أكتوبر: تحديث المستودع وخرائط الانتقال. أضفنا هذه الإصدارات إلى مستودع التنزيل الخاص بعملائنا، وحدّثنا إرشاداتنا للانتقال من Oracle JDK إلى Liberica لتشير إليها، مع مراجعة التحديث من قِبل مهندس ثانٍ.

عملاء Azul Zulu

تتوفر إصدارات Azul الصادرة في 21 أكتوبر و24 أكتوبر لمشتركي Azul عبر Azul. ويعتمد الإصدار المناسب على إصدار Java لديك، وعلى ما إذا كنت تستخدم خط CPU أو PSU، وعلى القاعدة التي تعتمد عليها (أكتوبر أو يوليو). راجع ملاحظات الإصدار لدى Azul لمعرفة إصدارك الدقيق، أو تواصل معنا وسنساعدك على تحديده.

الإصدارات القديمة Java 6 و7

لا يزال بعض العملاء يستخدمون Java 6 أو 7، وغالبًا في تطبيقات لا يمكن نقلها بسرعة. لم تعد Oracle تقدّم تحديثات عامة لهذه الإصدارات، لكن ذلك لا يعني انعدام الخيارات. فنحن نساعد العملاء على الانتقال من إصدارات Oracle JDK 6 و7 القديمة إلى أحدث إصدارات Liberica JDK 6 و7، كما أن إصدارات BellSoft لشهر أكتوبر 2026 لكلا الإصدارين متاحة لنا عبر بوابة الدعم لدى BellSoft. وعندما يكون أحد الإصلاحات أو الحزم التي نحتاجها لهذه الإصدارات غير متوفر، نصعّد الأمر إلى BellSoft عبر قناة الدعم التجاري الخاصة بنا. وبالنسبة لهذه الحادثة، راجع الملاحظة أعلاه: تأكد من أن إصدار Java 6 أو 7 لديك يتضمن تغيير مخزن الثقة الخاص بـ eMudhra قبل الاعتماد عليه.

ما يجب عليك فعله الآن

1. حدِّد كل بيئة تشغيل Java

اجرد كل مكان تعمل فيه Java، وليس JDK النظام فقط. ويشمل ذلك خوادم التطبيقات، وبيئات التشغيل المضمّنة داخل منتجات المورّدين، وصور jlink، ووكلاء البناء في CI، وكل صورة حاوية. على Linux، يعثر الأمر التالي على ملفات Java التنفيذية على المضيف:

find / -xdev -type f -path "*/bin/java" 2>/dev/null

بالنسبة لصور الحاويات، شغّل الفحص داخل الصورة، على سبيل المثال docker run --rm --entrypoint java <image> -version.

2. تحقق من المورّد ورقم الإصدار بدقة

لا يكفي معرفة الإصدار الرئيسي. فأنت بحاجة إلى معرفة المورّد ورقم الإصدار الكامل لمطابقتهما مع قائمة الإصدارات المُصلَحة لدى المورّد:

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

وكمؤشر سريع، يمكنك أيضًا عرض شهادات الجذر الخاصة بـ eMudhra (emSign) في مخزن الثقة لبيئة التشغيل:

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

في اختباراتنا على صور الحاويات العامة من BellSoft، أظهر إصدار Liberica 21.0.10 الأقدم خمس شهادات جذر من emSign، بينما لم يُظهر الإصداران المُصلَحان 21.0.13.0.3+5 و8u513 أيًّا منها. والنتيجة الفارغة مؤشر جيد لكنها ليست دليلًا قاطعًا. فإصلاح Azul الصادر في 21 أكتوبر، على سبيل المثال، حظر الشهادات الوسيطة دون إزالة شهادات الجذر. ويبقى رقم الإصدار هو الفحص الموثوق. ويتناول مقالنا السابق حول فحص مخازن الثقة في Java فحوصات أكثر تفصيلًا.

3. احصل على أحدث تصحيح منطبق

  • Azul Zulu: انتقل إلى إصدار 24 أكتوبر الصادر خارج الدورة والخاص بخطك (CPU أو PSU، على قاعدة أكتوبر أو يوليو)، حتى لو كنت قد ثبّتّ إصدار 21 أكتوبر أو طبّقت الحل المؤقت. وإذا كنت تستخدم إصدارات PSU، فتابع إصدار PSU اللاحق من Azul.
  • Liberica JDK: انتقل إلى الإصدارات المُصلَحة التي أدرجتها BellSoft (8u513+9 و11.0.33.0.3+7 و17.0.21.0.3+5 و21.0.13.0.3+5 و25.0.5.0.3+5 و27.0.1.0.3+5).
  • المورّدون الآخرون وبيئات التشغيل المضمّنة: راجع النشرة الأمنية لذلك المورّد. فـ JDK المضمّن داخل منتج من طرف ثالث يُحدَّث من قِبل مورّد ذلك المنتج، وليس عبر تحديثات نظام التشغيل لديك.
  • الحاويات: أعد بناء الصور على صورة أساسية مُصلَحة ثم أعد نشرها. فترقيع حاوية قيد التشغيل لا يغيّر الصورة.

4. تحقق من اتصالات TLS قبل الطرح وأثناءه

قد تؤدي إزالة شهادات الجذر من مخزن الثقة إلى تعطيل اتصالات مشروعة، على سبيل المثال مع مواقع لا تزال تستخدم شهادات ترتبط بشهادات جذر eMudhra المُزالة. وتقول eMudhra إنها تعيد إصدار شهادات العملاء المتأثرة من تسلسل هرمي بديل لجهة إصدار الشهادات (CA). وقبل الطرح على نطاق واسع، اختبر اتصالات TLS الصادرة التي تعتمد عليها تطبيقاتك، لا سيما مع الشركاء أو الخدمات التي قد تستخدم شهادات eMudhra. نفّذ الطرح على مراحل، وأعد تشغيل عمليات Java لتحميل مخزن الثقة الجديد، ثم تأكد من الإصدار قيد التشغيل بعد ذلك.

5. تابع الإصدارات الصادرة خارج الدورة المعتادة

أسفرت هذه الحادثة عن إصدارين طارئين لـ Java خلال أربعة أيام، وقد تتبعهما إصدارات أخرى، مثل إصدارات PSU من Azul. اشترك في الإشعارات الأمنية لدى مورّديك، وراجع صفحات الإصدارات لديهم مباشرةً بدلًا من الاعتماد على البريد الإلكتروني وحده، وخطّط لتحديثات Java خارج الجدول الفصلي.

الدرس المستفاد

حُمي مستخدمو Firefox خلال ساعات لأن المتصفحات تمتلك مخازن ثقة خاصة بها وآلية تلقائية لتحديثها. أما Java في المؤسسات فلديها مخازن ثقة عديدة، ولا تُجري فحوصات إبطال افتراضيًا، وتنتظر تحديثاتها من يقوم بتثبيتها. ويتطلب سدّ هذه الفجوة جردًا دقيقًا، وأرقام إصدارات دقيقة، ووصولًا سريعًا إلى إصدارات المورّدين، وعملية لا تنتظر التصحيح الفصلي التالي. وإذا كنت بحاجة إلى مساعدة في تحديد بيئات تشغيل Java في بيئتك أو تحديثها، فتواصل مع LOGIQ.

المراجع