DeepSeek Harness CVE-2026-82533: وكيل يعمل داخل بيئة معزولة يعطّل بيئته المعزولة الخاصة بأمر واحد

نشرت VulnCheck الثغرة CVE-2026-82533 في 8 سبتمبر 2026: تجاوز مصادقة حرج سمح لوكيل برمجة بالذكاء الاصطناعي بتعطيل بيئته المعزولة بنفسه باستخدام أمر شِل واحد. البرنامج هو DeepSeek Harness، بيئة التشغيل المحلية مفتوحة المصدر الخاصة بـ DeepSeek لوكلاء البرمجة، والتي تقول Cloud Security Alliance إنها جذبت نحو 215,000 نجمة على GitHub في غضون أسابيع؛ وكل الإصدارات السابقة لـ 0.1.2-alpha.1 متأثرة. كانت تحكم على ما إذا كان المستدعي محليًا استنادًا إلى ترويسة Host الخاصة بالمستدعي نفسه، لذا كان بإمكان أي طلب ادعاء أنه قادم من loopback. ولأن بيئتها المعزولة كانت تقيّد كتابة الملفات لكن ليس شبكات loopback، فقد كان بإمكان وكيل مقيّد استدعاء واجهة API التحكم غير المصادق عليها الخاصة بـ Harness على المنفذ 3080 وتحويل جلسته إلى danger-full-access مع تعطيل الموافقات. تصنفها VulnCheck بدرجة 9.4، حرجة؛ ولا يُدّعى وقوع أي استغلال في العالم الحقيقي. والسجل هو مدخل واحد في مجموعة بيانات عامة لحوادث الذكاء الاصطناعي، وأرشيف Orca لحوادث الذكاء الاصطناعي يضم مجموعة السجلات الكاملة، مع التواريخ ودرجات الخطورة والمصادر لكل مدخل.

الفحص الذي سأل الطلب عن ماهيته

المكوّن المعرّض للثغرة هو واجهة برمجة تطبيقات التحكم بالوكيل المحلي الخاصة بـ harness، وهي خدمة HTTP صغيرة تستخدمها واجهة الويب وسطر الأوامر لتشغيل جلسة قيد التشغيل. وفقًا لمذكرة البحث الصادرة عن Cloud Security Alliance في 10 سبتمبر 2026، والتي تستند إلى التقرير المكتوب من OX Security، الشركة التي اكتشفت العيب، فإن تلك الخدمة كانت تستمع على 127.0.0.1 المنفذ 3080 افتراضيًا، واتخذت قرار الثقة الخاص بها في دالة تسميها المذكرة isTrustedApiRequest. كانت الدالة تقرأ ترويسة HTTP Host وتمنح الوصول عندما تطابق القيمة اسمًا من أسماء loopback مثل localhost أو 127.0.0.1. ترويسة Host هي بيانات وصفية يكتبها العميل؛ وهي لا تقول شيئًا عن مكان اتصال TCP الذي جاء منه. ويذكر The Hacker News، نقلًا عن المصدر المتأثر في 9 سبتمبر 2026، أن الفحص لم ينظر قط إلى أصل الاتصال، وأن تعليقًا في الملف نفسه يقول إن الفحص "is not an auth layer."

هذا هو جوهر CWE-807، أي الاعتماد على مدخلات غير موثوقة في قرار أمني، وهو ما يصفه السجل المنشور من VulnCheck: قبول ترويسة Host من نوع loopback يقدّمها العميل بدلًا من التحقق من الأصل الفعلي لاتصال TCP.

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

لماذا لم توقفه مطالبات الموافقة

كانت أداة التشغيل تحتوي بالفعل على مطالبات موافقة، ولم يتم تجاوزها بقدر ما كانت غير قابلة للتطبيق. تذكر Hacker News أنه في الإصدار المتأثر لم تكن الموافقة تُطلب إلا عندما يسعى أمر ما إلى وصول أوسع مما كانت الجلسة تملكه بالفعل. ولم يكن استدعاء التصعيد يطلب شيئًا من هذا القبيل؛ بل غيّر إعداد الجلسة. وانتقل وكيل نفّذه إلى وضع تسميه OX Security danger-full-access، مع ضبط مطالبات الموافقة على خيار «أبدًا»، وواصل العمل بصفته المستخدم الذي أطلق أداة التشغيل، خارج البيئة المعزولة بالكامل.

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

