ثغرة IPv6 تمنح صلاحيات root، والإصدار لا يكفي وحده للحكم

نشر GovCERT.HK في 31 أغسطس 2026 تحذيرًا عالي الخطورة من CVE-2026-53362، وهي ثغرة محلية في مسار IPv6 بنواة Linux قد ترفع مستخدمًا غير مميز إلى صلاحيات root. ويذكر تنبيه GovCERT.HK ورود تقارير عن استغلالها فعليًا، ويوصي مسؤولي الأنظمة بتثبيت تحديثات مورّد التوزيعة.

يرتبط التحذير الصادر في 31 أغسطس باستغلال عملي، لا بإثبات نظري فقط. فقد وثقت تغطية SecurityWeek استخدام الثغرة في 19 يوليو داخل بيئة محلية للحصول على root على عقدة Linux، ثم إضافتها إلى كتالوج CISA للثغرات المعروفة الاستغلال في 27 أغسطس. مع ذلك، لا تجعلها هذه الحالة ثغرة دخول مباشر من الإنترنت: المسار المعروف يحتاج قدرة على تنفيذ تعليمات محليًا ونواة تحتوي الشيفرة المتأثرة.

الخلل يبدأ من UDPv6 وينتهي خارج حدود الذاكرة

تقع المشكلة في الدالة __ip6_append_data() عند تكوين رزمة UDPv6 مجزأة. يوثق متتبع Debian الأمني أن حساب fraggap في مسار التخصيص المعتمد على الصفحات يجعل المنطقة الخطية من socket buffer أصغر من المطلوب، فتتجاوز عملية النسخ نهاية المخزن وتصل إلى بنية skb_shared_info.

يستطيع مستخدم محلي غير مميز بلوغ هذا المسار عبر مقبس UDPv6 عند الجمع بين MSG_MORE وMSG_SPLICE_PAGES. ويشترط فرع IPv6 أن تكون النواة مبنية مع CONFIG_IPV6=y؛ لذلك لا يثبت مجرد وجود عنوان IPv6 أن النظام متأثر، كما لا يزيل إغلاق منفذ شبكي خللًا يمكن تشغيله من عملية محلية.

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

شجرة التحقق تبدأ بالتوزيعة والحزمة

الجواب العملي لكل خادم يبدأ بهوية المنتج، لا برقم نواة عام. على المسؤول تحديد التوزيعة وإصدارها، ثم اسم حزمة النواة التي توفر البناء الجاري، وحالة CONFIG_IPV6، وأخيرًا حكم المتتبع الأمني للمورّد على الفرع نفسه.

1. حدد المنتج المدعوم: راجع /etc/os-release لمعرفة التوزيعة والإصدار، وتأكد من أن الفرع ما زال يحصل على تحديثات أمنية.
2. اربط النواة الجارية بالحزمة: يعرض uname -r البناء المحمّل حاليًا، ثم يلزم استخدام مدير الحزم لتحديد حزمة linux-image أو kernel أو kernel-core المقابلة وإصدارها الكامل.
3. افحص إعداد البناء: ابحث عن CONFIG_IPV6=y في ملف الإعداد الخاص بالنواة الجارية داخل /boot، أو في /proc/config.gz إذا كان متاحًا. غياب ملف الإعداد ليس دليلًا على تعطيل IPv6، بل يستلزم الرجوع إلى بيانات بناء الحزمة.
4. طابق صف المورّد: افتح سجل CVE الخاص بالتوزيعة، واختر المنتج والفرع ونوع النواة الصحيح، ثم قارن إصدار الحزمة كاملًا بالإصدار الذي صنفه المورّد على أنه مصحح.
5. تحقق بعد التحديث: تثبيت حزمة جديدة لا يبدل النواة العاملة تلقائيًا دائمًا. بعد إعادة التشغيل وفق إجراءات الخدمة، قارن البناء الجاري بالحزمة المصححة المثبتة.

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

لماذا لا يحسم uname حالة التأثر؟

تحافظ توزيعات Linux عادة على فرع نواة مستقر وتنقل إليه إصلاحات أمنية من فروع أحدث. نتيجة ذلك أن حزمة تحمل رقمًا عامًا قديمًا نسبيًا يمكن أن تكون مصححة، بينما لا تكفي مقارنة الرقم المختصر بحد upstream لإثبات الحالة الأمنية.

كما قد تكون الحزمة المصححة مثبتة على القرص فيما يواصل الخادم تشغيل البناء السابق حتى إعادة التشغيل. وهناك أيضًا حزم منفصلة للنواة العامة والسحابية وبيئات real-time؛ وقد تختلف لاحقة الحزمة أو مسار التحديث بينها رغم تشابه الجزء الأول من رقم الإصدار.

يظهر هذا الفرق بوضوح في بيانات Debian الحالية: تتغير الحالة بحسب حزمة المصدر والفرع الأمني، ويُسجل فرع linux الأصلي في Bullseye على أنه غير متأثر لغياب الشيفرة الضعيفة، مع وجود حزمة linux-6.1 منفصلة لها إصدار إصلاح خاص. لذلك يجب مقارنة الاسم والإصدار الكاملين بالصف الصحيح، لا نقل حكم فرع إلى آخر لمجرد تشابه ناتج uname.

الأولوية تعتمد على موطئ القدم المحلي

ترتفع الأولوية في الأنظمة متعددة المستخدمين، وعقد التطوير والبناء، ومضيفي الحاويات، وبيئات الاستضافة المشتركة، لأن مستخدمًا أو عملية غير موثوق بها قد تمتلك أصلًا القدرة اللازمة لتشغيل UDPv6 محليًا. أما الخادم الذي لا يتيح حسابات shell عامة فليس محصنًا تلقائيًا؛ فقد يأتي التنفيذ المحلي بعد اختراق خدمة أو مهمة آلية.

في المقابل، لا ينبغي توسيع وصف الخطر إلى جميع الأجهزة التي تستخدم IPv6. يلزم اجتماع الوصول المحلي والشيفرة القابلة للتشغيل وحالة حزمة غير مصححة، وقد يستبعد المورّد منتجًا محددًا لأن الشيفرة غير موجودة فيه أو لأن الإصلاح نُقل إليه من دون تغيير رقم النواة الرئيسي.

ما ثبت وما يبقى خاصًا بكل خادم

الثابت حتى صدور تحذير 31 أغسطس 2026 هو وجود ثغرة رفع صلاحيات محلية في مسار UDPv6، وإمكان الوصول إلى root عند نجاح الاستغلال، ووجود واقعة استغلال منشورة. لكن التحذير العام لا يستطيع وحده تقرير حالة كل خادم، لأن التوزيعات تبني حزمًا وفروعًا مختلفة.

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

اقرأ أيضًا:

• ثغرة Entra ID سجلت 10 من 10، ثم سحبت Microsoft ادعاء استغلالها
• CISA تضع مهلة 29 أغسطس لإغلاق ثغرة NetScaler المستغلة