CVE-2026-98432: لا تزال Ubuntu وRHEL بلا تصحيح، وقد كتب نموذج Claude الاستغلال بالفعل

لا تجتمع الحقيقتان بشأن CVE-2026-98432 على نحو مريح. فهي ثغرة استخدام بعد التحرير (use-after-free) في مصافحة IPv4 TCP في نواة Linux، ويمكن الوصول إليها عبر الشبكة من دون تسجيل دخول ومن دون تفاعل، وقد منحها فريق CVE في النواة تقييمًا قدره 9.8. واعتبارًا من 30 أكتوبر 2026، لا تملك Ubuntu أي إصلاح صادر لإصدارات 22.04 و24.04 و26.04 أو 26.10، وتُدرج Red Hat إصدارات RHEL 8 و9 و10 ضمن المتأثرة، من دون إصلاح ومن دون تخفيف معتمد. أما الحقيقة الثانية فهي أنه في 27 أكتوبر، نشرت Anthropic بحثًا يفيد بأن نموذج Claude غير المُصدَر أنتج إثبات مفهوم عاملًا لتحقيق root عن بُعد دون مصادقة ضد خادم عليه مستمع MPTCP — نحو 48 دقيقة لتسريب عنوان في النواة وخمس دقائق إضافية للوصول إلى تنفيذ الأوامر.

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

الخلل البرمجي، في فقرة واحدة

عند إعداد اتصال TCP، تُسلَّم خيارات IP الملحقة بالحزمة الواردة إلى المقبس الجديد بدلاً من نسخها. إذا أُعيد إرسال حزمة المصافحة، فقد تتم معالجة الحزمة على وحدة معالجة مركزية مختلفة عن التي تملك مخزن الخيارات المؤقت — ويمكن لتلك الوحدة الثانية قراءة ذاكرة سبق أن حرّرتها الأولى. ويوجد سباق مماثل في مسار ترحيل الطلبات. يبدأ النطاق المتأثر من نواة 4.4، أي معظم الأجهزة التي لا تزال تشغّل نواة مدعومة. الإصلاح في المنبع، الالتزام code>e3f33b0a1d89/code>، يؤخر تحرير مخازن الخيارات المؤقتة حتى لا يبقى أي نواة معالجة أخرى قادرة على الاحتفاظ بمرجع.

تتبيّن قابلية الاستغلال من الآلية نفسها: لا مصادقة، ولا تفاعل من المستخدم، ومسار يمكن الوصول إليه عبر الشبكة، وحالة سباق قابلة لإعادة المحاولة. وملخّص Anthropic نفسه لسبب كون PoC عمليًا هو تلك الخاصية بالضبط — فخسارة السباق تُفشل مصافحة واحدة بدلًا من إسقاط الجهاز، لذا يعيد المهاجم المحاولة.

ثلاثة موردين، ثلاثة أرقام خطورة

تقسيم الدرجات هو الجزء الجدير بالاستيعاب، لأنه يحدد ما إذا كان الماسح الخاص بك سيفتح تذكرة هذا الأسبوع.

• فريق CVE للنواة — 9.8، حرجة. يمكن الوصول إليها عبر الشبكة، ولا تتطلب امتيازات، ولا تتطلب تفاعلاً.

• Red Hat — 8.1، مهم. موقف الشركة هو أن الفوز في السباق صعب عمليًا.

• Ubuntu — أولوية عالية، دون نشر أي درجة رقمية في الصفحات التي تم فحصها.

الفجوة بين 9.8 و8.1 ليست خلافًا حول العيب البرمجي؛ بل خلاف حول احتمال الفوز في سباق. وكلا التقييمين يمكن الدفاع عنه، والفرق مهم تشغيليًا: فـ9.8 مع PoC عام يمثل حالة طوارئ، و8.1 مع سباق صعب يمثل إصلاحًا مجدولًا. وحتى ينشر أحد أرقام إعادة إنتاج على عتاد حقيقي، فإن القراءة الصادقة هي أن السباق قابل للفوز، لأنه يُقال إن نموذجًا حدوديًا فاز به.

من لديه حل، ومن ليس لديه؟

اعتبارًا من 29–30 أكتوبر، تبدو الصورة متفاوتة على نحو يوقع من يفترضون أن النواة المستقرة تعني نواة مُرقّعة.

