ماذا حدث
رصد باحثو وحدة Unit 42 التابعة لشركة Palo Alto Networks ثغرة أمنية في حزمة تطوير برمجيات Vertex AI SDK الخاصة بلغة بايثون، تُتيح لمهاجم من خارج مشروع الضحية تماماً اختطاف عملية رفع نماذج التعلم الآلي (Machine Learning models) وتنفيذ كود خبيث داخل بنية خدمة Vertex AI التحتية لدى غوغل. أُبلغت غوغل عن الثغرة عبر برنامج مكافآت اكتشاف الثغرات (Vulnerability Reward Program) في 5 مارس 2026، وأصدرت تصحيحاً كاملاً في الإصدار 1.148.0 بتاريخ 15 أبريل 2026. لم تُرصد أي عمليات استغلال فعلية حتى الآن.
التفاصيل
### كيف يعمل الهجوم؟
أطلق الباحثون على هذا الأسلوب اسم **"Pickle in the Middle"**، في إشارة إلى صيغة التسلسل (serialization) الشائعة في بايثون. تكمن جذر المشكلة في آلية اختيار الحزمة للحاوية المؤقتة في خدمة Cloud Storage عند رفع النماذج:
- حين لا يحدد المطور معامل `staging_bucket` صراحةً، تُولّد الحزمة اسماً متوقعاً ومشتقاً من معرّف المشروع والمنطقة الجغرافية، على نحو `project-vertex-staging-region`.
- الحزمة تتحقق من وجود هذه الحاوية، لكنها **لا تتحقق من ملكية الضحية لها**.
- لأن أسماء الحاويات فريدة على مستوى عالمي، يستطيع أي مهاجم يعرف معرّف المشروع (غالباً معلومة عامة) إنشاء الحاوية المتوقعة مسبقاً في مشروعه الخاص.
### خطوات الهجوم عملياً
1. يُنشئ المهاجم الحاوية المتوقعة قبل الضحية. 2. يرفع SDK الضحية ملفات النموذج إلى حاوية المهاجم دون أن يدرك ذلك. 3. خلال نافذة زمنية تبلغ نحو **2.5 ثانية** بين اكتمال الرفع وقراءة Vertex AI للملف، يستبدل المهاجم النموذج المرفوع بآخر خبيث. 4. في إثبات المفهوم (Proof of Concept)، استخدم الباحثون دالة Cloud Function أتمّت الاستبدال في **1.4 ثانية** فقط. 5. لأن نماذج بايثون كثيراً ما تُحفظ بصيغتَي pickle أو joblib القادرتين على تنفيذ كود لدى تحميل الملف، يُنفَّذ الكود الخبيث داخل حاوية الخدمة (serving container).
### ما الذي يستطيع المهاجم الوصول إليه؟
في بيئة الاختبار، أتاح الرمز المُنفَّذ سرقة رمز OAuth token من خادم البيانات الوصفية (metadata server) للحاوية. وتبيّن أن هذا الرمز لم يقتصر على النشر المخترق، بل امتدت صلاحياته لتشمل:
- نماذج TensorFlow أخرى مع أوزانها المدرَّبة داخل مشروع المستأجر المُدار من غوغل
- بيانات وصفية من BigQuery وقوائم التحكم بالوصول وسجلات المستأجر
- أسماء كتل GKE ومسارات صور الحاويات الداخلية
### شروط الهجوم
يشترط الهجوم توفر حالتين معاً: ألا تكون الحاوية الافتراضية للضحية موجودة مسبقاً في تلك المنطقة، وأن يترك المطور معامل `staging_bucket` دون تحديد. وكلا الشرطين شائعان لدى المشاريع الجديدة.
### الجدول الزمني للإصلاح
| التاريخ | الإجراء | |---|---| | 5 مارس 2026 | إبلاغ غوغل بالثغرة | | 31 مارس 2026 | إصلاح أولي في v1.144.0 بإضافة uuid4 عشوائي لاسم الحاوية | | 15 أبريل 2026 | إصلاح كامل في v1.148.0 بإضافة التحقق من ملكية الحاوية |
لم يُخصَّص معرّف CVE لهذه الثغرة حتى تاريخ النشر.
لماذا يهمّك
هذه ثاني ثغرة من نوع "اختطاف الحاوية" (Bucket Squatting) تُكشف في Vertex AI خلال عام واحد؛ إذ أصلحت غوغل في فبراير 2026 ثغرة مستقلة تحمل المعرّف CVE-2026-2473 في خدمة Vertex AI Experiments أتاحت هي الأخرى تنفيذ كود عبر المستأجرين وسرقة النماذج. يُظهر هذا النمط أن الاعتماد على أسماء متوقعة للموارد المشتركة يُمثّل سطح هجوم قابلاً للتكرار في بيئات السحابة.
الخطورة البالغة هنا أن المهاجم لا يحتاج إلى أي صلاحيات على مشروع الضحية، ولا إلى تصيّد احتيالي أو برمجيات خبيثة تقليدية. معرفة معرّف المشروع وحده كافية للبدء.
توصيات
1. **التحديث الفوري**: رفّع حزمة `google-cloud-aiplatform` إلى الإصدار 1.148.0 أو أحدث في جميع البيئات. 2. **تحديد الحاوية صراحةً**: حدد دائماً معامل `staging_bucket` بحاوية Cloud Storage تمتلكها وتتحكم بها عند رفع النماذج. 3. **فحص شامل للبيئات**: تحقق من إصدار الحزمة في كل مكان تُستخدم فيه، بما يشمل دفاتر Jupyter notebooks وعمليات CI/CD والأنابيب التدريبية (training pipelines)، لا في بيئة الإنتاج وحدها. 4. **مراجعة صلاحيات الوصول**: تحقق من نطاق صلاحيات الرموز المستخدمة في بيئات Vertex AI وقيّدها وفق مبدأ الحد الأدنى من الصلاحيات.
