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

لكن ماذا يحدث عندما تنهار هذه الحدود نفسها؟

في أكتوبر 2026، كُشف عن ثغرة حرجة من فئة VM Escape بعد أن نجح الباحث الأمني المستقل Paulos Yibelo في الخروج من بيئة microVM ضمن Vercel Sandbox والوصول بصلاحيات root إلى المضيف. ووفق المعلومات المنشورة حتى الآن، فإن الأثر يصل إلى تجاوز العزل بين المستأجرين وإمكانية القراءة والتعديل والتنفيذ عن بُعد عبر حدود يفترض أنها تفصل بين أحمال عمل مستقلة.

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

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

#ما الذي تم اكتشافه فعلياً؟

أعلنت Vercel تأكيدها لثغرة من نوع zero-day اكتُشفت من خلال برنامج مكافآت Vercel Sandbox.

وبحسب المعلومات المنشورة، استطاع الباحث الانتقال من:

text
Guest workload
        ↓
Linux container
        ↓
Firecracker microVM
        ↓
Virtualization boundary
        ↓
EC2 bare-metal host
        ↓
root on host

النتيجة هنا ليست مجرد رفع صلاحيات داخل آلة افتراضية، بل تجاوز لحدود الثقة الأساسية بين الضيف والمضيف.

المعلومات المنشورة حول تقرير المكافأة تشير إلى أثر يتضمن:

text
microVM → EC2 host escape
cross-tenant read
cross-tenant modify
remote code execution

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

إشعار مكافأة الثغرة التي أبلغ عنها Paulos Yibelo

صورة إشعار مكافأة الثغرة المنشورة بواسطة الباحث، كما ظهرت في تغطية Cybernews.

#قبل الحديث عن الثغرة: أين يقع KVM في هذه البنية؟

لفهم خطورة الحدث، يجب فصل المكونات عن بعضها.

KVM أو:

text
Kernel-based Virtual Machine

هو جزء من نواة Linux يحوّل النظام إلى منصة افتراضية قادرة على تشغيل آلات افتراضية معزولة باستخدام دعم العتاد للـ virtualization.

لكن KVM ليس بالضرورة هو كل طبقة الافتراضية التي يراها المستخدم.

في بيئة مثل Vercel Sandbox، توضح Vercel أن كل بيئة تشغيل تحصل على Firecracker microVM خاصة بها، وبداخلها يعمل Linux container. كما تعمل هذه البيئات فوق مضيفات EC2 bare-metal.

يمكن تبسيط البنية كالتالي:

text
Application / Agent Code
          ↓
Linux Container
          ↓
Firecracker microVM
          ↓
KVM / Linux virtualization layer
          ↓
Host Linux Kernel
          ↓
Bare-metal EC2 host

الفكرة الأمنية هنا أن الكود داخل الـ Sandbox قد يكون عدائياً بالكامل، لكن يفترض أن يبقى محصوراً داخل الـ microVM.

إذا استطاع هذا الكود تجاوز تلك الحدود والوصول إلى المضيف، فإن المشكلة لا تعود مشكلة داخل الـ Sandbox؛ بل تصبح انهياراً في أحد أهم حدود الثقة في البنية.

#لماذا لا يمكن الجزم حتى الآن بأن الخلل موجود في KVM نفسه؟

هذه نقطة مهمة جداً.

الوصف المنشور حتى الآن يشير إلى KVM zero-day، لكن التفاصيل الضرورية لإسناد السبب الجذري لم تُنشر بعد.

مسار هروب من آلة افتراضية إلى المضيف قد يوجد نظرياً في أكثر من طبقة، مثل:

text
KVM
Linux kernel
Firecracker
virtio implementation
device emulation
memory handling
host-side integration
hypervisor interfaces

ولذلك فإن وجود VM Escape في بيئة تستخدم KVM لا يكفي وحده لإثبات أن الخلل داخل شيفرة KVM الأساسية.

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

هذه الدقة مهمة خصوصاً لفرق الأمن المؤسسي؛ لأن التعامل مع خبر غير مكتمل وكأنه إنذار شامل لكل خادم يعمل بـ KVM قد يؤدي إلى قرارات تشغيلية غير مبررة.

#لماذا يُعد VM Escape من أخطر أنواع الثغرات؟

