ثغرة حرجة قبل المصادقة في MongoDB (CVE-2026-118383) قد تُسقط خوادم متأخرة عند تجاوز الفشل

أصدرت MongoDB إصدارات مُصلَحة للثغرة CVE-2026-118383، وهي ثغرة حرجة قبل المصادقة في خادم MongoDB قد تُسقط عضوًا في مجموعة النسخ المتماثل إذا فاز في الانتخابات وهو لا يزال متأخرًا في النسخ بعد تلقيه طلبين غير مصادقين. الثغرة من نوع استخدام الذاكرة بعد تحريرها، وقيّمتها MongoDB بـ 9.5 من 10 على مقياس CVSS 4.0. وتشمل الأعضاء المتأثرة أعضاء مجموعة النسخ المتماثل، إضافة إلى أعضاء خوادم الشارد وخوادم التهيئة في العناقيد المجزأة، أما mongod المستقل، وهو خادم واحد خارج أي مجموعة نسخ متماثل، فغير متأثر.

كيف تعمل الثغرة

في الإصدارات المصابة، لا يوقف تفعيل المصادقة الطلبين. فهما أمران من نوع ping يحملان قيمة readConcern.afterOpTime، ويطلب كل منهما من الخادم الانتظار حتى تبلغ عملية النسخ نقطة معينة، فيسجّل الخادم إشعار انتظار يُسمى waiter. ولا تنتهي صلاحية هذه الإشعارات، وتبقى في مكانها حتى يُعاد تشغيل العضو أو يتراجع أو يتنازل عن دور العقدة الأساسية. ويحدث الانهيار عندما يفوز العضو الذي تلقاها في انتخابات لاحقة رغم تأخره عن عضو آخر: عند انتهاء مرحلة اللحاق يعمل التنظيف مرتين ويعيد استخدام ذاكرة حُررت بالفعل، فينهار الأساسي الجديد قبل أن يقبل أي عمليات كتابة. وقال الباحثون إن الانهيار، بعد تحقق هذه الشروط، لا يعتمد على الفوز في سباق توقيت، وإن المهاجم لا يستطيع أن يجعل العضو المستهدف متأخرًا أو أن يجعله يفوز في الانتخابات، ولا أن يرى متى يحدث أي من الأمرين.

الإصدارات المتأثرة والإصلاحات

أصدرت MongoDB إصدارًا مُصلَحًا لكل فرع متأثر، وكل إصدار أقدم في الفرع متأثر حتى أول إصدار فيه. وتحتاج عمليات النشر ذاتية الإدارة إلى الإصدار المُصلَح على كل عضو في مجموعة النسخ المتماثل، وبعد الترقية ينبغي للمسؤولين التحقق من الإصدار الذي يعمل عليه كل عضو، بما في ذلك الأعضاء داخل الحاويات وأي عضو كان غير متصل أثناء الصيانة. وتتلقى عناقيد MongoDB Atlas إصدارات مُصلَحة تلقائيًا أثناء الصيانة، وعلى العملاء الذين يؤجلون الصيانة تطبيق الترقية في أقرب وقت ممكن. ولا يظهر الفرع 8.2 بين الإصدارات المتأثرة المدرجة، وأحدث إصداراته هو 8.2.12، لكن إثبات مفهوم نُشر على GitHub يفيد بأن 8.2.12 أظهر الخلل أيضًا في اختبار معملي استخدم إعدادًا مخصصًا للاختبار فقط. وبحسب جدول دورة حياة الشركة، وصل الفرع 8.2 إلى نهاية العمر في 31 يوليو.

الكشف والتخفيف

إلى أن يصبح تحديث العضو ممكنًا، ينصح الباحثون بتقييد الوصول الشبكي إلى قاعدة البيانات على الأنظمة التي تحتاج إليه فقط؛ وهذا يحدّ من الجهات القادرة على إرسال الطلبين لكنه لا يُصلح الخلل. وللبحث عن آثار الزرع أو عن انهيار، تحققوا في السجلات المهيكلة من: إدخال COMMAND Slow query بالمعرّف 51803 لطلب ping غير مصادق يحمل readConcern.afterOpTime وانتهى بـ MaxTimeMSExpired؛ وعضو يدخل مرحلة لحاق الأساسي بالمعرّف 21359 ثم يخرج منها مرتين بالمعرّف 21363 في انتقال واحد؛ وإشارة قاتلة أو أثر استدعاء عكسي بعد هذين الخروجين يتضمن CatchupState::abort_inlock(). وقد تصل الطلبات قبل تجاوز الفشل، لذا ينبغي فحص سجلات أقدم للعضو نفسه أيضًا.

مزاعم تنفيذ الشيفرة

تقول MongoDB إن الخلل قد يؤدي أيضًا إلى تنفيذ شيفرة عشوائية داخل عملية الخادم في ظروف معينة. لكن الباحثين قالوا إنهم "لم يحققوا تنفيذ شيفرة" في المختبر، ولا تُظهر نتائجهم مدى تكرار نجاح الهجوم في إعدادات أخرى. ويعيد كود إثبات المفهوم إنتاج الخلل في مجموعة نسخ متماثل معملية؛ ويتطلب وضعه الموثوق إعدادًا مخصصًا للاختبار فقط لا يستطيع مهاجم بعيد تفعيله، وأثره المعلن هو انهيار أو تلف في الذاكرة. وفي اختبار إثبات المفهوم المعملي، الذي جرى مع تعطيل المصادقة، قبل الإصدار المُصلَح 8.0.37 الإشعارات المزروعة لكنه نفّذ التنظيف مرة واحدة فقط.

المصادر: The Hacker News