في 15 سبتمبر 2026، نشرت Docker إعلاناً أمنياً لم يحصل إلا على جزء ضئيل من الاهتمام الذي يستحقه. ثغرتان في Docker Sandboxes، وهو المنتج الذي يشغّل كل وكيل برمجة ذكي داخل جهاز افتراضي خفيف خاص به، سمحتا للشيفرة داخل ذلك الجهاز بالخروج منه وملامسة المضيف. إحداهما مصنفة حرجة بدرجة CVSS 9.4. والأخرى عالية بدرجة 8.7. وقد تم إصلاحهما في الإصدار 0.42.0.
توقف لحظة عند جملة من وثائق Docker نفسها. إن حد المراقب الفائق "هو ضابط العزل، وليس فصل الصلاحيات داخل الجهاز الافتراضي". أي أن كل ما داخل الجهاز الافتراضي يُفترض أنه معادٍ: الوكيل، والحزم التي يثبتها، والأوامر التي ينفذها بصلاحيات الجذر. هذا هو التصميم كله. إن صندوق الرمل ليس غلافاً مريحاً حول أداة خطرة. إنه الضابط نفسه.
لذلك حين تجعل طبقة مشاركة الملفات، التي تجعل صندوق الرمل مفيداً، قابلاً للهروب أيضاً، ينهار نموذج الثقة.
ما كشفته Docker
يغطي إعلان Docker ثغرتين في Docker Sandboxes، الأداة التي تمنح كل وكيل برمجة ذكي جهازاً افتراضياً مصغراً خاصاً مع مشاركة مجلد المشروع.
- CVE-2026-77179 مصنفة حرجة، CVSS 9.4. تكمن في خادم المضيف virtio-fs، وهو الجانب المضيف من مشاركة الملفات بين جهاز Mac والجهاز الافتراضي. كان الخادم يتبع الروابط الرمزية عند إعادة فتح ملف محذوف من مسار مخزّن. ويمكن للضيف استبدال مجلد أب برابط رمزي، والخروج من مساحة العمل المشتركة، وقراءة أو تعديل ملفات عشوائية بصلاحيات مستخدم مراقب الجهاز الافتراضي، وهو حساب المضيف الذي يشغّل المراقب، "ما قد يؤدي إلى تنفيذ شيفرة على المضيف"، بحسب Docker. الإصدارات المتأثرة: من 0.28.0 وحتى ما قبل 0.42.0، على macOS فقط.
- CVE-2026-79994 مصنفة عالية، CVSS 8.7. تكمن في المرحّل الذي يتيح لصندوق الرمل الاتصال بمقابس Unix داخل مساحته المصرّح بها. كان المرحّل يتحقق من أن مسار المقبس داخل مساحة العمل، ثم يعيد الاتصال بالاسم. ويمكن لضيف يستبدل مجلداً على ذلك المسار برابط رمزي بين التحقق والاتصال أن يجعل المضيف يتصل بأي مقبس AF_UNIX خارج مساحة العمل، "ما يكشف بيانات أو قدرات على جانب المضيف يوفرها ذلك المقبس". الإصدارات المتأثرة: من 0.37.0 وحتى ما قبل 0.42.0.
تم إصلاح الثغرتين في الإصدار 0.42.0 في 7 سبتمبر 2026. وأحدث إصدار هو 0.43.0 الصادر في 15 سبتمبر. ولم تعلن Docker عن أي استغلال، وتشير تقييمات CISA في السجلات إلى عدم وجود استغلال، ولا توجد أي من الثغرتين في كتالوج الثغرات المستغلة المعروفة في نسخته الصادرة في 16 سبتمبر.
التفصيل المقلق
تقول وثائق Docker منذ مارس إن الروابط الرمزية التي تشير خارج مساحة العمل لا يتم اتباعها. كان ذلك هو الوعد. وCVE-2026-77179 هو مسار العودة إلى المسار المخزّن وهو ينقض ذلك الوعد بهدوء.
هذا هو النمط الذي تصادفه فرق الأمن مراراً في أدوات الوكلاء. الضوابط حقيقية، ونية التصميم سليمة، ثم يقوم فرع عودة واحد في مسار شيفرة واحد بالتصرف الساذج. يعمل الهروب بصلاحيات حساب المضيف الذي شغّل الجهاز الافتراضي. وإذا كان ذلك الحساب هو حساب الدخول اليومي للمطوّر، فكذلك كل ما يمكن الوصول إليه منه: مفاتيح SSH، وبيانات السحابة، وجلسات المتصفح، ومستودعات الشيفرة، وخزائن كلمات المرور.
لماذا لا تُعبّر درجة CVSS عن مستوى الخطر
لا يمكن استغلال أي من الثغرتين عن بعد. تحتاجان أولاً إلى شيفرة خبيثة داخل صندوق الرمل. يبدو ذلك مطمئناً حتى تتذكر ما هو وكيل البرمجة. إنه عملية تقرأ مدخلات غير موثوقة، وتتبع تعليمات مدمجة في تلك المدخلات، وتثبت حزماً من مستودعات عامة، وتنفذ شيفرة مولدة بصلاحيات مرتفعة داخل جهازه الافتراضي. وحقن الأوامر فئة هجوم نشطة وغير محلولة. وحزمة مسمومة أمر روتيني. الضيف ليس منطقة موثوقة، والتصميم كله يقول ذلك.
لذا فالسؤال الصادق ليس هل يمكن لأحد استغلال هذا. بل ما حجم الضرر الذي قد تلحقه أنت في اليوم الذي يستغله فيه أحد. إذا كانت وكلاؤك يعملون تحت حساب يحمل أيضاً بيانات الإنتاج، فالجواب هو: كل شيء.
ما ينبغي فعله هذا الأسبوع
- حدّث إلى الإصدار 0.42.0 أو أحدث. الإصدار 0.43.0 متاح. وإذا لم تستطع التحديث فوراً، فتنصح Docker باستخدام وضع النسخ، الذي يزيل تعرّض مساحة العمل المشتركة.
- احصر من يشغّل الوكلاء داخل صناديق الرمل. الإصدار، والنظام الأساسي، وحساب المضيف الذي يشغّل الجهاز الافتراضي. التصحيح الذي لا تستطيع إثبات تثبيته ليس تصحيحاً.
- امنح مراقب الجهاز الافتراضي حساباً خاصاً بأقل الصلاحيات. بلا بيانات سحابية، وبلا مفاتيح SSH، وبلا رموز نشر، وبلا وصول إلى خزانة كلمات المرور. الهروب يرث بالضبط الصلاحيات التي منحتها للجهاز الافتراضي.
- أبعد الأسرار عن مجلد المشروع المشترك. فمساحة العمل هي بالضبط ما صُمم صندوق الرمل لتسليمه إلى شيفرة غير موثوقة.
- تعامل مع حد العزل على أنه على بُعد خطأ واحد من الانهيار، لأنه كذلك. ضع طبقات: لا بيانات دائمة طويلة الأجل في بيئة الوكيل، ومراقبة الصادر على مضيفات الوكلاء، وجهاز منفصل لكل ما يمس الإنتاج.
- اجعل إيقاع تصحيح أدوات التطوير عملية أمنية، لا عادة. صناديق رمل الوكلاء تصدر أسبوعياً. ويجب أن تكون دورة مراجعتك أقصر من الفترة بين ثغراتها.
الدرس الأكبر
أمضينا العامين الماضيين ننصح الفرق بوضع وكلائها من الذكاء الاصطناعي داخل صناديق رمل. امنحوهم جهازاً افتراضياً، وحدوا شبكتهم، وأبعدوهم عن الإنتاج. تلك النصيحة لا تزال صحيحة، ولا تزال أفضل ضابط متاح.
لكن صندوق الرمل حد بين منطقتَي ثقة، والحدود تحتاج إلى الانضباط نفسه الذي نطبقه في كل مكان آخر: أقل الصلاحيات على الجانبين، وبلا بيانات عرضية، ومع المراقبة، ومع عملية تصحيح تعمل فعلاً. أصلحت Docker هاتين الثغرتين في ثمانية أيام وأعلنت عنهما بمسؤولية. كان العمل الهندسي جيداً. أما الدرس المقلق فهو أدق. في الأنظمة الوكيلة، يقرر كل مكوّن في السلسلة قيمة هذا الحد، وأضعف فرع عودة هو الذي يحدد الثمن.
إذا كان فريقك يشغّل وكلاء برمجة ذكية ولست متأكداً مما يمكنهم الوصول إليه من داخل صندوق الرمل، فهذا حوار يستحق أن يُجرى هذا الأسبوع.
المصادر
- إعلانات Docker الأمنية: تحديث أمني Docker Sandboxes 0.42.0 (CVE-2026-77179 وCVE-2026-79994)، 15 سبتمبر 2026
- The Hacker News: Critical Docker Sandboxes Flaw Lets Malicious Guest Code Read and Modify macOS Host Files، 17 سبتمبر 2026
- وثائق العزل في Docker Sandboxes
- إصدارا Docker sbx-releases v0.42.0 وv0.43.0