ذكاء OpenAI الاصطناعي يكتشف 948 طريقة للحصول على صلاحيات Root في Linux: فهل خادم الـ API لديك محمي؟

تغير ثغرات الوصول إلى جذر النظام (root) الـ 948 التي كشفت عنها OpenAI في نظام Linux افتراضًا أساسيًا لدى فرق واجهات برمجة التطبيقات (API): موطئ القدم محدود الصلاحيات على خادم لم تُثبّت عليه التحديثات الأمنية قد لا يظل محدود الصلاحيات لفترة طويلة. تحقق من نواة النظام (kernel) قيد التشغيل لديك، وثبّت التحديثات الأمنية الخاصة بتوزيعتك، وأعد تشغيل الخادم للإقلاع بالنواة الجديدة، وقلّص ما يمكن لأي عملية مخترقة الوصول إليه. هذه ثغرات محلية، مما يعني أن المهاجم يحتاج أولاً إلى موطئ قدم، وليست ثغرات قابلة للاستغلال عن بُعد بمفردها.

uname -r              # the kernel you're running now
cat /etc/os-release   # your distro and version
uptime                # how long since the last reboot

ملخص سريع

• أنتج خط معالجة OpenAI ما مجموعه 948 استغلالاً فريداً لتصعيد الصلاحيات محلياً (LPE) على Linux بتكلفة 1,279 دولاراً لكل استغلال من رصيد API.
• تشير OpenAI إلى أن امتلاك حساب محدود الصلاحيات على نظام تشغيل لم يحصل على أحدث الترقيعات الأمنية "يجب اعتباره مكافئاً عملياً لصلاحيات root بالنسبة لجهات التهديد ذات الموارد العالية".
• لا تزال العديد من هذه الثغرات قيد الإبلاغ والإصلاح حالياً. ولم تنشر OpenAI أي قائمة بالإصدارات المتأثرة، لذا لا يمكن اعتبار أي إصدار من النواة آمناً بشكل قاطع.
• لم يشر تقرير OpenAI إلى رصد أي هجمات نشطة تستخدم هذه الثغرات الـ 948.
• مهمتك هذا الأسبوع: تثبيت التحديثات وإعادة التشغيل، وعزل أحمال العمل المعرضة للخطر، وتقليص نطاق وصول حسابات الخدمات لأدنى حد ممكن.

ما وجدته OpenAI: لغة الأرقام

يصف تقرير OpenAI بعنوان "ألف طريق أقل نحو صلاحيات root"، والمنشور في 4 نوفمبر 2026، تجربة تشغيل نُفذت في منتصف أكتوبر ضد أحدث نواة لنظام Linux باستخدام نموذج أمني مستقبلي للذكاء الاصطناعي. جرى اختبار الاستغلالات على نظام تشغيل مكتبي افتراضي من إحدى التوزيعات الشائعة، مع تفعيل آليات الحماية القياسية (SMEP وSMAP وKASLR وHARDENED_USERCOPY)، وذلك داخل أجهزة افتراضية معزولة تماماً.

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

أوضحت OpenAI أنها أرسلت مئات البلاغات والترقيعات البرمجية للثغرات الحرجة، وتعمل على تسليم البقية تدريجياً بالتعاون مع شركاء مبادرة Patch the Planet. وتظل التفاصيل الدقيقة للاستغلالات طي الكتمان، بما في ذلك ما لا يقل عن 10 تقنيات استغلال مبتكرة. وبالتالي، لا توجد قائمة محددة لمقارنة نواتك بها، كما أن دمج الإصلاح في المصدر الرئيسي للنواة (upstream) لا يعني بالضرورة أن توزيعتك قد وفرته بعد للمستخدمين.

ماذا يعني وصف "محلي" بالنسبة لخادم API؟

