عملاء إيثريوم يُصلحون ثغرة قد تُعيد توجيه مكافآت ETH
تحديثات Teku و Besu تُبرز أهمية أمن البنية التحتية الخارجية
تم إصدار تحديثات أمنية لعميل التوافق Ethereum Teku وعميل التنفيذ Besu في أواخر أكتوبر 2026 لإغلاق ثغرة مرتبطة بمفاتيح سلطة شهادة مخترقة من الشركة الهندية eMudhra. كانت هذه الثغرة يمكن أن تسمح للمهاجمين الذين اعتراضوا بعض اتصالات HTTPS بانتحال هوية الخدمات الخارجية المستخدمة من قبل المدققين وإعادة توجيه مكافآت الكتل أو الحصول على توقيعات حساسة. اكتشف الباحثون أن ثمانية سلطات شهادة وسيطة من eMudhra كانت مفاتيحها الخاصة مولدة بعشوائية غير كافية، مما جعل تلك المفاتيح قابلة للاسترجاع من الشهادات العامة نفسها. وبما أن بيئات تشغيل Java المستخدمة من قبل العميلين لا تتحقق من إلغاء الشهادات افتراضيًا، استمرت بعض صور Docker والتثبيتات في الثقة بالسلاسل المتأثرة حتى بعد حظرها من قبل المتصفحات وأنظمة التشغيل الرئيسية. لم تتأثر التكوينات الافتراضية لشبكة mainnet لـ Teku التي تجنبت نقاط نهاية HTTPS، ولم يبلغ المطورون عن أي استغلال مؤكّد.
تُزيل التصحيحات الثقة في الجذور المعنية من صور دوكير المحدثة، بينما يجب على المشغلين الذين يشغلون ملفات ثنائية مستقلة معالجة مخازن الثقة المحلية الخاصة بجافا بشكل منفصل. وتُبرز هذه الحادثة كيف يمكن للاعتمادات على البنية التحتية الخارجية أن تخلق مخاطر ضيقة لكنها ذات تأثير عالٍ على عمليات التخزين، حتى عندما تظل البروتوكول الأساسي آمنًا. ويعكس الاستجابة السريعة من قبل Teku و Besu أن تنوع عملاء إيثريوم وممارسات الأمان الاستباقية يمكنها احتواء التهديدات المتعلقة بالشهادات قبل أن تؤثر على مكافآت المدققين على نطاق واسع، شريطة تطبيق المشغلين للتحديثات المتاحة ومراجعة تكوينات اتصالاتهم الخارجية.
ضعف العشوائية في المفاتيح الوسيطة لـ eMudhra أنشأ مواد خاصة قابلة للاسترجاع
حدد الباحثون المشكلة في 17 أكتوبر 2026، عندما تبين أن المفاتيح الخاصة وراء ثمانية من سلطات الشهادات الوسيطة الخاصة بـ eMudhra تم إنشاؤها بكمية ضئيلة جدًا من العشوائية. كانت المفاتيح قابلة للاستعادة فعليًا من الشهادات العامة، وهي حالة كانت سارية منذ إنشائها في حفل توليد المفاتيح في أبريل 2025. دعم ستة من الوسيطين اتصالات TLS، بينما كان اثنان مرتبطين بتوقيع الكود. بمجرد أن أصبحت المواد الخاصة معروفة، كان يمكن للمهاجم إصدار شهادات مزيفة تقبلها البرامج التي لا تزال تثق في السلطات المتأثرة. ألغت eMudhra الوسيطين في 18 أكتوبر. استجابت المنصات الكبرى بسرعة: بدأت المتصفحات وأنظمة التشغيل في حظر الشهادات بين 17 و20 أكتوبر، وأصدرت مايكروسوفت تحديثات إضافية لـ Windows وEdge في 26–27 أكتوبر أزالت منها الجذور المرتبطة من قوائم الثقة الخاصة بها. لم تكن فشل التشفير نفسه مشكلة في بروتوكول Ethereum، لكنه كان مهمًا لأن Teku وBesu تعتمدان على التحقق من شهادات Java لأي اتصالات HTTPS تقوم بها عقدهما. ترك السلوك الافتراضي لـ Java لتجاهل فحوصات الإلغاء بعض التثبيتات عرضة لفترة أطول من بيئات المتصفحات. وبالتالي، يوضح هذا الحادث كيف يمكن أن ينتشر خطأ تشغيلي واحد من سلطة شهادة واحدة إلى بنية تحتية متخصصة تعتمد على مخازن الثقة القياسية لـ TLS.
لم يتطلب استعادة المفاتيح تحليلًا تشفيريًا معقدًا؛ فقد جعلت العشوائية غير الكافية عملية الاستنباط بسيطة بمجرد فحص الشهادات العامة. وقد أكدت إشعار مايكروسوفت في 26 أكتوبر أن المفاتيح يمكن استخدامها لإنشاء شهادات تبدو وكأنها تأتي من سلطة موثوقة، مما قد يمكّن من انتحال هوية المواقع أو الخدمات. بالنسبة لمشغلي إيثريوم، كانت النتيجة العملية هي أن أي تكوين مُحقق يعتمد على نقاط نهاية HTTPS، أو عقد م Beacons بعيدة، أو توقيعات خارجية، أو مُنشئي كتل، أو مُرسلات، كان يمكنه قبول شهادة مزيفة إذا كانت بيئة تشغيل Java الأساسية لا تزال تثق بالسلسلة المخترقة. ظل التوصيل الند للند المستخدم من قبل عملاء إيثريوم غير متأثر لأنه لا يعتمد على سلطات الشهادات هذه. وقد خلق مزيج المفاتيح القابلة للاستعادة وفحص Java غير المُلغى فرصةً لمقاتل منتصف الطريق يقع على مسار الشبكة ليقدم هوية مقنعة لبرنامج العميل. واستجابت فرق العملاء بإزالة الجذور ذات الصلة من صور Docker الخاصة بهم بدلاً من الانتظار فقط لتحديثات Java الأساسية، مما ضمان حصول المشغلين الذين يسحبون صورًا جديدة على مخزن ثقة مُعزز. وقد حدّت هذه الاستجابة المتعددة الطبقات — إلغاء الشهادات عند سلطة الشهادة، وحظر المنصات، وتحديثات الصور الخاصة بالعميل — من سطح الهجوم العملي لمعظم إعدادات التخزين.
كيف يمكن أن تغير الشهادات المزورة سلوك اقتراح الكتل ومستلمي الرسوم
أوضح إشعار أمان Teku مسارات هجوم ملموسة تصبح ممكنة بمجرد قدرة المهاجم على تقديم شهادة مزورة تقبلها العميل. أحد السيناريوهات يتضمن انتحال هوية عقد بeacon بعيد يستخدمه المدقق للتنسيق. إذا تم اعتراض الاتصال وقبول الشهادة المزورة، فقد يتلقى المدقق معلومات مُعدلة حول الكتلة التي يُعدّ لاقتراحها. في هذه الحالة، قد يُنشئ العميل ويوقّع على كتلة يكون عنوان مستلم الرسوم موجهًا إلى حساب يتحكم فيه المهاجم بدلاً من عنوان المُشغل المُعين. ستتدفق رسوم المعاملات وأي مبالغ أولوية مدرجة في الكتلة إلى المهاجم. كما أظهر الإشعار خدمات التوقيع الخارجي، التي تحتفظ بمفاتيح المدقق بشكل منفصل وتُعيد التوقيعات عند الطلب. يمكن للمهاجم القادر على انتحال هوية مثل هذا المُوقّع الحصول على توقيعات تُستخدم في عمليات حساسة، بما في ذلك التغييرات التي تؤثر على وجهة المكافآت. وصنّف Teku حالة المُوقّع الخارجي ضمن التكوينات الأكثر خطورة، على الرغم من أن مصادقة TLS المتبادلة في بعض الإعدادات قد تحد من التأثير إلى منع الخدمة بدلاً من اختراق التوقيع.
تشمل أنواع الاتصالات المكشوفة الإضافية عملاء التنفيذ، وبناء الكتل، والمرسلات، والخدمات التي توفر بيانات تكوين المُحققين. في كل حالة، يكون الخطر الأساسي هو نفسه: يعامل برنامج العميل الشهادة المزورة على أنها شهادة مشروعة وبالتالي يقبل البيانات أو التعليمات التي تغير محتوى الكتلة المقترحة أو معالجة المفاتيح. لا تمنح الثغرة وصولًا مباشرًا إلى مفتاح التوقيع الخاص بالمُحقق أثناء التشغيل العادي؛ بل تُضعف سلامة الخدمات الخارجية التي يستشيرها المُحقق. وبما أن مكافآت وكفاءات كتل إيثريوم تُدفع وفقًا للعناوين المضمنة في الكتلة المقترحة، فيمكن للتدخل الناجح أثناء الاقتراح تحويل القيمة دون الحاجة إلى نقل الأموال المكتسبة مسبقًا. لم يُبلغ عن أي استغلال لهذه المسارات، وتظل التثبيتات الافتراضية لـ Teku على الشبكة الرئيسية التي لا تحتوي على عناوين HTTPS في تكوينها خارج المجموعة المتأثرة. ومع ذلك، فإن السيناريوهات التفصيلية توضح بوضوح سبب تعامل فرق العملاء مع هذه المسألة على أنها تتطلب تحديثات فورية لصور Docker، حتى مع بقاء طبقات البروتوكول الأساسية وطبقات الند للند دون تغيير.
Teku 26.10.3 يزيل الجذور المخترقة من مخازن الثقة الخاصة بـ Docker
أصدر Teku الإصدار 26.10.3 في 27 أكتوبر 2026، وذلك بشكل خاص لمعالجة التعرض المرتبط بـ eMudhra. تشير ملاحظات الإصدار إلى أن صور Docker لم تعد تثق في شهادات الجذر emSign ECC Root CA – G3 و emSign Root CA – G1 و emSign Root CA – G2 أو AAA Certificate Services. تم إزالة هذه الجذور من قبل OpenJDK بعد اختراق السلطات الوسيطة؛ لكن صور Eclipse Temurin الأساسية المستخدمة من قبل Teku لم تدمج التصحيح المقابل بعد عند إصدار العميل. من خلال توزيع صور محدثة، تأكد فريق Teku من أن المشغلين الذين يجلبون العلامات الجديدة سيحصلون على بيئة تشغيل Java يستبعد محتوى المخترق من مستودع الثقة. وتشدد التوصية المرافقة للإصدار على أن العقدة الافتراضية على الشبكة الرئيسية دون تكوين أي عناوين HTTPS لا تتطلب أي إجراء. التعرض محدود فقط للتكوينات التي تتصل عمدًا بنقاط نهاية HTTPS عن بُعد لتنسيق الشعاع، أو التوقيع الخارجي، أو المُنشئين، أو خدمات مشابهة.
المشغلون الذين يستخدمون صور Docker الأقدم، بما في ذلك تلك الموسومة حتى الإصدار 26.10.2، لا يزالون يوفرون بيئة تشغيل تثق بالجذور المتأثرة. تحديث تثبيت Java على المضيف لا يُحدث تلقائيًا بيئة التشغيل داخل حاوية موجودة، لذا يتطلب الأمر سحب صورة جديدة. كما أشار Teku إلى أن Java 26 وصلت إلى نهاية دورة حياتها ولن تتلقى إصدارًا مُصلحًا؛ ويُنصح المشغلون الذين لا يزالون يستخدمون هذا الإصدار بالانتقال إلى الإصدار الحالي المدعوم طويل الأمد، وهو Java 25، واستخدام علامات الصورة المقابلة -jdk25. وبالتالي، يجمع الإصدار بين إزالة جذور الشهادات وتوجيهات إدارة إصدار بيئة التشغيل. وبما أن التغيير مقتصر على مخازن الثقة في صور Docker، فإن سلوك التوافق ومعالجة مفاتيح المُدققين لا تزال دون تغيير. ويُقدَّم هذا التحديث كإجراء أمان موصى به وليس كترقية طارئة للتوافق، انعكاسًا للنطاق الضيق للتكوينات المتأثرة.
يطبق Besu 26.10.2 تعديلات الثقة المتوازية للشهادات
تم إصدار إصدار 26.10.2 من Besu، العميل الطبقة التنفيذية المُحافظ عليه من قبل النظام البيئي الأوسع نفسه، في 26 أكتوبر 2026، وتطبيق نفس إزالة الجذور في صور Docker الخاصة به. يشير التزامن المتوازي والأهداف المتطابقة للشهادات إلى وعي منسق بحادث eMudhra عبر طبقة عملاء Ethereum القائمة على Java. تعمل عملاء التنفيذ مع عملاء التوافق والخدمات الخارجية لبناء الحمولة وتضمين المعاملات؛ أي مسارات اتصال HTTPS يحافظون عليها تخضع لنفس قواعد التحقق من الشهادات التي تؤثر على Teku. من خلال إزالة الثقة في السلطات المخترقة من صوره، يغلق Besu سطح الهجوم المقابل للمشغلين الذين يعتمدون على توزيعات Docker الخاصة به.
كما هو الحال مع Teku، لا يقوم تحديث Besu تلقائيًا بإصلاح التثبيتات الثنائية المستقلة التي تستخدم بيئة تشغيل Java مدارة بشكل منفصل. يجب على المشغلين في هذه الفئة التحقق من تحديث مخازن الثقة المحلية أو إصدارات Java الخاصة بهم بشكل مستقل. تُظهر الإصدارات المزدوجة للعميل أن كلا الجانبين، الاتصال والتنفيذ، في برنامج عقد Ethereum قد أدركا الاعتماد المشترك على معالجة شهادات Java. وبما أن العديد من المُحققين الإنتاجيين يشغلون كلاً من عميل اتصال مثل Teku وعميل تنفيذ مثل Besu، فإن التحديثات المتزامنة تقلل من احتمال بقاء الثقة المتبقية في الجذور المخترقة على أحد جانبي زوج العقد. ويشير غياب أي استغلال مبلغ عنه قبل الإصدارات إلى أن النافذة العملية كانت محدودة، إلا أن التصحيحات المنسقة لا تزال تمثل تقوية حكيمة ضد فشل تشفيري معروف خارج بروتوكول Ethereum نفسه.
الافتقار الافتراضي لجافا إلى التحقق من الإلغاء يطيل التعرض
تفاصيل تقنية مركزية هي أن التحقق من شهادات Java لا يتحقق من حالة الإلغاء افتراضيًا. حتى بعد إلغاء eMudhra للشهادات الوسيطة وبعد حظرها من قبل منصات كبيرة، استمر أي بيئة تشغيل Java تحتوي على الجذور أو الوسائط المقابلة في مستودع الثقة الخاص بها في قبول الشهادات التي تتسلسل إلى تلك السلطات. أصدر OpenJDK تصحيحات أوقفت أولًا الوسائط المخترقة ثم أزالت لاحقًا أربع جذور مرتبطة بها. ومع ذلك، لم تتلقَ صور Docker التي تحتوي على إصدارات أقدم من Temurin أو OpenJDK هذه التصحيحات تلقائيًا. هذه الفجوة بين إلغاء المستوى المنصي وسلوك بيئات Java المضمنة هي ما استدعى تحديثات الصور الخاصة بالعميل.
للمشغلين الذين يستخدمون إيثريوم، فإن التأثير عملي أكثر من كونه نظري. المُحقق الذي يتضمن تكوينه نقاط نهاية HTTPS للخدمات البعيدة يرث قرارات الثقة الخاصة ببيئة تشغيل Java التي يستخدمها. إذا لم يتم تحديث هذه البيئة أو استبدالها بصورة مُصلحة، يظل العميل مستعدًا لقبول شهادة مزورة. يمكن أن تقلل طريقة TLS المتبادلة أو الشهادات المثبتة من المخاطر في التكوينات المصممة بدقة، إلا أن العديد من التكوينات الإنتاجية تعتمد على التحقق القياسي من مخزن الثقة. وبالتالي، فإن إصدارات Teku وBesu تُذكّر عمليًا بأن برامج العقد المُحَزَّمة تحمل مخزن شهادات خاصًا بها مستقلًا عن نظام المضيف. قد يغفل المشغلون الذين يعاملون صور Docker كصناديق سوداء مغلقة هذا التفصيل حتى يجبرهم حادث خارجي على التحديث. كما يسلط هذا الحدث الضوء على أهمية مراقبة التوصيات الأمنية لـ Java الصادرة من المصادر العليا عند تشغيل عملاء إيثريوم القائمة على Java.
تم تجنب التكوينات الافتراضية لشبكة Mainnet للسطح الهجومي الرئيسي
يُشير توصية Teku بوضوح إلى أن العقدة الافتراضية الرئيسية التي لا تحتوي على أي عناوين HTTPS في تكوينها غير متأثرة ولا تتطلب أي إجراء. ويسقط معظم المُحققين الذين يشغلون عملاء توافق وتنفيذ محليين متجاورين، دون توقيع عن بُعد أو نقاط وصول بeacon عن بُعد، ضمن هذه الفئة. لا تعتمد بروتوكولات اكتشاف النقاط المتماثلة ونشر البيانات المستخدمة من قبل Ethereum على سلطات التوقيع eMudhra، مما يعزز حماية التكوينات القياسية. يتركز الخطر بين المشغلين الذين أدخلوا عمداً اعتمادات HTTPS خارجية لراحة التشغيل، أو توزيع الجغرافي للمفاتيح التوقيعية، أو التكامل مع خدمات بناء الكتل من طرف ثالث. هذا التمييز مهم لتقييم الأثر الكلي على الشبكة. وبما أن الغالبية العظمى من مُحققين الشبكة الرئيسية يعملون ضمن تكوينات لم تتصل أبداً بسلاسل الشهادات المعرضة للخطر، ظل سطح الهجوم النظري محدوداً حتى قبل تطبيق التصحيحات.
قرار فرق العمل على نشر الصور المحدثة على أي حال يحمي مجموعة فرعية من المشغلين الذين يستخدمون الخدمات عن بُعد، وضمان أن عمليات سحب الصور المستقبلية تبدأ من قاعدة متينة. تم تحديد تكوينات Testnet التي تُحمّل الحالة الأولية عبر HTTPS على أنها معرضة للخطر محتملاً، مما يوضح أن نفس منطق الشهادة ينطبق خارج الشبكة الرئيسية. يجب على مشغلي أي شبكة يعتمدون على Bootstrap عبر HTTPS أو نقاط نهاية عن بُعد اعتبار إصدارات أكتوبر 2026 إلزامية لبيئاتهم. سمح الفصل الواضح بين التكوينات الافتراضية وغير الافتراضية بإصدار التحذير بدقة وطمأنة لغالبية مجموعة المدققين.
المُوقِّعون الخارجيون وعقد المُنبِّئ البعيدة تمثل مسارات ذات أعلى مستوى خطر
من بين السيناريوهات التي ذكرها Teku، كانت خدمات التوقيع الخارجي ذات خطورة مُرتفعة. هذه الخدمات تحتفظ بالمفاتيح الخاصة للمُدقق خارج الإنترنت أو في أجهزة متخصصة، وتستجيب لطلبات التوقيع عبر اتصال شبكي. إذا استطاع المهاجم انتحال هوية المُوقِّع من خلال عرض شهادة مزورة، فقد يقبل عميل المُدقق توقيعات تُصرح بعمليات لم يُقصد بها المُشغل أصلًا، بما في ذلك تلك التي تُغيّر إعدادات مستلم الرسوم أو تُطلق عمليات خروج. إن التكوينات التي تُلزم المصادقة المتبادلة عبر TLS تقلل الأثر إلى حجب الخدمة، لأن المهاجم لا يستطيع إكمال مفاوضات المصادقة. حيثما تغيب المصادقة المتبادلة، يكون خطر الحصول على توقيعات قابلة للاستخدام أعلى. عقد Beacon البعيدة تمثل مصدر قلق ذا صلة ولكن مختلف.
المُحقق الذي يُفوّض مهام تنسيق معينة إلى نقطة نهاية إشارة بعيدة يثق في تلك النقطة للمعلومات المتعلقة بالواجبات ومحتويات الكتلة وحالة الشبكة. وبالتالي، يمكن أن يؤثر التزييف الناجح على الكتلة التي يقترحها المُحقق في النهاية، بما في ذلك عنوان مستلم الرسوم المضمن في تلك الكتلة. يقدم مُبنّو الكتل والمرسلون أسطح HTTPS أخرى تُمكن من حقن حمولات مُعدلة. في كل حالة، يجب على المهاجم أولاً تحقيق موقع شبكة يسمح بالاعتراض، ثم تقديم شهادة تقبلها بيئة تشغيل Java غير المُصححة. إن مزيج المتطلبات يضيّق مجموعة الخصوم الواقعيين، إلا أن العائد المحتمل، وهو تحويل الرسوم الناتجة عن اقتراح ناجح، يبرر التصحيحات الدفاعية. يجب على المشغلين الذين يحافظون على وحدات توقيع خارجية أو بنية تحتية بعيدة أن يعطوا أولوية لتحديثات العميل ومراجعة آليات المصادقة على تلك الروابط.
المشغلون الذين يعتمدون ملفات ثنائية مستقلة يواجهون التزامات تحديث Java منفصلة
يمكن لمستخدمي Docker إصلاح المشكلة عن طريق استخراج صور Teku 26.10.3 أو Besu 26.10.2 الجديدة. يعتمد المشغلون الذين يثبّتون العميل كملفات ثنائية أو حزم منفصلة على بيئة تشغيل Java الموجودة على النظام المضيف. بالنسبة لتلك التثبيتات، لا تغيّر إصدارات العميل نفسها مخزن الثقة الخاص بالنظام المضيف. لذلك، يجب على المشغلين التحقق من أن إصدار Java المثبت يحتوي على إصلاحات OpenJDK التي تزيل الجذور المخترقة، أو يجب عليهم تعديل مخزن الشهادات يدويًا. حذّرت Teku بشكل خاص من أن Java 26 انتهت دورة حياتها ولن تتلقى إصدارًا مُصلحًا؛ يتطلب الاستمرار في الدعم والتحديثات الأمنية الانتقال إلى Java 25. هذا الانقسام بين النشرات المُحَزَّمة والنشرات على الخوادم المجردة شائع في بنية Ethereum، ويشكل بندًا عمليًا في قائمة مراجعة للمشغلين.
قائمة إصدارات Java، وتأكيد محتويات خزنة الثقة، والتحقق من عدم وجود نقاط نهاية HTTPS لا تزال موجهة إلى خدمات غير موثوقة تشكل الحد الأدنى من نظافة ما بعد التحديث. نظرًا لأن فشل التشفير الأساسي حدث خارج Ethereum، فإن نفس الالتزامات بتحديث Java تنطبق على أي أدوات أخرى قائمة على Java قد يشغلها المشغل. وبالتالي، فإن إرشادات العميل تخدم كإصلاح محدد لـ Teku و Besu، كونها أيضًا تحفيزًا أوسع للمراجعة الشاملة لمعالجة الشهادات عبر طبقة المشغل. إن عدم معالجة بيئة Java المضيفة تترك مسارات الهجوم النظرية مفتوحة حتى بعد تحديث برنامج العميل نفسه.
لم تحدث أي استغلالات مؤكدة قبل تطبيق التصحيحات
تشير كل من توصية Teku والتقارير المصاحبة لها إلى أنه لم يُلاحظ أي استغلال للثغرة. واتساقًا مع مجموعة الضيقة من الشروط المطلوبة لتنفيذ هجوم ناجح: تشغيل Java غير مُصلح، واتصال HTTPS بخدمة خارجية، ومهاجم قادر على اعتراض هذا الاتصال المحدد مع تقديم شهادة مزيفة. فمعظم المُدققين لم يحققوا أبدًا الشرطين الأولين في نفس الوقت. كما أن الفترة القصيرة بين الإعلان العام عن المفاتيح القابلة للاستعادة في 17 أكتوبر وإطلاق صور العميل قلّصت أكثر من أي وقت مضى النافذة العملية.
عدم ملاحظة الهجمات لا يقلل من قيمة التصحيحات. يمكن أن تظل الثغرات المتعلقة بالشهادات خاملة حتى ظهور خصم يستغل الفرصة. من خلال إزالة جذور المخترقة من مستودعات الثقة الخاصة بـ Docker، قام فرق العميل بحذف قبول الشهادات المزيفة للمشغلين الذين يقومون بالتحديث. كما قدمت هذه الحادثة عرضًا مباشرًا لكيفية تقاطع فشلات التشفير الخارجية مع بنية التخزين في Ethereum، مما دفع المشغلين إلى فحص رسوميات الاعتمادات الخاصة بهم. من المرجح أن تُواجه الحوادث المستقبلية المتعلقة بسلطات الشهادات أو أوقات تشغيل اللغات بردود مشابهة على مستوى العميل، مما يعزز نمط التخفيف السريع والمستهدف.
كيف تمتد مخاطر أمان الشهادات عبر شبكات البلوكشين
حادثة eMudhra ليست فريدة من نوعها على إيثريوم؛ أي برنامج يعتمد على مخازن الثقة القياسية TLS يرث الوضع الأمني لسلطات الشهادات التي يثق بها. يجب على عملاء البلوكشين الذين يدمجون بيئات تشغيل لغات مثل Java أو Go أو غيرها أن تتبع تحديثات الشهادات من المصدر بنفس الحرص الذي تطبقه على تغييرات التوافق. حقيقة أن التكوين الافتراضي لـ Java يستبعد فحص إلغاء الشهادات قد زاد من تأثير الحادثة وأجبر فرق العمل على نشر تعديلات خاصة بمخازن الثقة الخاصة بها. تواجه أنظمة أخرى تُعبّأ فيها بيئات تشغيل طويلة الأمد داخل حاويات مخاطر مشابهة.
لمجتمع الاستثمار في Ethereum، الدرس العملي هو أن أمن التشغيل يمتد أبعد من إدارة المفاتيح وإصدارات العميل ليشمل سلوك التحقق من الشهادات لكل مكون متصل بالشبكة. المشغلون الذين يتبنون التوقيع عن بُعد، أو عقد Beacons الموزعة، أو مُعيدَي طرف ثالث يُدخلون حدود ثقة إضافية يجب مراقبتها. يُظهر احتواء هذا العيب المحدد، من خلال إلغاء صلاحية CA، وحظر المنصات، وتحديثات صور العميل، أن الدفاعات المتعددة الطبقات يمكن أن تعمل عندما تستجيب كل طبقة بسرعة. يظل التنوع المستمر في العملاء ذا قيمة، لأن الت implementations المختلفة قد تكشف أو تخفف من الاعتماديات الخارجية بسرعات مختلفة، مما يقلل من احتمال تأثير فشل شهادة واحدة على مجموعة المدققين بأكملها في نفس الوقت.
المخاوف المتوازية الأخيرة في بنية المُحققين تُبرز الحاجة المستمرة للحذر
وصلت شهادات أكتوبر 2026 في ظل تركيز آخر على الأمان المرتبط بالمحققين. وقد دفعت الكشف السابق عن البنية التحتية لخدمة التخزين والتعامل مع مستلمي الرسوم بالفعل إلى مغادرات طوعية واسعة النطاق وزيادة مراقبة تدفقات المكافآت. بشكل منفصل، عالج المطورون مشكلة توجيه الإيداع في القواعد التجريبية للترقية القادمة Glamsterdam، والتي كانت قد تؤدي إلى تعيين غير صحيح لإيداعات التخزين تحت ظروف تصادم مفاتيح عامة؛ وقد تم دمج هذا الإصلاح في مواصفات التوافق بعد مراجعة إضافية. وتُظهر هذه الأحداث المتزامنة أن اقتصاد المحققين والأمان التشغيلي لا يزالان مجالين نشطين للمراجعة حتى مع استمرار تطور البروتوكول الأساسي.
كان عيب الشهادة مختلفًا في أصله؛ فهو نشأ من جهة شهادات خارجية بدلاً من خطأ في مواصفات إيثريوم أو توافق العميل، لكنه لمس نفس السطح الاقتصادي: وجهة الرسوم والمكافآت التي يكسبها المُقترحون. لذا فإن الاستجابة السريعة للعميل تتماشى مع نمط أوسع يتمثل في اعتبار أي مسار واقعي لتوجيه المكافآت كأولوية عالية. المشغلون الذين يحافظون على إعدادات عملاء متنوعة، ويراقبون عناوين مستلمي الرسوم على السلسلة، ويبقون برامج التوافق والتنفيذ محدثة، هم في وضع أفضل لامتصاص الصدمات الخارجية مثل هذه. إن غياب الخسائر في حالة eMudhra يعزز أن التصحيحات في الوقت المناسب والانضباط في التكوين لا يزالان دفاعات فعالة.
ما الذي يحتاجه مشغلو عقد إيثريوم القيام به بعد الإصدارات الخاصة بشهر أكتوبر
يجب على المُحققين ومشغلي العقد التأكد من تشغيلهم Teku 26.10.3 أو أحدث، وBesu 26.10.2 أو أحدث عند استخدام Docker، أو بيئة تشغيل Java المُصلحة المكافئة عند استخدام الملفات التنفيذية. يجب مراجعة التكوينات لأي نقاط نهاية HTTPS؛ حيث تكون نقاط النهاية هذه ضرورية، فإن TLS المتبادل أو تثبيت الشهادة توفر حماية إضافية. يجب على المشغلين الذين لا يزالون يستخدمون Java 26 الانتقال إلى إصدار مدعوم. يظل مراقبة الكتل المقترحة بحثًا عن عناوين مستلم الرسوم غير المتوقعة طريقة كشف منخفضة التكلفة حتى بعد تحديثات مخزن الثقة. نظرًا لأن المفاتيح الأساسية كانت قابلة للاسترجاع لفترة طويلة قبل اكتشافها، فإن مراجعة واحدة لسجلات الاتصالات التاريخية وقبول الشهادات يمكن أن توفر ضمانًا إضافيًا، على الرغم من عدم الإبلاغ عن أي استغلال.
هذه الخطوات تدريجية أكثر من كونها تحويلية لأغلب المشغلين. لم يتواصل أغلب مُصدّقي الشبكة الرئيسية أبدًا مع سلاسل الشهادات المعرضة للخطر، وبالتالي يشعرون بالحادث فقط كتذكير بضرورة تحديث صور الحاويات وبيئات تشغيل Java. بالنسبة لأولئك الذين يعتمدون على خدمات خارجية، فإن التصحيحات تغلق مسارًا محددًا كان يُهمل سابقًا. سيساعد الحفاظ على الوعي بالإشعارات المتعلقة بالشهادات وبيئات التشغيل من المصدر على تقليل احتمالية حدوث فشلات خارجية مشابهة تخلق فترات مماثلة في المستقبل. إن الإجراء المنسق من فريقي Teku وBesu يوفر الحل الفوري نموذجًا للتعامل مع الحادث الكريبتوجرافي الخارجي القادم الذي يتقاطع مع برامج عميل Ethereum.
الأسئلة الشائعة
ما الذي كان خاطئًا تمامًا في شهادات eMudhra؟
تم إنشاء المفاتيح الخاصة لثمانية سلطات شهادات وسيطة تعملها eMudhra باستخدام عشوائية غير كافية أثناء مراسم المفاتيح لعام 2025. كانت هذه المفاتيح قابلة للاسترجاع من الشهادات العامة، مما يسمح لأي شخص يحصل عليها بإصدار شهادات مزيفة ستظل البرامج تثق بها كأنها صادرة من تلك السلطات. تم استخدام ستة من الوسطاء لـ TLS واثنين لتوقيع الكود. ألغت eMudhra هذه الشهادات بعد اكتشافها في 17 أكتوبر 2026، وحظرت المنصات الكبرى المواد المرتبطة بها لاحقًا.
هل خسر أي من المُصدّقين مكافآت ETH بسبب هذا العيب؟
لم يتم الإبلاغ عن أي استغلال مؤكد أو فقدان للمكافآت. تشير التوصيات الخاصة بالعميل والتغطية المتزامنة إلى أنه لم يُلاحظ أي هجمات. إن مزيج الشروط المطلوبة، وهو تشغيل Java غير مُصلح بالإضافة إلى اتصال HTTPS نشط بخدمة خارجية معرضة للخطر، قلل من سطح الهجوم الواقعي، كما أن الإصدار السريع لصور Docker المُصلحة قلل من التعرض أكثر.
هل تتأثر عقدة Ethereum الرئيسية الافتراضية؟
التكوينات الافتراضية لـ Teku على الشبكة الرئيسية التي لا تحتوي على عناوين HTTPS غير متأثرة ولا تتطلب أي إجراء. تنطبق نفس المبدأ على إعدادات Besu المماثلة. التعرض محدود بالمشغلين الذين يُكوّنون بشكل متعمد نقاط نهاية HTTPS عن بُعد لعقد البث، أو توقيعات خارجية، أو مُنشئين، أو خدمات مشابهة.
لماذا ظلت بيئة تشغيل جافا عرضة للهجمات بعد إلغاء الشهادات؟
لا يتحقق Java من حالة إلغاء الشهادة افتراضيًا. حتى بعد إلغاء وحظر الوسطاء من قبل المتصفحات وأنظمة التشغيل، استمرت أي تثبيتات لـ Java تحتوي على الجذور المقابلة في مستودع الثقة الخاص بها في قبول الشهادات التي تربط بها. لذا كانت صور Docker العميلة التي تحتوي على أوقات تشغيل أقدم بحاجة إلى إزالة صريحة للجذور.
ماذا يجب على المشغلين الذين يستخدمون صور Docker فعله؟
اجمع وشغّل إصدار Teku 26.10.3 أو أحدث وإصدار Besu 26.10.2 أو أحدث. هذه الصور لم تعد تثق بالجذور المخترقة. تحديث نظام المضيف وحده لا يُحدث Runtime داخل حاوية موجودة؛ يتطلب الأمر صورة جديدة.
ماذا عن المشغلين الذين ينفذون العميل كملفات ثنائية مستقلة؟
يجب على هذه الوحدات تحديث أو إعادة تكوين تثبيت Java الخاص بالخادم بحيث يدمج إصلاحات OpenJDK، ويُزيل الجذور المتأثرة. Java 26 انتهت دورة حياتها ولن تتلقى إصدارًا مُصلحًا؛ يُوصى بالانتقال إلى Java 25. تحديثات برنامج العميل نفسها لا تغيّر مخزن الثقة الخاص بالخادم.
إخلاء المسؤولية: يتم تقديم هذه المعلومات العامة عن السوق، والتي قد تكون من مصادر خارجية أو تجارية أو راعية، لأغراض المرجعية والتعليم فقط ولا تشكل نصيحة مالية أو استثمارية، أو عرضًا أو دعوة أو ضمان. نحن ننفي أي مسؤولية عن دقتها أو اكتمالها أو موثوقيتها وأي خسائر ناتجة عنها. الاستثمار/التداول محفوف بالمخاطر؛ الأداء السابق لا يضمن نتائج مستقبلية. يجب على المستخدمين إجراء البحث، واتخاذ قرارات حكيمة، وتحمل المسؤولية الكاملة. للحصول على مزيد من التفاصيل، يرجى الرجوع إلى شروط الاستخدام وإخلاء المسؤولية عن المخاطر الخاصين بـ KuCoin.
اخلاء المسؤوليه: تُرجمت هذه الصفحة باستخدام تقنية الذكاء الاصطناعي لراحتك. للحصول على المعلومات الأكثر دقة، ارجع إلى النسخة الإنجليزية الأصلية.