لكل سحابة جدار تقسم بأنه الحامل الأساسي. وعلى أي مضيف افتراضي، ذلك الجدار هو الهايبرفايزر: طبقة الكود الرقيقة التي تُقنع كل عميل بأن حصته من الجهاز ملكه وحده. في الثالث من نوفمبر، أعلن مشروع Xen للعالم أن جدارًا يصونه منذ 2016 فيه باب، وأن الباب اكتشفه ذكاء اصطناعي.
التحذير اسمه XSA-523، والثغرتان هما CVE-2026-102703 وCVE-2026-102704. الأثر بصياغة المشروع الحذرة: «يمكن لضيف خبيث أن يقرأ ويكتب ذاكرة عشوائية تعود لنطاقات أخرى، بما فيها Dom0».
اقرأ ذلك مرتين. ليس «ضيف يستطيع إسقاط جاره»، وليس «ضيف يسرب بضعة بايتات». الضيف يستطيع الوصول إلى ذاكرة عميل آخر وإلى ذاكرة Dom0، نطاق التحكم الذي يدير المضيف. وقد صاغتها منصة XCP-ng المفتوحة المبنية على Xen بشكل أوضح: «ضيف واحد مخترق يستطيع الخروج من العزل والسيطرة على المضيف بالكامل».
ولا يوجد تخفيف. فقط ترقيع، وإعادة تشغيل.
ما الذي انكسر بالضبط
جدول المنح في Xen هو الآلية التي تسمح للآلات الافتراضية بمشاركة الذاكرة دون أن تثق إحداها بالأخرى. يقول الضيف «هذه الصفحات من عندي يمكن لذلك الجهاز قراءتها»، فينفّذ Xen الوعد. وتقوم تعليمة GNTTABOP_copy بهذه النسخ على شكل دفعات، ولأن العناصر المتجاورة في الدفعة تلمس عادة ذاكرة متجاورة في الصفحة نفسها، يخزّن Xen وصف العنصر السابق بعد التحقق منه ويعيد استخدامه عندما يبدو العنصر التالي مكافئًا.
في هذا المخزن المؤقت شُقّ الجدار.
الخلل الأول، CVE-2026-102703، هو فحص صلاحية يخلط بين نوعين من المعرّفات. عندما ينسخ العنصر الجديد برقم إطار الذاكرة، يقارن Xen رقم الإطار مع المدخل المخزّن دون أن يتأكد أولًا أن المدخل المخزّن كان أيضًا إطارًا. لذلك يمكن اعتبار مرجع منح من عنصر سابق رقم إطار فعلي، ويُعاد استخدام المخزن لذاكرة لا يحق للضيف لمسها.
الخلل الثاني، CVE-2026-102704، هو فحص صلاحيات في المكان الخطأ. النسخ برقم الإطار بدل مرجع المنح مسموح فقط عندما يعمل الضيف على ذاكرته الخاصة، ويطبّق Xen ذلك داخل دالة يستدعيها عند إعادة قفل النطاقات المعنية. وإذا ذكر العنصر التالي النطاقات نفسها التي ذكرها السابق، تُتجاوز هذه الدالة بالكامل، فلا يُطبّق شرط «ذاكرتك وحدها» أبدًا.
لا يحتاج أي من المسارين إعدادًا خاصًا، ولا صلاحيات root داخل الضيف، ولا سلسلة استغلال منشورة. يحتاج شيئًا واحدًا: جدول منح يعمل. وكل إصدارات Xen من 4.6 وما بعدها مصابة. هذا عقد كامل من الهايبرفايزر، ولهذا يتجاوز الأمر قائمة بريد Xen بكثير.
الجزء الذي يجب أن يغيّر طريقة بناء فريق الأمن
ينسب مشروع Xen الاكتشاف إلى Anthropic باستخدام Claude، وتحقّق منه Stephan Lipp من Ada Logics، وأبلغ فريق أبحاث CodeAnt عن المشكلة ذاتها بشكل مستقل.
تأمل هذا التسلسل. نموذج وجد خطأ منطقيًا في إدارة الذاكرة داخل جدول المنح في هايبرفايزر قرأه خبراء بشريون عشر سنوات. جهة تحقق بشرية أكدت أن الاكتشاف حقيقي. ثم وصل فريق أبحاث ذكاء اصطناعي ثانٍ، مستقل تمامًا، إلى الخلل نفسه بمفرده.
وهذا هو الأسبوع نفسه الذي وصف فيه فريق استخبارات التهديدات في Google عمليات LLMjacking تسحب أكثر من مليون دولار من استخدام الذكاء الاصطناعي السحابي المسروق، وأحصت Wiz أكثر من تسع منصات تطوير ذكاء اصطناعي مخترقة في أكتوبر. منحنيان يتقاطعان: المهاجمون يؤتمتون الاكتشاف وتحويله إلى مال بالذكاء الاصطناعي، والمدافعون أصبح لديهم ذكاء اصطناعي يجد ثغرات حقيقية في أعمق طبقة من البنية.
الخلاصة العملية لمدير تقني غير مريحة: وتيرة الترقيع عندك لم تعد معايرة على باحثين بشريين. صارت معايرة على آلات تقرأ كود النواة طوال الليل.
من المعرّض ومن ليس كذلك
إذا كنت تستأجر جهازًا افتراضيًا من مزوّد سحابي كبير، فالترقيع مسؤوليته، وتعرضك يعتمد على نافذة الصيانة عنده. اسألهم. وفي السحابة المُدارة قد تتأخر رؤية الضيف عن حالة المضيف الحقيقية، لذا لا قيمة إلا لجواب مكتوب من المزوّد.
وإذا كنت تدير بنية Xen أو XCP-ng خاصة بك، وهو أمر شائع لدى مزوّدي الاستضافة والوكالات التي تدير بنية عملائها وكل من يستخدم الافتراضية داخل مقره، فالساعة ساعتك.
- Xen unstable حتى 4.19.x: طبّق xsa523-1.patch وxsa523-2.patch.
- Xen من 4.18.x إلى 4.17.x: طبّق xsa523-4.18-1.patch وxsa523-4.18-2.patch.
- Xen من 4.6.x إلى 4.16.x: لا ترقيع من المشروع. هذه الفروع انتهى عمرها. من كان هنا فليعتبر الأمر لحظة ترحيل لا لحظة ترقيع.
- XCP-ng 8.3 LTS: ثبّت xen-4.17.7-4.2.xcpng8.3 وأعد تشغيل المضيف. وتصنّف Vates الأثر بأنه حرج.
- Qubes OS 4.3: حزم Xen 4.19.6-3 في dom0، مع إعادة تشغيل dom0. وإن كنت تستخدم Anti Evil Maid فأعد ختم عبارة المرور، لأن ملفات Xen الجديدة تغيّر PCR18 وPCR19.
وثمّة حقيقتان تشغيليتان من موجات الذعر السابقة في الهايبرفايزر تنطبقان هنا أيضًا. الأولى: الترقيعات مُعدّة مقابل الفروع المستقرة، فحدّث إلى رأس الفرع قبل التطبيق وإلا سيقاومك أرشيف الإصدار. والثانية: الترقيع يوقف الهجمات المستقبلية، لكنه لا يخبرك إن كان قد وقع هجوم سابقًا. الضيف الذي يقرأ ذاكرة جاره لا يترك أثرًا في سجلات الجار. وإن كنت تستضيف مستأجرين غير موثوقين، فالترقيع بداية مراجعة الحادث لا نهايتها.
ما نفعله نحن، وما سنفعله من أجلك
في aratech نتعامل مع ترقيع الهايبرفايزر كتغيير من الدرجة الأولى: نافذة إعادة تشغيل مجدولة، إشعار المستأجرين، نسخة احتياطية قبل إعادة التشغيل، ثم مراجعة سجل تغييرات الحزمة لنُثبت أن الفرع يحمل رقم XSA بدلًا من افتراض ذلك. والعملاء على بنية افتراضية مشتركة يحصلون على جواب مكتوب: أي هايبرفايزر، وأي إصدار، وأي حالة ترقيع.
النسخة القصيرة لما يجب فعله هذا الأسبوع:
- اجرد الهايبرفايزر، لا الجهاز الافتراضي فقط. على مضيفات Xen استخدم
xl info | grep '^xen_version'، وداخل الضيف تحقق عبرcat /sys/hypervisor/type. معظم الفرق تعرف إصدارات أنظمتها ولا تعرف ما تحتها. - اطلب من كل مزوّد حالة XSA-523 كتابيًا، مع الفرع وتاريخ إعادة التشغيل. عبارة «نحن مرقّعون» بلا رقم إصدار هي تخمين.
- رقّع، ثم أعد التشغيل، ثم تحقق. ترقيع هايبرفايزر لا يُعيد التشغيل هو ملاحظة في تذكرة، لا إصلاح.
- إن كنت تشغّل فروعًا منتهية العمر، فاعتبر XSA-523 محفّزًا لخطة ترحيل. لا ترقيع قادمًا لـ 4.6 حتى 4.16.
- افترض أن الاكتشاف صار بسرعة الآلة. قلّص الفاصل بين «نشر التحذير» و«إعادة تشغيل المضيف» إلى ساعات، واكتب دليل التنفيذ قبل أن تحتاجه.
الجدار يصمد إن أعدت بناءه
جدار الهايبرفايزر يبقى أفضل ما لدينا. صمد عقدًا أمام باحثين بشريين، وصمد لأن الفحوصات كانت شبه صحيحة. و«شبه» أصبحت اليوم كل ما يحتاجه مدقّق ذكاء اصطناعي ليجدك.
الباب في Xen مُرقّع. أما إن كان باب بنيتك مغلقًا، فيتوقف على سؤال ممل: هل تعرف اليوم أي إصدار هايبرفايزر يحمل أحمال الإنتاج عندك؟
وإن كانت الإجابة الصادقة «سأضطر للسؤال»، فهذا هو الاكتشاف الذي يستحق التحرك قبل التحذير القادم.