• Debian 12 bookworm — تم الإصلاح في 6.1.190-1 عبر DLA-4841-1.

• Debian 13 trixie — تم الإصلاح في 6.12.113-1 عبر DSA-6568-1.

• Ubuntu 22.04، 24.04، 26.04، 26.10 — لا يوجد إصلاح صادر؛ العمل جارٍ.

• Ubuntu 16.04, 18.04, 20.04 — عرضة للثغرة، ولم يصدر أي إصلاح.

• RHEL 8، 9، 10 وOpenShift 4 — متأثر، لا يوجد إصلاح، ولا يوجد تخفيف معتمد من Red Hat.

• RHEL 6 و7 — غير متأثرة.

• Amazon Linux 2023 — أُفيد بأن النواة 6.18 أصبحت مُصلحة؛ Oracle Linux UEK أُفيد بأنها مُصلحة؛ SUSE تفيد بأن بعض الإصدارات أصبحت مُصلحة وأخرى لا تزال قيد الاختبار، دون تسمية الإصدارات.

الإصدارات المستقرة من المنبع التي تحمل الإصلاح هي 5.10.272 و5.15.223 و6.1.190 و6.6.159 و6.12.113 و6.18.56 و7.2.10 و7.3 — وهي القائمة التي ينبغي التحقق منها مقابل البناء الخاص بك إذا كنت تُجمّع نواتك بنفسك بدلًا من الاعتماد على حزمة من التوزيعة.

لماذا يستمر ظهور MPTCP

العيب ليس خاصًا بـ MPTCP، وهنا يخطئ قدر كبير من التغطية. تتعامل Red Hat مع أي خدمة TCP قابلة للوصول باعتبارها محفزًا محتملًا. ما يوفره MPTCP هو مسار مُثبت، وما يوفّر حركة المرور هو Go: الإصدار 1.24 وما بعده يفعّل بروتوكول TCP متعدد المسارات افتراضيًا لمقابس الاستماع في Linux عندما يكون MPTCP مفعّلًا في النواة. وحذّر فريق الأمن لدى Go من هذا المزيج في 29 أكتوبر.

إذن، فإن «تعطيل MPTCP» يزيل المسار الذي أثبتته Anthropic، وليس الثغرة نفسها. إنه إجراء مؤقت يمكن الدفاع عنه مع تحفّظ محدد: فهو جدير بالتنفيذ على خدمات Go اليوم، وليس بديلاً عن نواة مُرقّعة.

الفحوصات قصيرة:

• code>ss -Mltnp/code> — يسرد المقابس التي تستخدم MPTCP حاليًا.

• code>net.mptcp.enabled/code> — ما إذا كانت ميزة النواة مفعّلة على الإطلاق.

• code>net.ipv4.tcp_migrate_req/code> — معطّل افتراضيًا؛ وإذا قمت بتشغيله، فأطفئه مرة أخرى.

بالنسبة إلى Go تحديدًا، code>GODEBUG=multipathtcp=0/code> وقت التشغيل، أو code>godebug/code> كسطر في code>go.mod/code>، يجعل الملف الثنائي يختار عدم المشاركة.

لا شيء من هذه معتمد من المورّد. وتقول Red Hat صراحةً إنه ليس لديها أي إجراء تخفيف يستوفي معيارها الخاص، وهذه جملة أنفع من قائمة بحلول التفافية مبنيّة على الأمل.

ما الذي نشرته Anthropic فعليًا

البحث محدود ودقيق. عند تزويد نموذج Claude غير المُصدَر بثغرة CVE وهدفٍ لديه مستمع MPTCP، أنتج سلسلة استغلال سرّبت عنوانًا في النواة خلال نحو 48 دقيقة، ثم وصلت إلى تنفيذ الأوامر بعد نحو خمس دقائق. ولم تنشر Anthropic الاستغلال، وحتى 29 أكتوبر لم يُبلِغ أيّ من البائعين ولا سجل CVE عن هجمات على أرض الواقع؛ كما أن الثغرة ليست في كتالوج KEV الخاص بـ CISA. وفي 30 أكتوبر، نشر مستودع GitHub تابع لطرف ثالث أدوات مخبرية لإثارة حالات سباق وتسريب الذاكرة — منصة إعادة إنتاج، من دون الوصول إلى تنفيذ كامل للشيفرة.