تسمح ثغرة تصعيد الصلاحيات المحلية (LPE) للمستخدم الذي يستطيع بالفعل تنفيذ أوامر برمجية على الخادم بالترقية إلى صلاحيات root. لا يمكن لأي شخص استغلال هذه الثغرة بمجرد إرسال طلب HTTP إلى واجهة برمجة التطبيقات الخاصة بك فحسب؛ بل يحتاج المهاجم أولاً إلى موطئ قدم، مثل القدرة على تنفيذ تعليمات برمجية داخل خدمتك أو الوصول إلى واجهة سطر الأوامر (shell) عبر بيانات اعتماد مسروقة. وتعد ثغرة النواة هي الخطوة الثانية دائماً.

توفر خوادم الـ API عادة العديد من نقاط الدخول الأولى:

• ثغرة برمجية في حزمتك التقنية. توضح ثغرات مثل PHP2Shell وReact2Shell وثغرة Node.js Brotli RCE كيف يمكن أن يبدأ تنفيذ التعليمات البرمجية عن بُعد من طبقة التطبيق نفسها.
• رمز مميز مسروق. يمكن لمفتاح SSH مسرب أو رمز مصادقة خاص بنظام التكامل المستمر (CI token) أن يمنح المهاجم وصولاً مباشراً إلى الطرفية. كما يوضح تقرير مفاتيح AI المسروقة مدى سرعة استغلال بيانات الاعتماد المسربة فور العثور عليها.
• اختراق حساب خدمة. غالباً ما تمتلك روبوتات النشر التلقائي أو حسابات العمال المشتركة (worker accounts) صلاحيات أوسع بكثير مما يتوقعه فريق العمل.

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

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

تحقق من نواتك وحالة التحديثات خلال دقيقتين

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

في نظام RHEL، يُرجع الأمر needs-restarting -r القيمة 1 عندما تكون إعادة التشغيل مطلوبة و0 عند عدم الحاجة إليها، مما يتيح لك أتمتة الفحص عبر الخوادم ببرمجيات نصية. أما في Debian، فيتحقق أمر needrestart -k مما إذا كانت النواة الحالية قديمة وتتطلب استبدالاً.

تساعدك تقنية الترقيع الحي (Live Patching)، ولكن ضمن قيود معينة:

• لا تغطي كل الثغرات. توفر AWS الترقيع الحي وفق مبدأ بذل أقصى جهد ممكن (best-effort)، وتشير صراحة إلى أن بعض الإصلاحات لا تتوفر إلا ضمن حزمة النواة الكاملة.
• لن يتغير ناتج الأمر uname -r. لا يتغير رقم الإصدار إلا بعد إعادة التشغيل الكاملة، لذا عليك التحقق من حالة الترقيع الحي مباشرة عبر أدواتها المخصصة.
• قد تختفي علامة طلب إعادة التشغيل في Ubuntu. تستطيع خدمة Livepatch إزالة تنبيه إعادة التشغيل إذا قامت بتغطية جميع ثغرات CVE المعالجة بواسطة النواة الجديدة المنتظرة عند الإقلاع القادم. يُظهر الأمر canonical-livepatch status --verbose قائمة الثغرات التي تم تطبيق إصلاحاتها فعلياً.

تعامل مع الترقيع الحي كإجراء مؤقت ريثما يحين موعد إعادة التشغيل التالي، واعمل على تقصير الفترات الزمنية بين دورات إعادة التشغيل.

الحاويات تتشارك نواة النظام مع الخادم المضيف

لا تمتلك الحاوية (Container) نواة منفصلة خاصة بها؛ فإذا نفذت uname -r داخل حاوية الـ API، فستحصل على رقم إصدار نواة الخادم المضيف نفسه. وبالتالي فإن تحديث الصورة الأساسية (base image) للحاوية لا يمس النواة بأي تغيير، وأي ثغرة في النواة يمكن الوصول إليها من داخل الحاوية تفتح مساراً مباشراً للسيطرة على الخادم المضيف.

في بيئات Kubernetes، يعرض لك أمر واحد إصدار النواة لكل عقدة ضمن العمود KERNEL-VERSION:

