نظرة عامة
| المعلومة | القيمة |
|---|---|
| النظام المتأثر | خادم Azure DevOps MCP الرسمي من مايكروسوفت (الإصدار 2.7.0 مؤكَّد، و2.8.0 لا يزال متأثراً حتى 24 حزيران/يونيو) |
| نوع الثغرة | حقن أوامر خفي (Hidden Prompt Injection) عبر تعليقات HTML مخفية بوصف طلبات الدمج (Pull Requests) |
| رقم CVE | لم يُخصَّص رقم CVE حتى تاريخ نشر هذا المقال |
| الوكلاء المتأثرون | متوافقة مع Copilot CLI وClaude Code كوكلاء مراجعة كود |
| الحاجة للمصادقة | يحتاج المهاجم صلاحية كتابة على المستودع (لإنشاء طلب دمج)، لكن الضحية (المراجِع) هو من يملك الصلاحيات الفعلية التي تُستغَل |
| حالة التصحيح | لا يوجد إصدار مصحَّح متاح بعد — مايكروسوفت أقرّت بالثغرة ضمن إفصاح منسَّق (Coordinated Disclosure) دون تعديل الكود أو تخصيص CVE |
| الجهة المكتشِفة | شركة Manifold Security |
المشكلة: حماية طُبِّقت في كل مكان إلا هنا
طبّقت مايكروسوفت آلية حماية تُعرف بـ"التظليل" أو “Spotlighting” — وهي تقنية تُحيط أي محتوى غير موثوق (كنص وارد من مستخدم خارجي) بمحدِّدات (Delimiters) واضحة، بحيث يستطيع نموذج الذكاء الاصطناعي التمييز بين “تعليمات من المستخدم الفعلي” و"نص خارجي يجب معاملته كبيانات فقط، لا كأوامر". طُبِّقت هذه الحماية عبر معظم أدوات خادم Azure DevOps MCP.
المشكلة: وظيفة واحدة تحديداً — وهي repo_get_pull_request_by_id المسؤولة عن جلب تفاصيل طلب الدمج — لم تُحدَّث أبداً بهذه الحماية. هذا النوع من الثغرات (خلل بتطبيق حماية شاملة على وظيفة واحدة نُسيت) شائع جداً بالأنظمة الكبيرة والمعقَّدة، ويُظهر كيف أن حماية “شبه كاملة” قد تكون بلا فائدة عملياً إذا وُجدت ثغرة واحدة تكفي للالتفاف الكامل عليها.
آلية الاستغلال: تعليقات مرئية للآلة، مخفية عن الإنسان
الحيلة التقنية هنا أنيقة وخطيرة بنفس الوقت: تعليقات HTML (<!-- تعليق -->) تُعرَض بشكل مخفي تماماً بواجهة الويب الخاصة بـAzure DevOps — أي مراجِع بشري يفتح طلب الدمج بالمتصفح لن يرى هذا التعليق إطلاقاً. لكن نفس هذا التعليق يظهر كنص عادي بالكامل عندما يُجلَب طلب الدمج عبر واجهة REST API — وهي بالضبط الطريقة التي يقرأ بها وكيل الذكاء الاصطناعي وصف طلب الدمج.
النتيجة: المهاجم يخفي تعليماته داخل تعليق HTML لا يراه أي إنسان بمراجعة عادية، بينما يقرأه الوكيل الآلي بوضوح تام ويتعامل معه كجزء من النص الذي يجب فهمه ومعالجته. كما وصف الباحثون:
“the sequence and intent, driven by text that a human never saw.” الترجمة: “التسلسل والنية [الفعلية بالأوامر المنفَّذة] كانا مدفوعين بنص لم يره أي إنسان إطلاقاً.”
سيناريو الاستغلال الكامل
- مهاجم يملك صلاحية كتابة على المستودع (Write Access) — سواء متعاون شرعي بنوايا خبيثة، أو حساب مخترَق — ينشئ طلب دمج (Pull Request) يبدو طبيعياً تماماً بمظهره الخارجي.
- داخل وصف طلب الدمج، يُخفي المهاجم حمولة (Payload) من التعليمات ضمن تعليق HTML غير مرئي.
- مراجِع بشري شرعي يطلب من وكيل الذكاء الاصطناعي الخاص به (مثلاً Copilot CLI أو Claude Code) مراجعة طلب الدمج هذا كإجراء روتيني.
- الوكيل يقرأ وصف طلب الدمج عبر REST API، فيلتقط التعليمات المخفية ويبدأ بتنفيذها — لكن بصلاحيات المراجِع البشري نفسه، لا بصلاحيات المهاجم.
- يستطيع الوكيل المُخترَق تنفيذ سلسلة كاملة من الإجراءات: تشغيل خطوط أنابيب (Pipelines) بمشاريع مختلفة، قراءة صفحات Wiki سرية، وتسريب محتواها عبر تعليقات إضافية بطلب الدمج نفسه.
نطاق التأثير الفعلي
بحسب الوصف التقني للأثر، الوصول الذي يحصل عليه الوكيل المُخترَق لا يقتصر على المثال التوضيحي (Proof of Concept) الذي استُخدم للكشف عن الثغرة:
“source code, secrets, and work items, not just the wiki page its proof of concept exfiltrated.” الترجمة: “الكود المصدري، الأسرار (Secrets)، وعناصر العمل (Work Items) — وليس فقط صفحة الـWiki التي سرّبها إثبات المفهوم.”
بمعنى آخر: إثبات المفهوم أظهر تسريب صفحة Wiki واحدة فقط كدليل على إمكانية الاستغلال، لكن النطاق الفعلي لما يستطيع المهاجم الوصول إليه أوسع بكثير — يشمل كل ما يملك المراجِع البشري صلاحية الوصول إليه فعلياً بالمنظومة.
لماذا هذه الثغرة مهمة حتى لو لم تُخصَّص لها CVE؟
عدم تخصيص رقم CVE رسمي لا يعني ضعف خطورة الثغرة — بل يعكس تحدياً أوسع بمجال أمن أنظمة الذكاء الاصطناعي حالياً: العديد من ثغرات حقن الأوامر (Prompt Injection) لا تندرج بسهولة ضمن تصنيفات CVE التقليدية المصمَّمة أصلاً لثغرات برمجية كلاسيكية (تجاوز سعة الذاكرة، حقن SQL، إلخ)، رغم أن أثرها العملي (اختراق شامل لصلاحيات مستخدم شرعي) لا يقل خطورة عن أي ثغرة RCE تقليدية.
كيف تحمي أنظمتك؟
- لا يوجد تصحيح متاح حالياً — التخفيف الوحيد الممكن هو تعديل سلوك الاستخدام: راجع أوصاف طلبات الدمج يدوياً (كنص خام عبر API، لا فقط بواجهة الويب) قبل تكليف وكيل ذكاء اصطناعي بمراجعتها آلياً.
- قيّد صلاحيات وكلاء الذكاء الاصطناعي المستخدَمة بمراجعة الكود بحيث لا تملك تلقائياً صلاحيات المراجِع البشري الكاملة — خصوصاً تشغيل خطوط الأنابيب أو قراءة موارد حساسة كصفحات Wiki سرية.
- راقب سلوك الوكيل غير المعتاد بعد مراجعة طلبات دمج من مساهمين جدد أو غير موثوقين بالكامل — أي إجراء خارج نطاق “قراءة الكود والتعليق عليه” يستحق تدقيقاً فورياً.
- افترض أن أي نص وارد من مصدر خارجي (وصف طلب دمج، تعليق، ملف يُقرأ آلياً) قد يحتوي تعليمات مخفية موجَّهة تحديداً لوكيل الذكاء الاصطناعي، لا للقارئ البشري.
ملاحظات
- الخبر الأصلي كتبته الصحفية Swati Khandelwal على The Hacker News بتاريخ 22 تموز/يوليو 2026.
- هذه الثغرة جزء من نمط متكرر بمشهد أمن الذكاء الاصطناعي هذا الأسبوع تحديداً بهذه المدونة — راجع أيضاً حملة FakeGit وتقنية AgentBaiting لاستدراج وكلاء الذكاء الاصطناعي، وثغرة ServiceNow AI Platform — جميعها تشترك بمحور واحد: استغلال ثقة الوكيل الآلي بمحتوى يبدو “بيانات عادية” بينما هو فعلياً تعليمات مموَّهة.
المصدر
المقال الأصلي: Microsoft Azure DevOps MCP Flaw Lets Hidden PR Comments Hijack AI Review Agents