المسار الثاني، والشرط المسبق الذي كان يحتاجه

عرّض نفس الفحص المفقود أداة الاختبار للمتصلين الذين لم يكونوا داخل صندوق رمل على الإطلاق، ولكن فقط في ظل شرط لم يُنشئه التكوين الافتراضي. رفض سطر الأوامر ربط واجهة برمجة التطبيقات (API) بجميع واجهات الشبكة، لذلك كان المنفذ قابلاً للوصول من مكان آخر فقط إذا كان المستخدم قد قام بإعادة توجيهه مسبقًا — عبر نفق، أو وكيل عكسي، أو إعادة توجيه SSH، أو ميزة إعادة توجيه المنفذ الخاصة بالمحرر، وفقًا لـ The Hacker News؛ وتدرج ملاحظة Cloud Security Alliance نفس المجموعة. وحيثما تحقق ذلك الشرط المسبق، ذكر استشارة VulnCheck أن المتصل الذي لا يملك بيانات اعتماد يمكنه إنشاء جلسات، وتنفيذ أوامر عشوائية، وتسريب نصوص المحادثات المخزنة. وأضافت The Hacker News أن نفس الواجهة قدّمت طلبًا يقوم بتنزيل السجل الكامل للجلسة.

يتطلب المسار المعزول شرطًا مسبقًا مختلفًا: نصًا سيقرأه الوكيل ويتصرف بناءً عليه. وتصف مذكرة Cloud Security Alliance وكيلًا محصورًا يتعامل مع توجيه مقدَّم من مهاجم ومضمَّن في تعليق برمجي أو ملف README أو نص مشكلة. ولا يتطلب أيٌّ من المسارين مفتاحًا مسروقًا، وتلاحظ المذكرة أن المسار البعيد لا يحتاج إلى أي تفاعل مع النموذج على الإطلاق بمجرد كشف المنفذ.

الفئة المعرّضة هي بالتالي كل من شغّل أداة الاختبار بالإصدار 0.1.1-rc.2 أو إصدار أقدم وبالإعدادات الافتراضية، وهي مجموعة لا يشير إليها عدد النجوم إلا إشارةً عابرة. وقد أحصت The Hacker News أكثر من 216,000 نجمة في 9 سبتمبر 2026، وحذّرت من أن النجمة إشارة مرجعية وليست عملية تثبيت.

ما هو ثابت، وما هو غير ثابت

ثبت، من سجل CVE نفسه: أن VulnCheck هي جهة الترقيم، وقد حجزت المعرّف في 29 أغسطس 2026 ونشرت السجل في 8 سبتمبر عند 16:59 UTC؛ والضعف هو CWE-807؛ والنطاق المتأثر هو كل إصدارات ما قبل 0.1.2-alpha.1؛ ويعود الفضل إلى Nir Zadok وMoshe Siman Tov Bustan. والدرجتان اللتان يحملهما السجل، 9.4 ضمن CVSS 4.0 و9.6 ضمن CVSS 3.1، مصدرهما VulnCheck وليس مُقيّمًا ثانيًا مستقلًا — إذ يُدرج NVD كلا المقياسين مع VulnCheck كمصدر لهما — لذا فهما تقييم واحد معبَّر عنه بإطارين، وليس تقييمين متوافقين.

اتضح من المستودع أن كوميت الإصلاح 3e24087، المعنون «fix(web): authenticate the browser Host API»، مؤرخ في 24 أغسطس 2026، وأنه يضيف وحدة مصادقة خاصة بالمتصفح إلى جانب 210 أسطر من اختبارات شاملة من طرف إلى طرف للتدفق الجديد، وفقًا لـ GitHub API. وتلا ذلك الإصدار الموسوم dsh-v0.1.2-alpha.1 في 27 أغسطس عند الساعة 17:06 بالتوقيت العالمي المنسق.

غير مُثبت: الاستخدام. لا يصف سجل CVE، ولا نشرة VulnCheck الاستشارية، ولا ملاحظات إصدار DeepSeek أي استغلال في البرية، ويسجّل NVD نضج الاستغلال على أنه غير محدد. أعطى نموذج EPSS التابع لـ FIRST للثغرة احتمال استغلال بنسبة 1.24% خلال الثلاثين يومًا التالية، عند المئين 68.9، في التغذية المؤرخة 27 أكتوبر 2026. ولا يسجّل الأرشيف أي ضرر في العالم الحقيقي لهذا المُدخل، ويصنّفه بدرجة ثقة A، موثّق جيدًا، مع اتفاق المصادر الأولية.

