حصل هروب من sandbox في Skyvern، الوكيل المستضاف ذاتيًا الذي يقود متصفح ويب عبر خطوات مولدة بواسطة LLM، على الرقم CVE-2026-82447 ونُشر في قاعدة بيانات GitHub Advisory Database في 29 أغسطس 2026 عند 15:30:19 UTC. أما إصلاح الشيفرة الذي يصفه فقد وصل إلى المستودع في 6 يوليو عند 21:44:03 UTC — أي قبل ذلك بـ 53 يومًا.
ما الذي كان الخلل فعليًا
كان TextPromptBlock في Skyvern يعرض كل prompt مرتين. كانت المرحلة الأولى تمر عبر SandboxedEnvironment في Jinja كما هو مقصود. أما المرحلة الثانية فكانت تمرّر السلسلة نفسها، المتأثرة بالمهاجم، عبر renderer غير معزول، وهو ما يكفي لتنفيذ الشيفرة بصفتها عملية الخادم. أما الإصلاح، commit d723de6، فهو حذف: ثلاثة أسطر أُضيفت وأُزيل أحد عشر سطرًا في block.py، مع إسقاط إعادة العرض الثانية ومعامل parameter_values الذي كان يغذيها. وبقية commit عبارة عن اختبارات.
أين يختلّ التأطير
ثمة شيئان يُقالان عن التنبيهات من هذا النوع، لكنهما غير صحيحين هنا. الأول أنه كان patch «صامتًا». لم يكن كذلك: ملاحظات إصدار v1.0.45، المنشورة في 7 يوليو عند 22:19:18 UTC, تتضمن بالفعل كلمة "SSTI". لكن ذلك لم يكن سوى بند واحد ضمن نص إصدار يمتد لنحو 190 سطرًا، من دون أي تنبيه أمني من المورّد، ومن دون CVE في ذلك الوقت، ومن دون ما يميّزه عن حركة سجل التغييرات الروتينية. والثاني هو الإيحاء بأن سنة CVE تخبرك متى كنتَ معرضًا للخطر. لكنها لا تفعل — فقد أصدر VulnCheck الرقم بوصفه جهة ترقيم طرفًا ثالثًا، لا المشروع نفسه.
الجزء الذي يكسر الأدوات
يحمل سجل التنبيه درجة CVSS 3.1 قدرها 8.8 ودرجة CVSS 4.0 قدرها 8.7، ويُصنَّف CWE-1336. لكن مصفوفة vulnerabilities المهيكلة فيه فارغة. أما النطاق المتأثر — 0.2.1 حتى ما قبل 1.0.45 — فلا يوجد إلا كنص في صفحة VulnCheck. أي أداة فحص تقرأ بيانات التنبيه المهيكلة في GitHub وتطابق اعتماد skyvern مثبتًا لديها عليها، ستُظهر لا شيء على الإطلاق.
لماذا يتكرر هذا الشكل
مسار الاستغلال ليس غريبًا. فمعامل في workflow، أو مخرجات block أعلى في السلسلة، هو نص أنتجه الوكيل نفسه أو استقبله؛ ثم يصل إلى template renderer؛ ثم يصبح شيفرة على مضيف الوكيل. هذه هي وصلة الحقن-إلى-التنفيذ بأبسط صورها، وهي بنيوية في الأدوات التي تسمح لمخرجات النموذج بأن توجه طبقة القوالب.