ثغرة في OpenClaw تسمح برفع صلاحيات صامت إلى مسؤول على النسخ المعرضة

ثغرة في OpenClaw سمحت بترقية صامتة لصلاحيات المسؤول على النسخ المكشوفة

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

من أجل الراحة، عادة ما يتم منحها مجموعة واسعة من الأذونات: الوصول إلى المجلدات المحلية والدردشات وأدوات الشركة ومفاتيح API والجلسات المصرح بها بالفعل. اعتباراً من بداية أبريل 2026، كان المشروع قد جمع حوالي 347 ألف نجمة على GitHub، وهذا الحجم يجعل أي ثغرة في نموذج الأمان الأساسي مؤلمة بشكل خاص. تأثرت الثغرة، المحددة بـ CVE-2026-33579، بإصدارات OpenClaw حتى 2026.

3.28. وفقاً لأوصاف NVD و GitHub Advisory، في سلسلة أوامر /pair approve، لم تقم النظام بنقل قيود الأذونات لمن كان يوافق على اتصال الجهاز الجديد.

في الممارسة العملية، هذا يعني أن المشارك الذي لديه صلاحيات minimal operator.pairing يمكنه الموافقة على طلب للحصول على مجموعة أوسع من الأذونات، بما فيها operator.admin، وتحويل جهازه بصمت إلى جهاز إداري.

تم تضمين الإصلاح في الإصدار 2026.3.28، الذي نُشر في 29 مارس 2026.

وصل تصنيف الخطورة لهذه الثغرة إلى 9.4–9.8 نقطة اعتماداً على المنهجية، وهو ما يعني فعلياً للفئة من البرامج الاستيلاء الكامل على النسخة.

الجانب الأكثر إزعاجاً في هذه القصة ليس الخلل نفسه فقط، بل ظروف الاستغلال الفعلية. أفاد باحثو Blink أنه عند مسح 135 ألف نسخة من OpenClaw يمكن الوصول إليها عبر الإنترنت، استجاب حوالي 63 في المائة—ما يقرب من 85 ألف تثبيت—لطلبات آلية الموافقة على pair بدون مصادقة. بعبارة أخرى، الحد الأدنى من متطلبات وجود صلاحيات pairing الأساسية في كثير من الحالات لم تعمل كحاجز على الإطلاق: كان الوصول إلى الشبكة بالفعل نقطة انطلاق كافية.

تم إنشاء مخاطر إضافية من خلال النافذة بين إصدار التصحيح في 29 مارس والتسجيل الرسمي لـ CVE في 1 أبريل 2026. خلال هذين اليومين، كان يمكن للمهاجمين فهم خطورة الخلل بسرعة أكبر من معظم المسؤولين فهم ما يحتاج إلى تحديث عاجل. عواقب مثل هذا الاختراق لـ OpenClaw خطيرة بشكل خاص بسبب طبيعة المنتج.

إذا كان الوكيل متصلاً بـ Slack و Telegram و Discord وأسهم الملفات والحسابات السحابية أو الأنظمة الداخلية، فإن الوصول الإداري إلى النسخة لا يوفر فقط التحكم في الواجهة، بل القدرة على قراءة البيانات واستخراج بيانات الاعتماد المحفوظة وتنفيذ استدعاءات tool عشوائية والتحرك جانباً عبر الخدمات المرتبطة. هذا هو السبب بالضبط في أن Microsoft، في 19 فبراير 2026، أوصت بمعاملة OpenClaw كرمز قابل للتنفيذ غير موثوق به مع بيانات اعتماد دائمة وعدم تشغيله على أجهزة عمل أو حاسوب شخصي عادية. وفقاً لـ Microsoft، السيناريو الآمن بأدنى حد هو جهاز افتراضي معزول منفصل وبيانات غير إنتاجية وحسابات مخصصة بامتيازات أدنى.

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

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