rickidevs/cve-2026-32913وجدت ثغرة يوم-الصفر في OpenClaw — إليك كيف سارت الأمور
أثناء مراجعتي للكود المصدري، ركّزت على كيفية تعامل OpenClaw مع طلبات HTTP — وتحديداً الدالة fetchWithSsrFGuard()، المسؤولة عن إجراء استدعاءات الجلب من جانب الخادم.
لاحظت شيئاً غير طبيعي.
عندما يتبع الطلب إعادة توجيه عبر النطاقات (أي أن الخادم أرسل استجابة 3xx تشير إلى نطاق مختلف)، كان من المفترض أن يقوم OpenClaw بتجريد رؤوس الحساسية قبل إعادة توجيه الطلب إلى الوجهة الجديدة. وقد فعل ذلك — ولكن فقط لقائمة حظر محددة مكتوبة يدوياً:
Authorization, Proxy-Authorization, Cookie, Cookie2
المشكلة؟ هذه القائمة غير مكتملة.
رؤوس التفويض المخصصة مثل X-Api-Key أو Private-Token أو أي رأس آخر بنمط الحامل (Bearer) الذي يستخدمه المطورون بشكل شائع — لم يتم تجريد أيٍّ منها. بل تم إعادة توجيهها كما هي إلى وجهة إعادة التوجيه.
هذا يعني: إذا تمكن المهاجم من التحكم أو التأثير على وجهة إعادة التوجيه، فقد يحصل على بيانات اعتماد حساسة لم تكن مخصصة له أبداً.
تخيّل أن تطبيقك يستخدم OpenClaw لاستدعاء واجهة برمجة تطبيقات داخلية مع رأس X-Api-Key مخصص. يستجيب خادم خبيث بإعادة توجيه إلى عنوان URL يتحكم فيه المهاجم. يقوم OpenClaw باتباع إعادة التوجيه — ويُرسل مفتاح واجهة برمجة التطبيقات الخاص بك معه مباشرة.
انتهت اللعبة. بيانات اعتمادك الآن في أيدي شخص آخر.
درجة CVSS 3.1: 9.3 (حرجة)
استبدل القائمون على الصيانة نهج قائمة الحظر بقائمة سماح للرؤوس الآمنة. بدلاً من محاولة حظر الرؤوس الضارة المعروفة، يسمح المنطق الجديد فقط بالرؤوس الآمنة المعروفة عبر عمليات إعادة التوجيه عبر النطاقات — مثل أشياء التفاوض على المحتوى ومُتحققات التخزين المؤقت. يتم تجريد كل شيء آخر افتراضياً.
هذا هو النهج الصحيح. الأمن القائم على قائمة الحظر هشّ؛ الأمن القائم على قائمة السماح قوي.
المراجع
46715371b0612a6f9114dffd1466941ac476cef5<= 2026.3.2>= 2026.3.7قم بالتحديث فوراً إلى >= 2026.3.7.
إذا كنت تستخدم رؤوس تفويض مخصصة (مثل X-Api-Key أو Private-Token) وكنت على إصدار أقدم، فتعامل مع هذه البيانات الاعتمادية على أنها ربما تكون معرَّضة للخطر وقم بتدويرها.