في النموذج التقليدي، اختراق تطبيق داخل آلة افتراضية يفترض أن يبقى محدوداً بالآلة نفسها.

أي أن المهاجم قد يحصل على:

text
application access
container access
guest root

لكن تبقى هناك طبقة عزل تمنعه من الوصول إلى:

text
host
other VMs
other tenants
host credentials
host networking
management plane

عند حدوث VM Escape، تنقلب المعادلة.

بدلاً من أن تكون الآلة الافتراضية حاجزاً يوقف الهجوم، تصبح نقطة انطلاق إلى المضيف.

وإذا وصل المهاجم إلى:

text
root

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

#البعد الأخطر: كسر العزل بين المستأجرين

من أهم مفاهيم الحوسبة السحابية:

text
Multi-tenancy

أي أن عدة عملاء أو أحمال عمل قد تستخدم البنية المادية نفسها مع الاعتماد على عزل منطقي وتقني صارم بينها.

لذلك فإن cross-tenant compromise يختلف جذرياً عن اختراق تطبيق منفرد.

في السيناريو الأسوأ، يمكن لسلسلة هجوم من هذا النوع أن تبدو كالتالي:

text
Compromise tenant workload
        ↓
Gain guest-level privileges
        ↓
Escape microVM
        ↓
Gain host privileges
        ↓
Reach host resources
        ↓
Attempt access to other tenants

وهنا تنتقل المخاطر من نطاق أصل واحد إلى نطاق منصة مشتركة.

من منظور CIA Triad، قد يتأثر ما يلي:

البعدالتأثير المحتمل
السرية Confidentialityالوصول إلى بيانات أو ذاكرة أو أسرار تخص أحمال عمل أخرى
السلامة Integrityتعديل ملفات أو عمليات أو إعدادات على المضيف أو لدى مستأجرين آخرين
التوافر Availabilityتعطيل المضيف أو الأحمال الموجودة عليه
العزل Isolationانهيار الحد الفاصل بين العملاء والأحمال
الثقة Trustفقدان الثقة في طبقة يفترض أنها أساس الاحتواء

#لماذا أصبحت هذه الفئة أكثر حساسية مع انتشار وكلاء الذكاء الاصطناعي؟

بيئات Sandbox لم تعد مجرد أدوات لتشغيل أوامر بسيطة.

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

بمعنى آخر، البيئة قد تستقبل كوداً لم يكتبه مالك البنية التحتية أصلاً.

ولهذا يفترض تصميم Sandbox أن المحتوى الموجود داخله:

text
untrusted
hostile
potentially malicious

ومن هنا تأتي أهمية العزل على مستوى microVM.

إذا كانت المؤسسة تسمح لوكلاء ذكاء اصطناعي بتوليد وتشغيل كود داخل بيئات معزولة، فإن نموذج التهديد يجب ألا يتوقف عند:

text
prompt injection
malicious package
command execution

بل يجب أن يمتد إلى:

text
sandbox escape
kernel exploitation
hypervisor escape
cross-tenant compromise
credential exposure
network policy bypass

الذكاء الاصطناعي لم يخلق هذه الفئات من الثغرات، لكنه يزيد عدد السيناريوهات التي يُشغّل فيها كود غير موثوق بصورة آلية وعلى نطاق واسع.

#ما علاقة Firecracker بالموضوع؟

Firecracker هو Virtual Machine Monitor مفتوح المصدر صُمم لتشغيل microVMs خفيفة وسريعة مع تقليل مساحة الهجوم مقارنة ببعض منصات الافتراضية العامة الأكثر تعقيداً.

تستخدمه منصات سحابية لتوفير بيئات قصيرة العمر وعالية العزل.

لكن تقليل مساحة الهجوم لا يعني إلغاءها.

أي طبقة تتعامل مع:

text
guest memory
virtual devices
interrupts
I/O
virtio
kernel interfaces
CPU virtualization

يمكن نظرياً أن تحتوي على أخطاء أمنية.

ولهذا فإن أمن الـ Sandbox لا يعتمد فقط على قوة مكوّن واحد، بل على سلسلة كاملة من الحدود والافتراضات الأمنية.

#لماذا جائزة 50,000 USD أثارت الجدل؟

كانت الثغرة ضمن تحدي أطلقته Vercel بميزانية إجمالية تصل إلى:

text
1,000,000 USD

لكن الحد الأقصى للمكافأة عن التقرير الواحد في البرنامج كان:

text
50,000 USD

وحصل الباحث على هذا الحد الأقصى.

من هنا بدأ الجدل: إذا كانت النتيجة الفعلية هي هروب من microVM إلى مضيف سحابي مع أثر محتمل عبر المستأجرين، فهل تعكس مكافأة بهذا الحجم القيمة الاقتصادية والأمنية الحقيقية للثغرة؟

هذه المسألة ليست محاسبية فقط.

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

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

#كيف يجب أن تقرأ فرق GRC هذا الحدث؟

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

السؤال الذي يجب أن يُطرح ليس فقط:

هل نستخدم KVM؟

بل:

أين نعتمد على العزل الافتراضي كضابط أساسي؟ وما الأثر إذا فشل هذا الضابط بالكامل؟

هذا التحول في السؤال مهم، لأن المؤسسة قد لا تدير KVM بنفسها، لكنها قد تعتمد عليه بشكل غير مباشر داخل خدمات سحابية ومنصات Sandbox وحلول تشغيل وكلاء الذكاء الاصطناعي ومزودي الاستضافة.

#قراءة الحادثة من منظور إدارة المخاطر

يمكن تمثيل الخطر بصورة مبسطة كالتالي:

عنصر الخطرالتقييم
الأصل المتأثرمضيف افتراضي وبيئات مستأجرين متعددة
مصدر التهديدمهاجم لديه قدرة على تشغيل كود داخل ضيف
السيناريوتجاوز حدود الـ microVM والوصول إلى المضيف
الأثرمرتفع جداً في حال تحقق الوصول عبر المستأجرين
الاحتماليةغير قابلة للتقدير بدقة قبل نشر التفاصيل
مستوى عدم اليقينمرتفع
أولوية المتابعةحرجة للجهات التي تعتمد على بيئات تشغيل كود غير موثوق

النقطة الأساسية هنا أن الأثر مرتفع، لكن الاحتمالية ما زالت غير معروفة.

وهذا فرق جوهري في Risk Assessment.

عدم وجود تفاصيل علنية لا يعني أن الخطر منخفض، لكنه يعني أيضاً أن المؤسسة لا تملك حتى الآن بيانات كافية لتفترض أن كل بيئة KVM لديها معرضة مباشرة.

#ماذا تعني الحادثة للامتثال في السعودية؟

بالنسبة للجهات الخاضعة للمتطلبات الوطنية في المملكة، فإن هذا النوع من الأحداث يرتبط مباشرة بمفاهيم موجودة ضمن ضوابط الهيئة الوطنية للأمن السيبراني، خصوصاً:

text
ECC 2-2024
CCC 2-2024

فـ ECC 2-2024 تغطي مجالات مثل الحوكمة، وإدارة المخاطر، وتعزيز الدفاع، والصمود، إضافة إلى الأمن السيبراني المتعلق بالأطراف الخارجية والحوسبة السحابية.

أما CCC 2-2024 فتركز بصورة أكثر مباشرة على متطلبات الأمن السيبراني المرتبطة بمقدمي الخدمات السحابية والمشتركين فيها.

الحادثة تبرز عملياً أهمية المجالات التالية:

المجالالسؤال الذي يجب أن تجيب عنه الجهة
إدارة مخاطر الأمن السيبرانيهل فشل طبقة العزل الافتراضي موجود ضمن سيناريوهات المخاطر؟
إدارة الأطراف الخارجيةهل يوفر المورّد آلية واضحة للإفصاح عن ثغرات الـ hypervisor ومعالجتها؟
الحوسبة السحابيةهل نعرف نموذج المسؤولية المشترك وحدود العزل الفعلية؟
إدارة الثغراتكيف تصلنا تحديثات الثغرات الحرجة في طبقات لا نديرها مباشرة؟
الاستجابة للحوادثهل توجد إجراءات للتعامل مع احتمال اختراق طبقة المضيف؟
استمرارية الأعمالهل يمكن نقل الأحمال سريعاً إذا أصبح مكوّن افتراضي معين غير موثوق؟
حماية البياناتما تصنيف البيانات الموجودة في البيئات التي تشغّل كوداً غير موثوق؟

#ما الذي يجب أن تراجعه المؤسسات الآن؟