kubectl get nodes -o wide

وقد سلك المهاجمون هذا المسار عملياً من قبل؛ ففي حادثة منفصلة، ذكر موقع SecurityWeek أن وكلاء الذكاء الاصطناعي لدى OpenAI استغلوا ثغرة معروفة في النواة (CVE-2026-53362) ووصلوا إلى صلاحيات root على عقدة العمل الأساسية (worker node) من داخل حاوية ضمن البيئة الداخلية لشركة OpenAI نفسها. وتجدر الإشارة إلى أن هذه الثغرة ليست واحدة من الـ 948 المذكورة حديثاً.

تحدد OpenAI خيارين لعزل البيئات والحد من نطاق الأضرار التدميرية (blast radius):

في Kubernetes، يمكنك تحديد بيئة تشغيل معزولة (sandboxed runtime) لكل Pod باستخدام ميزة RuntimeClass. ابدأ بتعيين runtimeClassName لأكثر أحمال العمل لديك خطورة أولاً، مثل أي خدمة تقوم بتشغيل كود خاص بالعملاء.

احرص على تحديث هذه الطبقات الأمنية أيضاً؛ فقد ذكرت OpenAI أن اختباراتها للبنية التحتية قادتها إلى اكتشاف ثغرات أمنية وتصحيحها في مشاريع مثل Kata وMoby/Docker وgVisor وغيرها. توفر بيئات العزل حاجزاً يقلص الضرر، لكنها تظل برمجيات قد تحتوي على أخطاء.

تقليص نطاق ما يمكن لموطئ القدم الوصول إليه

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

1. فصل حسابات الخدمات المشتركة. امنح كل خدمة هوية مستقلة ومخصصة، بحيث لا يؤدي تسريب بيانات اعتماد واحدة إلى كشف بقية الأنظمة. وتنطبق إرشاداتنا حول الحد الأدنى من الصلاحيات لمفاتيح API الخاصة بالوكلاء على الخدمات أيضاً.
2. إزالة الرموز المميزة التي لا يحتاجها حمل العمل. في بيئة Kubernetes، قم بتعطيل التضمين التلقائي عبر automountServiceAccountToken: false على الـ Pods التي لا تحتاج للاتصال بواجهة برمجة تطبيقات Kubernetes.
3. إبعاد الأسرار طويلة الأمد عن العقد والخوادم. يستطيع صاحب صلاحية root قراءة متغيرات البيئة والملفات الموصولة (mounted files)، لذا يُفضل الاعتماد دوماً على بيانات اعتماد قصيرة العمر وصالحة لفترات محدودة.
4. تدوير بيانات الاعتماد فور الاشتباه في أي اختراق. إذا اكتشفت تنفيذ تعليمات برمجية مجهولة على أحد الخوادم، فتعامل مع كل سر أو رمز مخزن على ذلك الخادم باعتباره مكشوفاً. إن ظهور الحساب بمظهر نظيف لا يثبت أبداً عدم السيطرة على الخادم بصلاحيات root.

بعد ذلك، قم بتدقيق باقي الجوانب باستخدام قائمة التحقق لاختبار أمان واجهات برمجة التطبيقات؛ فكل ثغرة تسدها هناك تعني حرمان المهاجمين من موطئ قدم محتمل.

دع وكيل البرمجة يتحقق من الـ API بعد الترقيع

العائق الحقيقي أمام التحديث الدوري لنواة النظام هو الخوف من إعادة التشغيل وما قد ينجم عنها من أعطال. وإجراء اختبارات انحدار (regression testing) قبل التحديث وبعده يبدد هذه المخاوف تماماً. وجّه وكيل البرمجة لديك لتشغيل نفس حزمة اختبارات Apidog CLI قبل التحديث وبعده، ثم مقارنة النتائج بدقة.

أعد التهيئة مرة واحدة فقط:

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

ثم وجّه أمراً واحداً لوكيلك:

