ثغرة عمرها 16 عامًا في مشرف الأجهزة الافتراضية KVM داخل نواة Linux، أُطلق عليها اسم Januscape وتُتتبَّع تحت المُعرّف CVE-2026-53359، تتيح لجهاز افتراضي خبيث الإفلات من بيئته كضيف والعبث بذاكرة المضيف الذي يعمل عليه. إنها ثغرة use-after-free في شيفرة إدارة الذاكرة الظلّية (shadow) في KVM، وتؤثر على أنظمة x86 من Intel وAMD على حدٍّ سواء، ولم يصل إصلاحها إلى النُّوى المستقرة إلا في 4 يوليو 2026. إذا كنت تُشغّل ضيوفًا غير موثوقين — منصة استضافة، أو مشغّل CI، أو سحابة متعددة المستأجرين — فهذا هو نوع الثغرات الذي يُقلق مضاجع مشغّلي الأنظمة: هروب كامل من الضيف إلى المضيف انطلاقًا من شيفرة غير مُمتازة الصلاحيات داخل الجهاز الافتراضي. إليك ما هي الثغرة، ولماذا ظلّت مخفيّة كل هذه المدة، ومن هم المعرّضون لها فعليًا، وكيف تسدّها بالضبط.
ما هي Januscape (CVE-2026-53359)؟
Januscape هي ثغرة use-after-free في الـ shadow MMU (وحدة إدارة الذاكرة الظلّية) الخاصة بـ Linux KVM، مشرف الأجهزة الافتراضية المدمج في النواة. اكتشفها الباحث الأمني Hyunwoo Kim (@v4bel) وقدّمها كثغرة يوم-صفر إلى برنامج kvmCTF من Google، وهو برنامج المكافآت المُنضبِط الذي يدفع حتى $250,000 مقابل هروب فعّال من الضيف إلى المضيف. يُسقِط الـ proof-of-concept العلني نواة المضيف بموثوقية من داخل ضيف غير مُمتاز الصلاحيات؛ ويقول الباحث إن هناك استغلالًا منفصلًا غير مُعلَن يحوّل الثغرة نفسها إلى تنفيذ شيفرة كامل على المضيف. وهي — على حدّ العلم العام — أول ثغرة KVM مفردة للهروب من الضيف إلى المضيف يمكن إطلاقها على عتاد Intel وAMD معًا، لأن الشيفرة المُعطوبة مشتركة بينهما. نشرت قاعدة بيانات الثغرات الوطنية National Vulnerability Database المُعرّف CVE في 4 يوليو 2026؛ ولم تُصنّفه NVD بعد، لكن SUSE تُقيّمه بدرجة 8.8 (CVSSv3.1) و9.3 (CVSSv4.0) — درجة عالية تكاد تبلغ الحرج.
كيف تعمل الثغرة
السبب الجذري هو اختصار في إعادة استخدام الصفحات ضمن آلية الترقيم الظلّي (shadow paging) في KVM. فعندما تبني KVM جداول صفحات متداخلة برمجيًا، تُخزّن مؤقتًا "الصفحات الظلّية" (shadow pages) وتعيد استخدامها لتوفير الجهد. وللعثور على صفحة صالحة لإعادة الاستخدام، كانت الدالة kvm_mmu_get_child_sp() تقارن رقم إطار الضيف (gfn) فقط — أي العنوان الذي تمثّله الصفحة — وتتجاهل دور (role) الصفحة، أي نوع بنية التتبّع التي تمثّلها فعليًا. ويمكن لنوعين مختلفين من الصفحات أن يتشاركا عنوانًا واحدًا بينما يؤدّيان مهمّتين مختلفتين تمامًا.
يستغل ضيف خبيث هذه الثغرة. فهو يُجبر KVM على إعادة استخدام صفحة ظلّية مبنية لتخطيط بحجم 2 MB (صفحة "مباشرة" direct) بينما تغيّر التخطيط ليحتاج إلى جدول صفحات بحجم 4 KB (صفحة "غير مباشرة" non-direct). العناوين متطابقة، فتُعيد KVM الصفحة الخاطئة. وأثناء التنظيف، تحسب KVM بعد ذلك رقم الإطار الخاطئ، وتفشل في إزالة مُدخل الخريطة العكسية (reverse-map)، وتحرّر الصفحة الظلّية على أي حال، وتترك خلفها مؤشرًا مُتقادمًا (stale pointer). وتُلغي عملية الخريطة العكسية التالية إسناد تلك الذاكرة المُحرَّرة — وهي use-after-free كلاسيكية يمكن للضيف توجيهها، كما يوثّق تحليل TuxCare. أما الإصلاح في المنبع فيكاد يكون تافهًا: أصبحت kvm_mmu_get_child_sp() الآن تقارن دور الصفحة الكامل (role.word) إلى جانب رقم الإطار، بحيث لا يمكن الخلط بين نوعَي الصفحة مرة أخرى أبدًا.
لماذا تُعدّ الافتراضية المتداخلة هي المُشغّل
تتعامل المعالجات الحديثة مع ذاكرة الضيف عتاديًا — تسمّيه Intel بـ EPT، وتسمّيه AMD بـ NPT — وهذا المسار السريع لا يلمس الشيفرة المُعطوبة على الإطلاق. المشكلة تكمن في الافتراضية المتداخلة (nested virtualization): تشغيل جهاز افتراضي داخل جهاز افتراضي. فعندما يتصرّف الضيف نفسه كمشرف أجهزة افتراضية، تلجأ KVM إلى الـ shadow MMU البرمجي القديم لإدارة ذاكرة الضيف الداخلي، وهذا المسار القديم هو بالضبط حيث تعيش Januscape. لذا حتى المضيف الذي يستخدم الترقيم العتادي افتراضيًا يصبح قابلًا للاختراق لحظة أن يسمح للضيوف بتفعيل التداخل. وإذا كان ضيوفك لا يُشغّلون مشرفات أجهزة افتراضية خاصة بهم، وكانت الافتراضية المتداخلة مُعطَّلة، فإن مسار الهجوم مُغلَق. وتفصيل الإعداد الوحيد هذا هو الفارق بين المُعرَّض والآمن بالنسبة لمعظم الأساطيل.
من هم المعرّضون للخطر فعليًا
القلق العملي ينصبّ على أي مضيف x86 يُشغّل ضيوفًا غير موثوقين مع توفّر الافتراضية المتداخلة. وحسب ترتيب الأولوية:
- مزوّدو السحابة والاستضافة متعددو المستأجرين الذين يُشغّلون أجهزة افتراضية يتحكّم بها العملاء على مضيفات KVM مشتركة. فمستأجر واحد عدائي مُفعِّل للتداخل يمكنه، من حيث المبدأ، الوصول إلى المضيف وكل جار عليه.
- البنية التحتية للتكامل والتسليم المستمر CI/CD والبناء التي تُنشئ أجهزة افتراضية مؤقتة انطلاقًا من طلبات دمج (pull requests) غير موثوقة — وهو تعرّض شائع ويُنسى بسهولة.
- أي جهاز يحصل فيه كود غير موثوق على صلاحيات guest-root ويستطيع تحميل وحدات نواة خاصة به أو بدء تشغيل مشرف أجهزة افتراضية متداخل.
أما الإعدادات الأقل خطورة فهي: المضيفات التي تُشغّل ضيوفًا موثوقين من الطرف الأول فقط؛ والأنظمة التي عُطِّلت فيها الافتراضية المتداخلة مسبقًا؛ والبيئات المُعتمِدة على الحاويات فقط دون وصول إلى /dev/kvm. نحن نبني ونُشغّل TechRiseUps على بنيتنا التحتية الخاصة عبر WaseerHost، وموقفنا من ثغرة كهذه بسيط ومملّ عن قصد: صلِّح نواة المضيف، واترك الافتراضية المتداخلة مُعطَّلة في أي مكان لا تكون فيه متطلّبًا للمنتج. إنه المنطق نفسه للدفاع المتعمّق الكامن خلف تغطيتنا لـ ثغرة الجذر Bad Epoll في نواة Linux — فنواة المضيف هي الجدار الأخير بين المستأجرين، ولهذا تُصلَّح أولًا.
كيف تُصلِح Januscape
صلِّح نواة المضيف. دُمِج الإصلاح في المسار الرئيسي (mainline) في 19 يونيو 2026 (الالتزام 81ccda30b4e8)، ووصل إلى الأشجار المستقرة في 4 يوليو 2026. حدِّث المضيف — لا الضيوف — إلى الإصدار الخاص بسلسلتك على الأقل:
| سلسلة النواة | الإصدار المُصلَّح | تاريخ الإصدار |
|---|---|---|
| 7.1.x | 7.1.3 | Jul 4, 2026 |
| 6.18.x | 6.18.38 | Jul 4, 2026 |
| 6.12.x | 6.12.95 | Jul 4, 2026 |
| 6.6.x | 6.6.144 | Jul 4, 2026 |
| 6.1.x | 6.1.177 | Jul 4, 2026 |
| 5.15.x | 5.15.211 | Jul 4, 2026 |
| 5.10.x | 5.10.260 | Jul 4, 2026 |
إذا لم تستطع إعادة التشغيل فورًا، فإن التخفيف الموثَّق هو إزالة مسار الهجوم عبر تعطيل الافتراضية المتداخلة للضيوف غير الموثوقين: اضبط kvm_intel.nested=0 على Intel أو kvm_amd.nested=0 على AMD (عبر ملف إضافي في modprobe.d)، وأزِل تحميل KVM كليًا على المضيفات التي لا تُشغّل أي أجهزة افتراضية، وقيِّد الوصول إلى /dev/kvm. وبدأ مزوّدو الترقيع الحيّ (live-patching) بشحن إصلاحات لا تتطلّب إعادة تشغيل، تغطّي كلًّا من Januscape وثغرتها الشقيقة، اعتبارًا من 7 يوليو 2026، وهو المسار العملي للأساطيل التي لا تستطيع أخذ نافذة صيانة. لاحظ أن المضيفات التي تُوزّع نُوى مخصّصة للعملاء — كما يفعل كثير من المزوّدين — قد تتأخّر عن تواريخ المنبع، لذا راجِع نشرة مزوّدك المحدَّدة بدلًا من افتراض التغطية.
لماذا تهمّ ثغرة عمرها 16 عامًا
أُدخِلت Januscape في أغسطس 2010 (الالتزام 2032a93d66fa، النواة 2.6.36) وبقيت دون أن يُلاحَظها أحد على مدى ستة عشر عامًا ومراجعات لا تُحصى. وهي ليست الوحيدة أيضًا: فثغرة use-after-free وثيقة الصلة في الـ shadow MMU، CVE-2026-46113، صُلِّحت في مايو 2026، وذلك الإصلاح الأسبق لا يمنع Januscape لأن الاثنتين تستغلّان عدم تطابق مختلفًا (رقم الإطار مقابل دور الصفحة). إن حدوث هروبين من الضيف إلى المضيف في مسار الشيفرة القديم نفسه خلال شهرين هو القصة الحقيقية. فالـ shadow MMU قديم ومعقّد وبات على نحو متزايد البطن الرخوة لأمن الافتراضية مع تحصين المسارات العتادية. وتؤكّد إفصاحات Kim الأخرى في 2026 هذا الاتجاه — بما في ذلك ITScape (CVE-2026-46316)، أول هروب مُبلَّغ عنه من الضيف إلى المضيف في KVM/arm64. الدرس للمشغّلين ليس الذعر بل الاستعداد: افترض أن حدّ مشرف الأجهزة الافتراضية قابل للانكسار، وقلّل ما يمكن للضيوف غير الموثوقين الوصول إليه (الافتراضية المتداخلة، النُّوى المخصّصة، /dev/kvm)، وعامِل ترقيع نواة المضيف بوصفه أعلى صيانة تُجريها أولويةً. وإذا كنت تُهيّئ أجهزتك الخاصة، فإن دليلنا خطوة بخطوة للاستضافة الذاتية للتطبيقات على VPS يغطّي حُسن الإدارة في تحديث النواة الذي يسدّ ثغرات كهذه قبل أن تُسلَّح.
الأسئلة الشائعة
ما هي Januscape (CVE-2026-53359)؟
هي ثغرة use-after-free في الـ shadow MMU الخاص بـ Linux KVM، تتيح لجهاز افتراضي ضيف خبيث الهروب إلى المضيف على أنظمة x86 من Intel وAMD. يُعطِّل الاستغلال العلني المضيف؛ ويدّعي الباحث أن نسخة خاصة تُحقّق تنفيذ شيفرة كاملًا على المضيف.
هل أنا متأثّر إذا كنت أُشغّل أجهزة افتراضية؟
فقط إذا كان مضيفك يُتيح الافتراضية المتداخلة لضيوف غير موثوقين. أما المضيفات التي تُشغّل ضيوفًا موثوقين من الطرف الأول، أو التي عُطِّلت فيها الافتراضية المتداخلة، فليست على المسار المُعرَّض للاختراق — إذ لا تعمل شيفرة الـ shadow MMU المُعطوبة إلا عندما يُشغّل ضيفٌ مشرف أجهزة افتراضية آخر متداخلًا.
كيف أُصلِحها؟
حدِّث نواة المضيف إلى إصدار مستقر مُصلَّح (7.1.3، أو 6.18.38، أو 6.12.95، أو 6.6.144، أو 6.1.177، أو 5.15.211، أو 5.10.260، من 4 يوليو 2026). وإذا لم تستطع إعادة التشغيل بعد، فعطِّل الافتراضية المتداخلة (kvm_intel.nested=0 / kvm_amd.nested=0) أو استخدم خدمة ترقيع حيّ.
هل يجري استغلال Januscape في البرّية؟
لا يوجد استغلال مؤكَّد في البرّية حتى وقت النشر. فقد ظهرت عبر برنامج البحث kvmCTF من Google، لكن هناك proof-of-concept علنيًا فعّالًا لإسقاط المضيف، ما يعني أن نافذة الهجمات الانتهازية مفتوحة. صلِّح على افتراض أنها ستُسلَّح.
المصادر
- The Hacker News — 16-Year-Old Linux KVM Flaw Lets Guest VMs Escape to Host: الاكتشاف، kvmCTF، تصنيف CVSS، إصدارات النواة المُصلَّحة، نطاق Intel/AMD، ITScape.
- TuxCare — Januscape exposes the KVM shadow-paging bug that kept coming back: شرح السبب الجذري، علاقة CVE-2026-46113، التخفيفات، الجدول الزمني للترقيع الحيّ.
- SecurityWeek — Linux Kernel Vulnerability Allows VM Escape on Intel and AMD Systems: تأكيد مستقل للهروب من الضيف إلى المضيف والمنصّات المتأثّرة.
وقاص احمد وسیر
وقاص احمد وسیر مطوّر ومهندس أتمتة بخبرة تزيد على 8 سنوات في بناء أنظمة إنتاجية يستخدمها أكثر من 100 ألف شخص. يبني تطبيقات SaaS متعددة المستأجرين، وأتمتة بالذكاء الاصطناعي (n8n، تدفقات LLM، بوتات واتساب)، وبنية استضافة (WHM/cPanel، CloudLinux) — وهو صانع WaSphere وFlowMaticX وعلامة الاستضافة WaseerHost. أنجز أكثر من 100 مشروع لشركات صغيرة ومتوسطة ووكالات وشركات ناشئة ممولة.