التواريخ، بما في ذلك تقريران جاءا أولاً

توصل مطوّران إلى الاستنتاج نفسه قبل أن يكون هناك CVE للإشارة إليه. تذكر The Hacker News منشورًا على لوحة النقاش الخاصة بالمشروع في 13 أغسطس 2026 يُظهر عملية لا تزال مقيّدة داخل البيئة المعزولة تصل إلى الواجهة المحلية وتحوّل الجلسة إلى danger-full-access، مع مخرجات الاختبار، ومنشورًا ثانيًا في 14 أغسطس يسرد الطلبات التي قبلتها تلك الواجهة دون بيانات اعتماد. أشار المنشور الثاني أيضًا إلى أن المشروع لم يكن لديه ملف سياسة أمنية ولا مسار خاص للإبلاغ عن ثغرة؛ وقد تحققت The Hacker News في 9 سبتمبر فوجدت أن ملف السياسة الأمنية لا يزال مفقودًا.

يضع الخط الزمني لـ OX Security تقريرها إلى VulnCheck في 24 أغسطس 2026 — وهو التاريخ نفسه الذي يسجله GitHub لالتزام الإصلاح. ولا تقول رسالة الالتزام شيئًا عن التقرير، كما أن الرواية العلنية لـ OX Security، كما تصفها The Hacker News، لا تذكر المنشورات المجتمعية السابقة. أما ما إذا كان الحدثان في 24 أغسطس مرتبطين، فليس ما ينص عليه السجل العام، ولا تفترض هذه المقالة ذلك.

الفجوة بين الإصلاح والإفصاح ليست غير مألوفة. تشير مذكرة تحالف أمن السحابة إلى أن OX Security أكدت الإصلاح في 30 أغسطس، أي قبل تسعة أيام من نشر VulnCheck لهوية CVE.

أين طُبّق الإصلاح، وأين لم يُطبّق

لم يتحرك وسم GitHub وسجل الحزم معًا، وهذا هو الجزء الجدير بالمعرفة إذا ثبّتت إطار العمل بالطريقة التي توحي بها تعليماته. نُشرت حزمة سطر الأوامر @deepseek-ai/dsh بالإصدار 0.1.1-rc.2 في 21 أغسطس 2026 ثم لم يصدر شيء حتى 0.1.2-alpha.2 في 30 أغسطس. الإصدار 0.1.2-alpha.1، الذي تذكره CVE بوصفه الإصلاح، غائب تمامًا عن السجل، لذا تأخر أول إصدار مُصلَح قابل للتثبيت عن الإصلاح بثلاثة أيام. تمت قراءة بيانات تعريف سجل npm الخاصة بهذا المقال في 28 أكتوبر 2026؛ وأبلغت The Hacker News عن الفجوة نفسها في 9 سبتمبر.

لم تُصِغ ملاحظات الإصدار ذلك على أنه إصدار أمني. فهي تدرج، ضمن تغييرات روتينية، أن واجهة الويب باتت تتطلب مصادقة برمز لمرة واحدة للوصول عبر الشبكة، من دون أي إشارة إلى CVE ومن دون إشعار أمني، ولم يعثر The Hacker News على أي استشارة أمنية في قائمة الاستشارات الخاصة بالمستودع في 9 سبتمبر. والآلية، كما تصفها Cloud Security Alliance: تطبع أداة التشغيل رمزًا لمرة واحدة عند بدء التشغيل، ويستبدل المتصفح ذلك الرمز بملف تعريف ارتباط موقّع، ويجب أن يقدّم كل استدعاء لاحق ملف تعريف الارتباط — إذ تُربط الثقة بسرّ يُصدر عند بدء العملية بدلًا من ربطها بأصل شبكي مُدّعى.

عمليات البناء من طرف ثالث هي النقطة العالقة. تشحن أغلفة سطح المكتب نسختها الخاصة من الهارنس، لذا فإن الإصدار الذي يستخدمه المستخدم هو خيار مشرف الغلاف؛ وجدت The Hacker News عملية بناء واحدة لنظام Windows مثبتة على 0.1.1-rc.2 في أواخر أغسطس وانتقلت إلى 0.1.3-alpha.1، التي تحمل الإصلاح، في 6 سبتمبر.

