CVE-2026-31431: ثغرة تصعيد صلاحيات في نواة لينكس مُدرجة في كتالوج KEV التابع لـCISA

CVE-2026-31431: ثغرة تصعيد صلاحيات في نواة لينكس مُدرجة في كتالوج KEV التابع لـCISA

باختصار

CVE-2026-31431 هي ثغرة تصعيد صلاحيات في نواة لينكس، تُستغل حاليًا بشكل فعلي وتم إدراجها في الكتالوج الرسمي للثغرات المعروفة والمُستغلة (KEV) التابع لـCISA [2]. يجب على أي منظمة تُشغّل خوادم لينكس تطبيق تحديث النواة على الفور وتدقيق عمليات الوصول الأخيرة على الأنظمة المتأثرة.

ما هي ولماذا تُعد مهمة

نواة لينكس هي جوهر نظام التشغيل الموجود في الغالبية العظمى من الخوادم المؤسسية وبيئات السحابة وأجهزة الشبكات. تصف CVE-2026-31431 خللًا في النقل غير الصحيح للموارد داخل تلك النواة [1] يفتح الباب أمام تصعيد الصلاحيات: يمكن لمهاجم لديه بالفعل وصول محلي إلى النظام استغلال هذا الضعف للحصول على صلاحيات إدارية (root) دون تصريح [2].

أدرجت CISA هذه الثغرة في كتالوج KEV الخاص بها -المخصص حصريًا للثغرات التي توجد أدلة مؤكدة على استغلالها الفعلي- [2]، مما يشير إلى أن الخطر ليس نظريًا: هناك جهات خبيثة تستغلها في الوقت الحالي.

من فريق التحليل في OCIRIA نصنّفها ضمن فئة الخطر التشغيلي الحرج، وهو تقييم خاص بنا يعكس التأثير المحتمل على أصول الأعمال. هذا التصنيف الداخلي مستقل عن مستوى الخطورة الذي قد يحدده NVD [1] رسميًا في حينه، ويستند إلى حقيقة أن السيطرة الكاملة على خادم ما تُعرّض للخطر سرية البيانات واستمرارية الأعمال والامتثال التنظيمي.

من يتأثر بها

تؤثر هذه الثغرة في أي منظمة:

• تُشغّل خوادم فعلية أو افتراضية تعمل بنظام لينكس (مراكز بيانات خاصة، استضافة مشتركة، أو سحابة خاصة).
• تستخدم بنية تحتية سحابية بها نسخ افتراضية من لينكس لم يتم تحديثها (AWS EC2، Azure VMs، Google Compute Engine، إلخ).
• تُدير حاويات أو منصات Kubernetes تشترك في نواة النظام المضيف.
• لديها موظفون أو موردون لديهم وصول محلي أو عن بُعد إلى تلك الأنظمة.

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

كيف تعرف ما إذا كنت عرضة للخطر

الخطوة الأولى هي معرفة إصدارات نواة لينكس التي تعمل في بنيتك التحتية. بعض المؤشرات الأساسية:

• جرد الإصدارات: نفّذ الأمر uname -r على كل خادم لمعرفة الإصدار الدقيق للنواة. إذا لم تكن لديك رؤية مركزية على جميع الأنظمة، فهذه مشكلة أمنية في حد ذاتها.
• التحديثات المطبّقة مؤخرًا: تحقق مما إذا كانت فرق الأنظمة قد طبّقت تحديثات للنواة في الأسابيع الأخيرة. في توزيعات مثل RHEL وDebian وUbuntu أو SUSE، يجب أن تكون الإشعارات الأمنية المقابلة منشورة من قبل مزوّد التوزيعة.
• التعرّض في الوصول: راجع أي المستخدمين أو الخدمات لديهم وصول محلي أو صدفة تفاعلية (shell) إلى الخوادم المتأثرة. اتساع نطاق الوصول يزيد بشكل مباشر من احتمالية الاستغلال.
• السطح المُعرَّض: تدقيق أي أنظمة لينكس يمكن الوصول إليها من الإنترنت أو من شبكات داخلية غير مقسّمة بشكل جيد يساعد على تحديد أولويات التحديث الأكثر إلحاحًا.

كيف تحمي نفسك

1. طبّق تحديث النواة فورًا [2]. راجع النشرة الأمنية لتوزيعة لينكس الخاصة بك (Red Hat، Canonical، Debian، SUSE، إلخ) وقم بالتحديث إلى إصدار النواة الذي يعالج CVE-2026-31431. لا تؤجّل هذه الخطوة.

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

3. دقّق عمليات الوصول الأخيرة. راجع سجلات المصادقة (/var/log/auth.log، journalctl) بحثًا عن عمليات وصول غير معتادة أو تصعيدات صلاحيات سابقة لتطبيق التحديث.

4. قيّد الوصول المحلي وعن بُعد. طبّق مبدأ الحد الأدنى من الصلاحيات: فقط المستخدمون الذين يحتاجون فعلًا إلى ذلك يجب أن يمتلكوا وصول شل إلى خوادم الإنتاج.

5. فعّل تنبيهات الأمان الخاصة بتوزيعتك. اشترك في قنوات الإشعارات الأمنية لمزوّد لينكس الخاص بك لتلقي إشعارات مستقبلية بشكل استباقي.

6. قسّم الشبكة. تقليل الاتصال بين الأنظمة يحد من قدرة المهاجم الذي حصل على وصول أولي على التحرك الجانبي.

---

أسئلة شائعة

هل يكفي وجود لينكس في السحابة لتكون محميًا؟

ليس تلقائيًا. يدير مزوّدو الخدمات السحابية البنية التحتية الفعلية، لكن مسؤولية تحديث نظام التشغيل الخاص بالنسخ الافتراضية تقع عادةً على عاتق العميل. تحقق من سياسة التحديث الخاصة بمزوّدك وحالة نسخك الافتراضية.

هل يمكن لمهاجم خارجي استغلال هذه الثغرة مباشرة عبر الإنترنت؟

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

هل هناك إجراء احتواء أثناء تطبيق التحديث؟

أثناء تحضير التحديث، يُعد تقليل عدد المستخدمين الذين يمتلكون وصول شل، ومراجعة أذونات SUID، وزيادة مراقبة أحداث الصلاحيات من الإجراءات التي تقلل من نافذة التعرض، رغم أنها لا تُغني عن التحديث [2].

كيف أتأكد من أن التحديث قد طُبّق بشكل صحيح؟

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

المصادر

• [1] NVD — الصفحة الرسمية لـCVE-2026-31431: nvd.nist.gov/vuln/detail/CVE-2026-31431
• [2] CISA — كتالوج الثغرات المعروفة والمُستغلة (KEV): cisa.gov/known-exploited-vulnerabilities-catalog