ثغرتان ومسؤولان
تحمل PwnEscape المعرّف CVE-2026-99999. يقع الخلل في حزمة الشبكة IPv4 داخل النواة، في الدالة skb_checksum_help، ويُبلَغ إليه عبر الحركة التي ترسلها آلة افتراضية من خلال virtio-net. درجة CVSS 3.1 هي 9.3 بمتجه محلي (AV:L). اكتشفها Paulos Yibelo (Pwn.ai) خلال تحدي Vercel Sandbox وأثبت هروبًا في المختبر على KVM وFirecracker. النواة المكشوفة هي نواة مضيف الافتراضية، لا نواة خادمك.
تحمل Vghost المعرّف CVE-2026-74580. تمسّ النظام الفرعي vhost: ذاكرة تخزين مؤقتة لبيانات طوابير virtio (الـ vrings) لا تُفرَّغ عند تغيّر إعدادها، فيتجاوز ذلك التحقق من النطاقات. المستخدم المحلي القادر على فتح /dev/vhost-net أو /dev/vhost-vsock يستطيع الحصول على صلاحيات root. يوجد إثبات مفهوم علني. وفي الثغرتين معًا لم يُبلَّغ عن استغلال فعلي وقت كتابة هذا الدليل.
من يصلح ماذا
مرّر الجدول أفقيًا
| الحالة | موضع الخلل | من يتحرك |
|---|---|---|
| PwnEscape (CVE-2026-99999) | نواة مضيف الافتراضية، حزمة الشبكة IPv4 | مزوّد الاستضافة على مضيفاته. لا شيء يُصلَح من خادمك |
| Vghost (CVE-2026-74580)، جهة الخادم | نواة خادمك إن كانت عقد `/dev/vhost-*` في المتناول | أنت: نواة مصلَحة ثم إعادة تشغيل |
| Vghost، مسار يُطلَق من آلة ضيفة | نواة المضيف وQEMU بشروط محددة | مزوّد الاستضافة |
| تحديث نواة الضيف أمام PwnEscape | الخلل على المضيف | لا حماية من هذه الجهة؛ ويبقى مفيدًا لـ Vghost ولإصلاحات أخرى |
| خادم مخصص أو VPS تكون فيه أنت المشرف على الآلات (KVM، Proxmox) | أنت المضيف | أنت: الثغرتان تعنيانك |
| حاويات Docker على الخادم | تتشارك نواة الخادم | أصلح نواة الخادم؛ إعادة بناء صورة لا تغيّر شيئًا |
| استضافة cPanel المشتركة | النواة يديرها المزوّد | مزوّد الاستضافة |
PwnEscape: شأن مزوّد الاستضافة
في حالة الهروب، يجب إصلاح النواة التي تستقبل حركة الآلة الافتراضية، أي نواة المضيف. الفروع المستقرة المصلَحة هي 5.10.272 و5.15.223 و6.1.190 و6.6.159 و6.12.113 و6.18.57 و7.2.11؛ وكثيرًا ما تنقل نواة التوزيعات الإصلاح دون تغيير رقم الأساس، فاقرأ نشرة التوزيعة بدل مقارنة الأرقام. كما يعرض سجل CVE حدودًا للإصدارات غير متسقة: اعتمد على متتبعات التوزيعات.
على خادم VPS لا يمكنك تطبيق هذا الإصلاح، وتحديث نواة الضيف لا يحميك منه. اسأل مزوّدك، أيًّا كان، هل مضيفاته مصلَحة، وفي أي تاريخ، وهل تُجدول إعادة تشغيل للمضيف. لا نزعم هنا أن عرضًا بعينه معرَّض أو غير معرَّض: وحدها تأكيدات المشغّل معتبرة. يتوقع الباحث في مقاله ظهور استغلالات علنية للإعدادات الأضعف في غضون أسابيع: هذا توقّعه لا ملاحظة، وتقييم CISA لا يبلغ عن أي استغلال حتى الآن.
Vghost: شأنك أنت
Vghost رفع صلاحيات محلي: على المهاجم أن ينفّذ شيفرة على الجهاز أصلًا، مثلًا عبر موقع عميل مخترَق يعمل بحساب محدود الصلاحيات. إصلاح النواة الرئيسية هو الإيداع de845981da67. أولى الإصدارات المستقرة المصلَحة هي 5.10.265 و5.15.216 و6.1.183 و6.6.152 و6.12.104 و6.18.45 و7.1.9 و7.2. وهنا أيضًا قد تحمل نواة التوزيعة الإصلاح برقم آخر: قارن بنشرة التوزيعة لا بالرقم الأصلي.
كل شيء يتوقف على صلاحيات عقد vhost. بحسب إعلان oss-security، في اختبارات كاتبه، حصرت Ubuntu العقدة /dev/vhost-vsock في المجموعة kvm، بينما فتحتها RHEL وAmazon Linux وAzure Linux وOracle Linux لأي مستخدم. وعلى خادم لا يستضيف أي آلة افتراضية تغيب هذه العقد عادةً؛ تحقق ولا تفترض. ولا يسري الإصلاح إلا بعد إعادة التشغيل على النواة الجديدة.
افحص النواة والتعرّض في عشر دقائق
قراءة النواة العاملة
uname -r
يعرض هذا الأمر النواة المحمَّلة في الذاكرة لا المثبَّتة على القرص. وهذا هو الرقم المهم في Vghost، ولا يتغير إلا بعد إعادة التشغيل.سرد النوى المثبَّتة
dpkg -l 'linux-image*' | grep '^ii'rpm -q kernel
الأمر الأول لـ Debian وUbuntu والثاني لـ AlmaLinux وRocky وRHEL. إن اختلفت أحدث نواة في القائمة عن نواةuname -r، فقد يكون الإصلاح مثبَّتًا دون أن يكون فعّالًا.معرفة ما إذا كانت إعادة تشغيل معلّقة
cat /var/run/reboot-requiredsudo needrestart -ksudo dnf needs-restarting -r
الأولان لـ Debian وUbuntu والثالث لـ AlmaLinux وRocky (الحزمةdnf-utilsإن غاب الأمر). وهي تقارن النواة العاملة بالمثبَّتة.البحث عن عقد vhost وصلاحياتها
ls -l /dev/vhost-net /dev/vhost-vsocklsmod | grep '^vhost'getent group kvm
إن لم توجد عقدة ولا وحدة محمَّلة فالمسار المذكور لـ Vghost غير مفتوح في هذه اللحظة، لكن برنامجًا أو مسؤولًا قد يحمّل الوحدة لاحقًا. وإن وُجدت عقدة فاقرأ وضعها:0666يعني أن أي حساب محلي يستطيع فتحها، و0660يعني وجوب الانتماء إلى المجموعة المالكة. وإن كنت تشغّل آلات افتراضية بنفسك فأضفls -l /dev/kvm.البحث عن المعرّف في سجل تغييرات الحزمة
apt changelog linux-image-$(uname -r) | grep CVE-2026-74580rpm -q --changelog kernel | grep CVE-2026-74580
السطر الأول لـ Debian وUbuntu والثاني لعائلة RHEL. العثور على المعرّف علامة جيدة؛ وعدم العثور عليه لا يثبت شيئًا، فقد يذكر السجل الإصلاح بصيغة أخرى. ويحسم الأمر متتبع التوزيعة.معالجة الحاويات والوصول إلى الأجهزة
docker exec <container> uname -rdocker ps -q | xargs -r docker inspect | grep -E 'Privileged|vhost'
يعرض الأمر الأول نواة الخادم، دليلًا على أن الحاوية لا تملك نواة خاصة. ويرصد الثاني الحاويات المشغَّلة في الوضع المميّز أو التي رُكِّب فيها جهاز vhost: فهي ترى عقد المضيف.
أين وصلت التوزيعات
تتغير حالة الإصلاحات من يوم إلى آخر وتختلف بين إصدارات التوزيعة الواحدة، إذ يُصلَح بعضها قبل بعض. أعد قراءة متتبع توزيعتك للمعرّفين CVE-2026-74580 وCVE-2026-99999 قبل أن تستنتج: الروابط في آخر المقال. وفي AlmaLinux وRocky تابع النشرات التي ينشرها كل مشروع بعد نشرات RHEL. ما دام إصدارك لا يعرض إصلاحًا منشورًا، طبّق إجراءً مؤقتًا وعاود الفحص.
التحديث بحسب البيئة
Debian وUbuntu
sudo apt updatesudo apt full-upgradeapt list --installed 'linux-image*'
استخدمfull-upgrade: تصل النواة الجديدة باسم حزمة جديد، وكثيرًا ما يتركهاapt upgradeجانبًا ("kept back"). وإن بيّن المتتبع أن الإصلاح لم يُنشر بعد لإصدارك فلا يفيد التحديث في هذه النقطة: طبّق إجراءً مؤقتًا وعاود الفحص بانتظام.AlmaLinux وRocky وRHEL
sudo dnf upgrade --refresh kernelsudo grubby --default-kernelsudo dnf needs-restarting -r
يؤكد الأمر الثاني أن النواة المثبَّتة هي التي ستقلع افتراضيًا. ويبيّن الثالث هل ينتظر النظام إعادة تشغيل.Docker والحاويات
لا شيء يُعاد بناؤه: الحاويات تستخدم نواة الخادم. حدّث نواة الجهاز كما سبق ثم أعد تشغيله. وبعد إعادة التشغيل تحقق من عودة كل حاوية:
docker psوdocker ps -a --filter status=exited. وسياسةrestart: unless-stoppedفي ملفات Compose توفّر عليك التشغيل اليدوي.مشرف افتراضية خاص بك (KVM، Proxmox)
أنت المضيف، فالثغرتان تعنيانك. طبّق التحديثات نفسها على المضيف ثم أعد تشغيله بعد نقل الآلات الافتراضية أو إيقافها بسلاسة. حدّث المضيف قبل الضيوف لا بعدهم.
النواة المثبَّتة ليست النواة العاملة
نجاح apt full-upgrade لا يصلح شيئًا ما دام الجهاز لم يُعَد تشغيله: تبقى النواة الهشة محمَّلة في الذاكرة. الفحص الصالح الوحيد هو uname -r بعد إعادة التشغيل، مقارنةً بالرقم المنتظر في نشرة توزيعتك. دوّنه في سجلك مع التاريخ لكل خادم.
إعادة التشغيل دون قطع مواقع العملاء
خطّط بدل أن تتحمّل. اختر نافذة هادئة، وأبلغ العملاء، وتأكد من حداثة نسخك الاحتياطية، ثم جدول إعادة التشغيل: sudo shutdown -r 03:30 "Kernel reboot". قبلها دوّن حالة الخدمات بـ systemctl --failed وقائمة الحاويات بـ docker ps؛ وبعدها أعد الأوامر نفسها وقارن. عالج المجموعة على دفعات من بضعة أجهزة.
قد يغني livepatch عن إعادة التشغيل، لكن توفره يتوقف على التوزيعة والاشتراك: Canonical Livepatch على Ubuntu مع Ubuntu Pro، وkpatch على عائلة RHEL، وKernelCare لدى ناشر خارجي. لا تفترض وجود إصلاح مباشر لهاتين الثغرتين: اقرأ نشرة المزوّد، وعلى Ubuntu نفّذ canonical-livepatch status --verbose. وتطلب نشرة Vghost إعادة التشغيل على النواة المصلَحة؛ وبلا livepatch مؤكَّد فهذا هو السبيل الوحيد.
إجراءات مؤقتة وحدودها
إن لم يُنشر إصلاح توزيعتك بعد، فهناك إجراءان يقلّصان سطح Vghost دون إغلاقه. الأول سحب الوصول العام إلى العقد، مثل sudo chmod 0660 /dev/vhost-net /dev/vhost-vsock، مع إبعاد الحاويات غير الموثوقة عن هذه الأجهزة. وهو لا يلغي الواصفات المفتوحة أصلًا. والثاني، الذي تقترحه صفحة Red Hat لـ Vghost كإجراء مؤقت، يمنع تحميل الوحدات: printf 'install vhost_net /bin/false\ninstall vhost_vsock /bin/false\n' | sudo tee /etc/modprobe.d/vhost-off.conf ثم sudo modprobe -r vhost_net vhost_vsock. وتحذّر Red Hat من أن تعطيل vhost قد يُضعف أداء الإدخال والإخراج للآلات الافتراضية، وأن إلغاء التحميل يفشل إن كان المشغّل قيد الاستخدام.
لا تنفع هذه الإجراءات ضد PwnEscape لأن خللها على المضيف، ولا يحل أيٌّ منها محل النواة المصلَحة. أعد الإعداد الأصلي متى طُبّق الإصلاح.
فحص الآثار بعد ذلك
على حد علمنا لم يُنشر مؤشر اختراق خاص بهاتين الثغرتين، ما يجعل الفحص ناقصًا. ومع ذلك راجع ما قد يفضح رفع صلاحيات حديثًا: sudo journalctl -k --since "30 days ago" | grep -i -E 'vhost|oops|general protection' لشذوذات النواة، وlast -x | head -30 لتسجيلات الدخول وإعادات التشغيل، وsudo awk -F: '$3==0' /etc/passwd للحسابات بمستوى root، ثم مفاتيح /root/.ssh/authorized_keys ومهام crontab -l لـ root. وابحث كذلك عن الملفات التنفيذية setuid الحديثة بالأمر sudo find / -xdev -perm -4000 -mtime -30.
قد يمحو المهاجم الذي صار root آثاره: فحص نظيف ليس دليل سلامة. وعند الشك في خادم شغّل شيفرة غير موثوقة، أعد بناءه من صورة سليمة واستعد البيانات بدل تنظيفه.
للوكالات: نافذة مشتركة لا خادمًا بعد خادم
مع عشرات خوادم VPS عند عملاء مختلفين يستغرق أمر التحديث دقيقة؛ ويضيع الوقت في معرفة أي خادم يعمل بأي نواة، ومن يوافق على إعادة التشغيل ومتى. احتفظ بسجل حي تغذّيه uname -r ووجود /var/run/reboot-required، ثم حدّد نافذة مشتركة معلنة مسبقًا بدل اكتشاف الثغرة خادمًا بعد خادم. رتّب أولًا الأجهزة التي تعمل عليها شيفرة عملاء غير موثوقة، ثم تلك التي توجد فيها /dev/vhost-*.
تجمع مساحة الوكالات في ServOrbit الخدمات ومواعيد الاستحقاق في مكان واحد، فلا تتابعها حسابًا بعد حساب. ولمن لا يريد إدارة النواة بنفسه تقدّم ServOrbit خيار إدارة VPS؛ أما هذا الدليل فمقدَّم دون دعم.
الوثائق الرسمية
الإفصاح عن Vghost في oss-security: https://openwall.com/lists/oss-security/2026/10/14/2
التحليل التقني لـ Vghost: https://matrix.tencent.com/en/2026/10/12/vghost-cve-2026-74580
سجل CVE لـ PwnEscape: https://cveawg.mitre.org/api/cve/CVE-2026-99999
مقال مكتشف PwnEscape: https://pwn.ai/blog/pwnescape
متتبع Debian لـ Vghost: https://security-tracker.debian.org/tracker/CVE-2026-74580
متتبع Debian لـ PwnEscape: https://security-tracker.debian.org/tracker/CVE-2026-99999
متتبع Ubuntu لـ Vghost: https://ubuntu.com/security/CVE-2026-74580
متتبع Ubuntu لـ PwnEscape: https://ubuntu.com/security/CVE-2026-99999
صفحة Red Hat لـ Vghost: https://access.redhat.com/security/cve/CVE-2026-74580
نشرات AlmaLinux: https://errata.almalinux.org/
Canonical Livepatch: https://ubuntu.com/security/livepatch
أداة needrestart: https://github.com/liske/needrestart