لم يتغيّر الـ sandbox نفسه. عند قراءة مرجع سطر الأوامر 0.1.2-rc.1، وجدت The Hacker News العبارة نفسها التي تفيد بأنّ القراءة والوصول إلى الشبكة غير مقيَّدين، ووجدت أنّ shell الخاص بالوكيل لا يزال يتلقّى عنوان الواجهة. ولا يذكر أي مصدر في ذلك التقرير ما إذا كان الوكيل العامل داخل مساحة عمله لا يزال قادرًا على الحصول على جلسة صالحة بموجب المخطط الجديد، وهو سؤال تتركه وثائق التصحيح نفسها مفتوحًا.

ما توصي به مصادر السجل

• تعامل مع أي تثبيت للإصدار 0.1.1-rc.2 أو أقدم منه باعتباره متأثرًا، بغض النظر عن طريقة تغليفه، بما في ذلك نسخة مضمّنة في غلاف لسطح المكتب.

ثبّت 0.1.2-alpha.2 أو إصدارًا أحدث من npm؛ كان أحدث إصدار على السجل في 27 أكتوبر 2026 هو 0.2.2-alpha.2.

• إذا لم تتمكن من الترقية، فأوقف واجهة الويب عندما لا تكون قيد الاستخدام، وأزل أي نفق أو وكيل أو إعادة توجيه منفذ يصل إلى المنفذ 3080.

• تحقّق مما إذا كان المنفذ 3080 قابلاً للوصول من أي مكان آخر غير loopback، بما في ذلك إعادة توجيه منافذ الحاويات والوكلاء العكسيون وأنفاق SSH.

• سجِّل تغييرات تصعيد الصلاحيات ووضع الموافقة على مستوى إطار التشغيل، لأن الهجوم نجح عبر جعل تصعيد غير مُصرَّح به يبدو كنشاط روتيني.

جميع الخمسة تأتي من ملاحظة Cloud Security Alliance وتقرير The Hacker News؛ ولا يتضمن سجل CVE نفسه أي إرشادات معالجة تتجاوز الإصدار المُصلح.

لماذا تقرأه Cloud Security Alliance كنمط

تضع ملاحظة Cloud Security Alliance هذه الثغرة CVE إلى جانب إخفاقين آخرين في احتواء وكلاء البرمجة وثّقتهما في 2026: GuardFall في 1 يوليو، حين أمكن دفع عشرة من أحد عشر وكيل برمجة مفتوح المصدر شائعًا إلى تنفيذ أوامر shell صُممت حواجز الحماية فيها لحجبها، ونتائج تسليم الثقة في 22 يوليو، حين كتب وكيل محصور ملفًا نفّذه لاحقًا مكوّن موثوق خارج بيئة العزل. وتوضح الملاحظة صراحةً أن الإخفاقات الثلاثة كلها نابعة من أبحاثها الخاصة لا من مسح شامل للسوق، وأن ما إذا كان النمط يتعمم خارج الوكلاء التي فحصتها ليس أمرًا مثبتًا. لكنها تجادل بأن الإخفاقات تقع في طبقات مختلفة — حواجز حماية الأوامر، والثقة اللاحقة، والآن مصادقة طبقة التحكم — ولهذا توصي بالتعامل مع بنية العزل كمسألة توريد بدلًا من متطلب تم تلبيته.

لا تتعارض وثائق السلامة الخاصة بـ DeepSeek نفسها مع هذا التفسير. ويذكر ملف SAFETY.md في المستودع أن البرنامج "لم يخضع لتدقيق أمني ويجب ألا يُعامل على أنه آمن أو جاهز للإنتاج"، وأن العزل عبر الصناديق الرملية ومطالبات الموافقة وضوابط الأذونات "لا تضمن العزل أو تمنع وقوع الضرر". وقد أُغلقت في الإصدارات الحالية ثغرة المصادقة التي سمحت لوكيل بالتسلل إلى الخارج عبر واجهة برمجة تطبيقات التحكم. أما عدم التماثل الذي جعل هذا التسلل قصيرًا — حدود حول عمليات الكتابة ولا شيء حول الشبكة — فيظل قيدًا معلنًا على الصندوق الرملي بدلًا من أن يكون عيبًا كانت حزمة التصحيحات تهدف إلى إصلاحه.