ذلك المزيج هو الجزء المثير للاهتمام. القدرة مُبرهَنٌ عليها، والسلاح محجوب، والتفصيل التمكيني — خاصية إعادة المحاولة التي تحوّل سباقًا هشًا إلى سباق موثوق — متاحٌ للعموم في نصّ نثري. وكل من يستطيع إعادة إنتاج السباق يعرف الآن لماذا يستحقّ الاستمرار فيه.

ماذا تفعل هذا الأسبوع

• طبّق التصحيح وأعد التشغيل حيثما يوجد إصلاح. إن إصلاح النواة المثبَّت دون إعادة تشغيل ليس إصلاحًا؛ تحقق باستخدام code>uname -r/code>.

حيث لا يتوفر تصحيح لتوزيعتك — Ubuntu 22.04 حتى 26.10، وRHEL 8 حتى 10 — قرّر الآن ما إذا كنت ستأخذ تصحيحًا مباشرًا من المورّد، أو تنتقل إلى إصدار تم إصلاحه، أو تقبل التعرّض للخطر مع إيقاف MPTCP على خدمات Go.

• احصر مدى تعرّض MPTCP بدلًا من افتراض أنه معطّل. تغيّر الافتراضي في Go، لا في إعداداتك، وتغيير الافتراضي غير مرئي في فرق الإعدادات.

• تدرّب على إعادة التشغيل. هذا النوع من الإصلاحات يتطلب إعادة تشغيل كاملة، والمنظمات التي ستخسر أكبر قدر من الوقت هي تلك التي تكتشف خطة تجاوز الفشل الخاصة بها أثناء نافذة الصيانة.

السؤالان اللذان يطرحهما هذا CVE في الواقع

الأول يتعلق بتوليد الاستغلال، وهو ليس فلسفيًا. فقد وجد نموذج تسلسلًا لم يجده عدد كبير جدًا من الباحثين البشريين، على هدف ذي إعداد تمكيني محدّد، في أقل من ساعة. وسواء نُشر الاستغلال أم لم يُنشر، فقد تغيّر الجدول الزمني: فالفترة بين إشعار عام واستغلال فعّال تُقاس الآن مقابل نماذج تقرأ الإشعار.

الثاني يتعلق بما يعنيه الترقيع عندما لا يستطيع الموردون الترقيع. التوزيعة التي تزوّدك بنواة والنواة التي تحمل الإصلاح ليستا الكيان نفسه، والفجوة بينهما هي بالضبط الموضع الذي تسكن فيه هذه الثغرة بالنسبة لمعظم قرّاء هذا المنشور. إن OrcaRouter AI Incident Archive يفهرس حوادث كهذه استنادًا إلى مصادرها الأولية ودرجة خطورتها ودرجة الثقة فيها، وهي النسخة من هذه القصة التي تستحق الاحتفاظ بها بعد أن تتحرك دورة الأخبار.

ما يجب تجنّبه هو تصنيف هذا تحت بند "انتظار المورّد". فصفحة المورّد نفسه تقول إنه لا يوجد شيء يُنتظر بعد.

ملاحظة حول المصادر: الآلية والنطاق المتأثر منذ النواة 4.4 والالتزام upstream code>e3f33b0a1d89/code> وقائمة الإصدارات المستقرة وإرشادات التخفيف مأخوذة من سجل CVE ومن استشارات التوزيعات التي اطُّلِع عليها في 30 أكتوبر 2026. وتقييمات 9.8 و8.1 و«High» من أوبونتو هي تقييمات فريق CVE الخاص بالنواة وريد هات وكانونيكال على التوالي. وحالة الترقية لكل توزيعة مأخوذة من DLA-4841-1 وDSA-6568-1 الخاصين بديبيان، ومن صفحتي CVE الخاصتين بريد هات وأوبونتو، ومن بيانات المورّدين في التاريخ نفسه. والجدول الزمني لإثبات المفهوم، ورقمَا 48 دقيقة وخمس دقائق، وخاصية إعادة المحاولة مأخوذة من بحث أنثروبيك في 27 أكتوبر، الذي احتفظ بالاستغلال. ويُوصَف مستودع المختبر المؤرَّخ 30 أكتوبر بأنه طرف ثالث وليس مستودعنا.