حذرت شركة كانونيكال من ثغرة أمنية بالغة الخطورة تؤثر في منصتي LXD وMicroCloud، وتحمل المعرف CVE-2026-112816، بعدما حصلت على أعلى درجة خطورة ممكنة وفق نظام تقييم الثغرات CVSS بمجموع 10 من 10، وذلك بسبب قدرتها على السماح للمهاجمين بانتحال هوية عملاء موثوقين والوصول إلى البنية التحتية الافتراضية دون الحاجة إلى امتلاك المفاتيح الخاصة المرتبطة بحساباتهم.
وتكمن خطورة الثغرة في أنها قد تمنح المهاجم إمكانية الوصول إلى العناقيد السحابية والآلات الافتراضية العاملة داخلها عبر استغلال خطأ في آلية التحقق من شهادات TLS، ما قد يؤدي في بعض السيناريوهات إلى الحصول على صلاحيات جذرية كاملة (Root Access) على الخادم المستهدف.
وقد سارعت كانونيكال إلى إصدار تحديثات أمنية لمعالجة المشكلة، داعية جميع المستخدمين والمؤسسات إلى تثبيت الإصدارات المحدثة بشكل عاجل.
كيف تعمل الثغرة الأمنية؟
تعتمد منصتا LXD وMicroCloud على بروتوكول المصادقة المتبادلة TLS أو ما يعرف بـ Mutual TLS للتحقق من هوية العملاء الذين يتصلون بواجهات البرمجة الخاصة بهما.
وفي الظروف الطبيعية، يتعين على العميل تقديم شهادة رقمية تثبت هويته وامتلاكه للمفتاح الخاص المرتبط بها. إلا أن الخلل المكتشف كان في طريقة تحقق الخادم من سلسلة الشهادات المقدمة أثناء عملية الاتصال.
وبحسب التحليل الفني، يقوم بروتوكول TLS بالتحقق فعليًا من ملكية المفتاح الخاص للشهادة الأولى فقط ضمن سلسلة الشهادات، بينما كانت آلية التحقق داخل LXD تسمح بمراجعة بقية الشهادات المرفقة بالطريقة نفسها دون التحقق من ملكيتها الحقيقية.
وهذا يعني أن المهاجم يمكنه الحصول على الشهادة العامة الخاصة بعميل موثوق وإرفاقها بسلسلة الاتصال الخاصة به، ليتم التعرف إليه من جانب الخادم باعتباره ذلك العميل الشرعي، رغم عدم امتلاكه المفتاح الخاص المرتبط بالشهادة الأصلية.
وبعبارة أخرى، لم يكن المهاجم بحاجة إلى سرقة المفاتيح السرية أو اختراق الحساب مباشرة، بل يكفيه الحصول على الشهادة العامة للعميل الموثوق واستغلال آلية التحقق المعيبة لانتحال هويته بالكامل.
نطاق التأثير والمخاطر المحتملة
رغم خطورة الثغرة، فإن استغلالها يتطلب توافر شرطين أساسيين.
أولهما امتلاك المهاجم إمكانية الوصول الشبكي إلى واجهة HTTPS الخاصة بخادم LXD أو MicroCloud. أما الشرط الثاني فهو الحصول على الشهادة العامة لأحد العملاء الذين يثق بهم النظام مسبقًا.
وفي بيئات LXD المستقلة لا يتم عادة تفعيل واجهة الوصول الشبكي بشكل افتراضي، حيث تعمل الخدمة عبر مقبس محلي فقط، ما يقلل من فرص الاستغلال في البيئات المغلقة.
لكن الوضع يختلف في بيئات MicroCloud، التي تعتمد على دمج عدة خوادم ضمن عنقود سحابي موحد. ففي هذه البيئات قد يتمكن المهاجم من التقاط شهادة عامة لأحد الأعضاء أثناء انضمامه إلى العنقود، ثم استخدامها لاحقًا لانتحال هويته والدخول إلى النظام.
وتزداد المخاطر بصورة كبيرة إذا كان الحساب المنتحل يمتلك صلاحيات إدارية مرتفعة، إذ يمكن للمهاجم حينها الوصول إلى الأجهزة الافتراضية وإدارة الموارد السحابية، بل وربما امتلاك سيطرة كاملة على الخادم المضيف نفسه.
المشروعات المتأثرة والإصدارات المصححة
أوضحت كانونيكال أن عدة إصدارات من LXD تأثرت بالثغرة قبل طرح التحديثات الأمنية اللازمة.
وشملت الإصدارات المتأثرة:
- LXD 4.0.14 وما قبله ضمن هذا الفرع.
- LXD 5.0.10 وما قبله.
- LXD 5.21.8 وما قبله.
- LXD 6.9 وما قبله.
أما الإصدارات المصححة فتشمل:
- LXD 6.10.1 لقناة 6/stable.
- LXD 5.21.9 لقناة 5.21/stable.
- LXD 5.0.11 لقناة 5.0/stable.
- LXD 4.0.15 لقناة 4.0/stable.
- MicroCloud 3.4.1 لقناة 3/stable.
- MicroCloud 2.1.5 لقناة 2/stable.
ومن اللافت أن الثغرة لم تُكتشف داخل مشروع كانونيكال نفسه، بل أُبلغ عنها لأول مرة من قبل مشروع Incus، وهو مشروع مجتمعي نشأ كنسخة متفرعة من LXD. وبعد التحقق من البلاغ أكدت كانونيكال أن الخلل يؤثر أيضًا على منتجاتها، وتم إصدار الإصلاحات الأمنية اللازمة. كما قام مشروع Incus بمعالجة المشكلة في الإصدار 7.6.0.
لا مؤشرات على استغلال فعلي حتى الآن
بحسب المعلومات المتاحة حتى الآن، لا توجد أدلة علنية تشير إلى تعرض أي مؤسسة لهجمات فعلية استغلت هذه الثغرة.
كما أشارت وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية (CISA) إلى أن الثغرة ليست ضمن قائمة الثغرات المعروفة المستغلة حاليًا، ولم يتم نشر أدوات استغلال عامة أو نماذج هجومية عملية لها حتى الآن.
ورغم ذلك، يؤكد خبراء الأمن السيبراني أن حصول الثغرة على أعلى تصنيف خطورة يجعل من الضروري التعامل معها بصورة عاجلة، خصوصًا في البيئات السحابية ومراكز البيانات التي تعتمد على LXD أو MicroCloud لإدارة البنية التحتية الافتراضية.
إجراءات الحماية الموصى بها
تنصح كانونيكال جميع المستخدمين بتحديث المنصات المتأثرة فورًا إلى الإصدارات المصححة المتاحة عبر قنوات Snap الرسمية.
كما شددت الشركة على ضرورة التحقق من أرقام الإصدارات بعد عملية التحديث للتأكد من وصول الترقيات الأمنية بالفعل إلى بيئة التشغيل.
وفي حال تعذر تنفيذ التحديث بشكل فوري، يوصي الخبراء بتقييد الوصول إلى واجهات HTTPS الخاصة بالخوادم وحصرها على العناوين والمستخدمين الموثوقين فقط، نظرًا لأن نجاح الهجوم يعتمد بشكل أساسي على إمكانية الوصول الشبكي إلى الخدمة.
ويبرز هذا الاكتشاف مجددًا أهمية تدقيق آليات المصادقة المعتمدة على الشهادات الرقمية داخل البيئات السحابية الحديثة، إذ إن أي خلل بسيط في التحقق من الهوية قد يؤدي إلى تجاوز كامل لطبقات الحماية الأمنية وفتح الباب أمام سيطرة المهاجمين على بنى تحتية واسعة النطاق.