Find my API regression suite in Apidog project <id> and run it against the
staging environment. Save the reports to reports/before. Stop and wait while
I update the kernel and reboot. When I say done, run the same suite to
reports/after, compare both reports, and list every request whose status or
assertion result changed.

سينفذ الوكيل الأوامر التالية:

apidog test-suite list --project <id>
apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/before
# you update the kernel and reboot
apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/after

ابدأ ببيئة الاختبار والتجهيز (staging)، ثم كرر العملية على عقدة إنتاجية واحدة قبل تعميم التحديث على كامل البنية التحتية. إن أي تغير في استجابة أحد الطلبات سيرشدك إلى موضع الخلل بدقة قبل تعطل بقية العقد.

يتطلب تقرير الوكيل نفس درجة التدقيق التي اتبعتها OpenAI في خط معالجتها؛ ففي اختبار أولي، تمكن 20 استغلالاً من أصل 200 من الحصول على صلاحيات root عبر ثغرة يوم صفري (0-day) مختلفة عن الثغرة المستهدفة، مما دفع OpenAI إلى إضافة مرحلة تحقق مستقلة. تحقق دائماً من المسار المؤدي إلى النتيجة وليس فقط من النتيجة المجردة: تأكد عبر uname -r أو أداة الترقيع الحي لديك من نجاح تطبيق التحديث الفعلي قبل الوثوق بتقرير ما بعد التحديث.

يمكن دمج نفس فحص -r junit ضمن مسار CI/CD بسلاسة. راجع دليل Apidog CLI لخطوط أنابيب CI/CD، ومرجع الأمر apidog run، ومقدمتنا حول اختبار انحدار واجهات برمجة التطبيقات. علماً بأن الخطة المجانية من Apidog تغطي حتى 4 مستخدمين.

ما يجب متابعته لاحقاً

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

الأسئلة الشائعة

هل ثغرات Linux الـ 948 قابلة للاستغلال عن بُعد؟ لا، إنها ثغرات تصعيد صلاحيات محلية (LPE)، مما يتطلب من المهاجم تشغيل كود بالفعل على النظام كمستخدم محدود الصلاحيات. ولكن يمكن لأي ثغرة عن بُعد في تطبيقك أن تمنحه موطئ القدم هذا، ولهذا السبب تحديداً يجب على فرق الـ API الاهتمام بها.

هل إصدار النواة لدي متأثر؟ لم تنشر OpenAI قائمة بالإصدارات المتأثرة، لذا لا يمكن لأحد أن يحدد لك رقم إصدار آمن بالكامل. قم بتثبيت أحدث التحديثات الأمنية لتوزيعتك فوراً وأعد تشغيل الخادم للإقلاع بالنواة المحدثة.

هل يجري استغلال هذه الثغرات في هجمات فعلية حالياً؟ لم يسجل منشور OpenAI أي هجمات واقعية تستخدم هذه الثغرات الـ 948، فالعديد منها لا يزال يمر بمراحل الإبلاغ والترقيع. بادر بالتحديث الآن على أي حال، لأن الإصلاحات العامة ترشد المهاجمين عادة إلى أماكن الخلل.

هل يغني الترقيع الحي عن إعادة التشغيل؟ لا، يغطي الترقيع الحي إصلاحات محددة فقط، ويؤكد الموردون أن بعض المعالجات لا تصدر إلا ضمن حزمة النواة الكاملة. استخدم الترقيع الحي فقط لكسب الوقت حتى موعد إعادة التشغيل التالي.

هل يؤدي تحديث صورة الحاوية (Container Image) إلى حل ثغرة النواة؟ لا، تعتمد الحاويات على نواة الخادم المضيف، لذا يتعين عليك تحديث الخادم أو العقدة المضيفة وإعادة تشغيلها. واحرص على تحديث صور الحاويات أيضاً، لأنها تضم مكتبات تطبيقك وتبعياته التي قد تحوي ثغراتها الخاصة.