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

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

OpenClaw منصة انتشرت انتشاراً واسعاً للسيناريوهات القائمة على الوكلاء (agentic)، وتعمل على جهاز المستخدم أو داخل بنيته التحتية الخاصة، وتستطيع التعامل بنفسها مع التطبيقات والملفات والمتصفح والخدمات الخارجية. وسعياً للراحة، تُمنح عادةً مجموعة واسعة من الأذونات: الوصول إلى المجلدات المحلية والمحادثات وأدوات المؤسسة ومفاتيح API والجلسات المصادَق عليها مسبقاً. ومع مطلع أبريل 2026 جمع المشروع نحو 347 ألف نجمة على GitHub، وهذا الحجم تحديداً يجعل أي ثغرة في نموذج الأمان الأساسي مؤلمة على نحو خاص.

وقد طالت المشكلة، التي حصلت على المعرّف CVE-2026-33579، إصدارات OpenClaw السابقة للإصدار 2026.3.28. ووفق وصف NVD وGitHub Advisory، لم يكن النظام ينقل في سلسلة الأمر /pair approve القيود المفروضة على صلاحيات من يوافق على ربط جهاز جديد. وعملياً، كان بإمكان مشارك يملك الحد الأدنى من الصلاحيات operator.pairing أن يوافق على طلب يتضمن مجموعة أوسع من الصلاحيات، بما فيها operator.admin، فيحوّل جهازه بصمت إلى جهاز بصلاحيات المسؤول. وصدر الإصلاح ضمن الإصدار 2026.3.28 المنشور في 29 مارس 2026. وبلغ تقييم خطورة هذه الثغرة 9,4–9,8 نقطة بحسب المنهجية المعتمدة، وهو ما يعني عملياً، في هذه الفئة من البرمجيات، استيلاءً كاملاً على النسخة.

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

وأضافت الفترة الفاصلة بين صدور التصحيح في 29 مارس والتسجيل الرسمي للثغرة CVE في 1 أبريل 2026 خطراً إضافياً. ففي هذين اليومين كان بإمكان المهاجمين إدراك خطورة الخلل أسرع مما يدرك كثير من المسؤولين ما الذي يجب تحديثه بصورة عاجلة.

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

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

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