عدم وجود CVE أو تصحيح معلن لا يعني عدم وجود عمل يمكن تنفيذه.

الخطوة الأولى هي تحديد التعرض الفعلي.

ينبغي معرفة أين تستخدم المؤسسة أو مورّدوها:

text
KVM
Firecracker
microVM
sandboxed code execution
multi-tenant compute
AI agent sandboxes
untrusted code execution

بعد ذلك، يجب تحديد ما إذا كانت هذه البيئات:

text
internet-facing
multi-tenant
handling sensitive data
holding credentials
connected to production networks
capable of reaching internal services

كلما اجتمعت هذه الخصائص، زادت أهمية متابعة الإفصاح الفني فور صدوره.

#الضوابط التعويضية أهم من انتظار التصحيح

عندما تكون الثغرة zero-day ولا يوجد تحديث متاح بعد، تتحول الأولوية إلى تقليل مساحة الضرر.

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

ومن أمثلتها:

text
network segmentation
least privilege
short-lived credentials
secret isolation
host hardening
workload separation
tenant isolation
rapid host recycling
centralized logging
behavioral monitoring
egress control

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

الفكرة ليست أن هذه الضوابط تمنع VM Escape نفسه بالضرورة، بل أنها تقلل قيمة المضيف للمهاجم بعد نجاح الهروب.

#لماذا تعد بيانات الاعتماد داخل الـ Sandbox نقطة حساسة؟

لو استطاع مهاجم الهروب من البيئة المعزولة، فإن السؤال التالي مباشرة هو: ما الذي يستطيع سرقته؟

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

لهذا تتجه التصاميم الحديثة إلى:

text
short-lived credentials
task-scoped credentials
credential injection at trusted boundaries
automatic rotation

كلما قل زمن صلاحية السر وقل نطاقه، انخفض الأثر الذي يستطيع المهاجم حمله معه بعد انتهاء جلسة الاختراق.

#الرصد التقليدي قد لا يكون كافياً

أنظمة الحماية داخل الضيف قد ترى المهاجم قبل الهروب، لكنها قد تفقد الرؤية بعد انتقاله إلى المضيف.

لذلك تحتاج البيئات عالية الحساسية إلى رصد على أكثر من طبقة:

text
guest telemetry
host telemetry
kernel events
hypervisor events
network telemetry
cloud control-plane logs
identity logs

ويجب ربط الأحداث زمنياً، لأن التسلسل هو الذي يكشف القصة:

text
unexpected guest behavior
        ↓
kernel anomaly
        ↓
host process execution
        ↓
credential access
        ↓
cross-tenant network activity

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

#متى يتحول الخبر إلى حالة طوارئ تشغيلية؟

ستتغير درجة الاستجابة فور نشر واحد أو أكثر من العناصر التالية:

text
CVE identifier
affected versions
reliable proof of concept
public exploit
confirmed exploitation in the wild
vendor patch
mitigation guidance

وجود استغلال عام ونسخ متأثرة محددة سيحوّل الحدث من خطر استراتيجي يحتاج متابعة مكثفة إلى حالة Vulnerability Management قابلة للقياس والتنفيذ.

عندها يصبح السؤال:

text
Are we affected?

بدلاً من:

text
Could we be affected?

وهذا الفرق هو ما يحدد الانتقال من المراقبة والتحليل إلى الاحتواء والترقيع والاستجابة للحوادث.

#ما الذي لا نعرفه حتى الآن؟

حتى وقت كتابة المقال، لا تزال عدة نقاط أساسية غير معلنة:

text
root cause
affected KVM versions
affected Linux kernel versions
affected Firecracker versions
exploit primitives
required guest privileges
reliability of exploitation
CVE identifier
patch details
evidence of in-the-wild exploitation

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

#الخلاصة

قيمة هذه الثغرة لا تكمن فقط في أنها سمحت بالخروج من آلة افتراضية.

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

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

في الحالتين، الدرس للمؤسسات واحد: لا ينبغي بناء الأمن على حد عزل واحد فقط.

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

فأخطر لحظة في أمن السحابة ليست عندما يخترق المهاجم تطبيقاً.

إنها عندما يكتشف أن الجدار الذي يفترض أن ينهي الهجوم ليس جداراً على الإطلاق.

#المصادر