ثغرة أزور ديف أوبس MCP تسمح بخطف وكلاء المراجعة

ثغرة أزور ديف أوبس MCP تكشف كيف يمكن لتعليق HTML مخفي داخل طلب سحب واحد أن يوجّه وكيل ذكاء اصطناعي لمراجعة الشفرة نحو مشاريع أخرى وتسريب ما يعثر عليه بصمت، وهي مشكلة تمس بيئات التطوير المؤتمتة التي تعتمد على صلاحيات المراجع نفسه.

تكمن المشكلة في الخادم الرسمي Azure DevOps MCP من مايكروسوفت، إذ إن إحدى أدواته تعيد وصف طلب السحب كما هو دون طبقة حماية ضد حقن الأوامر غير المباشر، رغم أن الشركة طبقت هذا النوع من الحماية على أدوات أخرى داخل الخادم نفسه.

هذا الخلل يجعل أي نص يكتبه طرف ثالث داخل محتوى يبدو عادياً أمام المراجع البشري يتحول إلى تعليمات قابلة للتنفيذ من قبل الوكيل الذكي. وهنا لا يتحدث المهاجم مباشرة مع الوكيل، بل يزرع أوامره في مكان يعرف أن الوكيل سيقرأه لاحقاً أثناء تنفيذ مهمة مشروعة.

ما هي ثغرة أزور ديف أوبس MCP وكيف تبدأ؟

السيناريو يبدأ من عنصر بسيط جداً: تعليق HTML غير مرئي داخل وصف Pull Request في Azure DevOps. واجهة الويب تعرض الوصف للمراجع كأنه طبيعي تماماً، لأن التعليقات المكتوبة بصيغة <!-- ... --> لا تظهر للمستخدم أثناء التصفح.

لكن على الجانب الآخر، تعيد واجهة REST API النص كاملاً كما كُتب حرفياً، من دون حذف هذا التعليق المخفي. بعد ذلك، يسلّم خادم Azure DevOps MCP هذا النص نفسه إلى وكيل الذكاء الاصطناعي، ليصل إليه المحتوى الخفي كجزء من البيانات التي يفترض أنها خاصة بالمراجعة فقط.

الفارق بين ما يراه الإنسان وما يتلقاه النموذج هو جوهر آلية الهجوم. المراجع يعتقد أنه يطلب من الوكيل فحص التغييرات البرمجية، بينما يقرأ الوكيل، إضافة إلى الوصف العادي، تعليمات مخفية قد تعيد تعريف المهمة بالكامل أو تبدل أولوياتها أو تدفعها لاستخدام أدوات أخرى متاحة له.

هذا النوع من الاستغلال يندرج ضمن هجمات "النائب المربك" أو Confused Deputy، حيث يستعير المهاجم صلاحيات شخص آخر أو خدمة أخرى لتحقيق هدف لا يمكنه تنفيذه بنفسه. في هذه الحالة، لا يربح المهاجم صلاحيات مباشرة على النظام، لكنه يستفيد من صلاحيات المراجع التي يحملها الوكيل الذكي.

بحسب طبيعة Azure DevOps MCP، فالخادم يتيح للوكلاء قراءة واستخدام عناصر متعددة داخل بيئة Azure DevOps نيابة عن المستخدم، مثل:

• طلبات السحب Pull Requests
• خطوط البناء والنشر Pipelines
• صفحات الويكي Wiki
• عناصر العمل Work Items
• المستودعات البرمجية والمحتوى المرتبط بها

هنا تظهر الخطورة الحقيقية. إذا كان المراجع يملك صلاحيات أوسع من صلاحيات الشخص الذي فتح طلب السحب، فإن الوكيل يستطيع الوصول إلى نطاق أكبر بكثير مما يستطيع المهاجم الوصول إليه بنفسه. وبذلك يتحول نص مخفي داخل وصف PR إلى قناة غير مباشرة لتنفيذ عمليات عابرة للمشاريع.

الأمر لا يقف عند قراءة صفحة ويكي واحدة فقط. التأثير المحتمل، كما أوضحت اختبارات الباحثين، يشمل الشفرة المصدرية والأسرار المخزنة وعناصر العمل ومحتويات أخرى حساسة قد توجد في مشاريع أو مساحات عمل لا يملك المهاجم إذناً لفتحها مباشرة.

وهذه النقطة مهمة جداً لفهم سبب اعتبار المشكلة تصعيداً فعلياً للصلاحيات. في بيئات التطوير المؤسسية، يكون المراجع غالباً أكثر خبرة أو أعلى مرتبة وظيفياً من صاحب طلب السحب، ولذلك يمتلك وصولاً أوسع إلى مستودعات أو مشاريع جانبية أو ويكيات داخلية أو خطوط تنفيذ خاصة بالفرق المختلفة.

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

كيف يعمل فرق الرؤية بين الإنسان والنموذج؟

واجهة المستخدم في Azure DevOps تخفي التعليق، لذلك لا يلاحظ المراجع أي إشارة تدل على وجود حمولة خبيثة داخل الوصف. أما الواجهة البرمجية فتتعامل مع النص الخام، فتسلم كل ما يحتويه بلا تمييز بين وصف بريء وتعليمات مزروعة.

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

لماذا فشل مسار طلب السحب في الحماية؟

ما يرفع هذه الحادثة فوق مستوى التحذيرات العامة بشأن حقن الأوامر في النماذج هو أن مايكروسوفت كانت قد أضافت بالفعل طبقة دفاعية من هذا النوع داخل الخادم. أي أن المسألة ليست غياب فهم للمشكلة، بل عدم تطبيق الحماية على كل المسارات التي تحتاجها.

عند مراجعة الشفرة المصدرية للخادم، ظهر أن بعض الأدوات تستخدم أسلوباً يعرف باسم spotlighting. هذا الأسلوب وارد ضمن إرشادات مايكروسوفت نفسها للتعامل مع الحقن غير المباشر، وفكرته الأساسية هي تطويق المحتوى غير الموثوق بعلامات واضحة حتى يتمكن النموذج من تمييزه كبيانات يجب الحذر منها، لا كأوامر يجب تنفيذها.

هذه الحماية أضيفت في مسارات مثل أدوات قراءة صفحات الويكي وسجلات البناء، حيث تمر الاستجابة عبر دالة مشتركة تحمل اسم createExternalContentResponse. وظيفة هذه الدالة هي تغليف المحتوى الخارجي بطريقة تقلل احتمال أن يخلط الوكيل بين البيانات والتعليمات.

لكن الأداة المسؤولة عن إعادة تفاصيل طلب السحب، وهي repo_get_pull_request_by_id، لا تستدعي هذه الدالة. وبدلاً من ذلك، تعيد الوصف مباشرة بصورته الخام، من دون طبقة التمييز أو الفصل التي تطبق في أدوات أخرى.

هذا الغياب الصغير ظاهرياً هو ما فتح سطح الهجوم بالكامل. فالوصف هو تحديداً المكان الذي يستطيع المهاجم الكتابة فيه، وإذا كان هذا المسار وحده غير محمي، فإن كل بقية الدفاعات تفقد جزءاً كبيراً من قيمتها العملية.

المشكلة هنا معمارية بقدر ما هي برمجية. عندما تكون الحماية مرتبطة بكل مسار استجابة على حدة، فإن أي وظيفة تُنسى أو أي أداة جديدة تضاف من دون نفس الالتزام تتحول إلى ثغرة صامتة يصعب اكتشافها من خارج النظام.

هذا يفسر لماذا تبدو مثل هذه الفجوات شبه غير مرئية خلال الاستخدام العادي. المستخدم يرى أن بعض الأدوات محمية، وقد يفترض أن الحماية عامة على مستوى الخادم كله، لكن التنفيذ الفعلي يعتمد على أن يتذكر المطورون تغليف كل نقطة تعيد محتوى غير موثوق.

وفقاً لما رصدته تيكبامين في تحليل هذا النمط، فإن الاتساع المستمر لأسطح التكامل الخاصة بوكلاء الذكاء الاصطناعي يجعل التدقيق اليدوي في كل دالة مساراً ضعيفاً على المدى الطويل. كلما زاد عدد الأدوات ونقاط الإدخال، زادت احتمالات أن يمر مسار واحد من دون حماية كافية.

لماذا لا تكفي الحماية الجزئية؟

لأن المهاجم لا يحتاج إلى اختراق كل الأدوات. يكفيه أن يجد أداة واحدة تعيد محتوى غير موثوق على نحو خام، ثم يبني عليها سلسلة كاملة من الأفعال المسموح بها. بهذا المعنى، فإن قوة المنظومة الأمنية لا تُقاس بأفضل أجزائها، بل بأضعف نقطة تغفل التمييز بين النص والتعليمات.

كما أن تقنيات مثل spotlighting ترفع كلفة الهجوم لكنها لا تغلق الباب نهائياً. فإذا كان النموذج أو الوكيل أو سلسلة الأدوات تسمح بتفسيرات مرنة أو آلية موافقات ضعيفة، فقد يظل هناك هامش للمناورة حتى مع وجود بعض الحواجز الشكلية.

كيف نُفذت سلسلة الاستغلال خطوة بخطوة؟

في تجربة الإثبات العملي، استُخدم بناء محلي للإصدار v2.7.0 من الخادم. قام مساهم داخل مشروع معين بفتح طلب سحب يبدو عادياً في ظاهره، لكنه يحتوي داخل الوصف على تعليق HTML مخفي يتضمن الحمولة أو التعليمات المطلوب تمريرها إلى الوكيل.

بمجرد أن يبدأ المراجع تشغيل وكيل الذكاء الاصطناعي لمراجعة الطلب، يبدأ الوكيل بقراءة الوصف كما وصله من الخادم. هنا تنتقل التعليمات المخفية من كونها مجرد نص غير مرئي إلى أوامر مؤثرة على تسلسل العمل الذي يتبعه الوكيل.

سلسلة التنفيذ التي تم توثيقها لم تكن عشوائية، بل سارت وفق خطوات متتابعة. الوكيل فعل ما يلي:

• شغّل Pipeline في مشروع مختلف عن المشروع الأصلي
• قرأ صفحة ويكي سرية لا يستطيع المهاجم فتحها بنفسه
• أعاد نشر محتوى تلك الصفحة على شكل تعليق داخل طلب السحب
• ترك البيانات المسربة في مكان يمكن للمهاجم الاطلاع عليه لاحقاً

اللافت هنا أن كل استدعاء في هذه السلسلة كان، من حيث المبدأ، ضمن الأفعال المسموح بها للوكيل. لم يكن هناك تجاوز مباشر للصلاحيات على مستوى النظام، بل كان التجاوز في النية والترتيب والغرض النهائي الذي خُدع الوكيل لتنفيذه.

لهذا السبب اعتبر الباحثون أن المشكلة ليست في استدعاء أداة مفردة بحد ذاتها، وإنما في "تسلسل التنفيذ والنية" الناتجين عن نص لم يره الإنسان أبداً. هذه العبارة تختصر جوهر المخاطر التي تضيفها الوكالة البرمجية عندما ترتبط بصلاحيات حقيقية وإمكانية تنفيذ إجراءات عبر عدة نطاقات.

كما أن التجربة لم تُربط بوكيل واحد بعينه. فقد أمكن إعادة إنتاج السلوك باستخدام Copilot CLI وكذلك Claude Code، ما يعني أن أصل الخطر ليس اسم الوكيل، بل طبيعة تكامله مع الخادم ودرجة الثقة التي يمنحها للمحتوى القادم من أدوات خارجية.

في المقابل، هذا النوع من الهجوم يحتاج إلى شروط مسبقة حتى ينجح. ومن أبرزها:

• أن يتمكن المهاجم من كتابة نص داخل وصف Pull Request
• أن يكون هناك سير عمل يمرر هذا الوصف إلى وكيل ذكاء اصطناعي
• أن تكون صلاحيات المراجع أوسع من صلاحيات المهاجم
• أن يكون الوكيل قادراً على تشغيل الأدوات من دون طلب تأكيد عند كل خطوة

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

وأكد الاختبار أن وضعية الموافقة التلقائية أو auto-approve من دون مطالبات لكل أداة كانت عاملاً حاسماً. لو وُجدت مطالبات لكل إجراء، فقد يلاحظ المراجع مثلاً أن الوكيل يحاول تشغيل Pipeline في مشروع آخر أو قراءة صفحة ويكي بعيدة عن سياق المراجعة، وربما يوقف العملية قبل اكتمالها.

لكن حين يجتمع رمز وصول واسع النطاق مع موافقات صامتة، تتركز المخاطر في أعلى مستوياتها. عندها لا تكون المشكلة مجرد قراءة نص خبيث، بل قدرة هذا النص على تحريك منظومة كاملة من الأدوات عبر الصلاحيات المتاحة.

ماذا عن المراجعات المؤتمتة بالكامل؟

التجربة الافتراضية هنا تفترض أن إنساناً بدأ المراجعة أولاً، لكن الاتجاه الذي تسير إليه الفرق التقنية اليوم أكثر طموحاً من ذلك. فالكثير من المؤسسات يختبر بالفعل وكلاء يطلقون المراجعات أو الملخصات أو أعمال الفرز تلقائياً عند وقوع حدث معين، مثل فتح PR جديد أو تعديل فرع أو اكتمال بناء.

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

النمط نفسه ليس جديداً على مستوى الفكرة العامة. فقد ظهرت في وقت سابق حالات مشابهة استهدفت خوادم MCP أخرى، حيث استُخدمت محتويات عامة أو شبه عامة لدفع وكيل يملك وصولاً خاصاً إلى قراءة مستودعات خاصة ثم تسريب ما يجد. ومع توسع استخدام الوكلاء داخل GitHub وAzure DevOps وسواهما، أصبح هذا الصنف من الهجمات أكثر قابلية للتكرار.

وتندرج هذه الحالة ضمن ما يُعرف أحياناً بـ"الثلاثية القاتلة" للوكلاء: الوصول إلى بيانات خاصة، والتعرض لمحتوى غير موثوق، وامتلاك قناة لإخراج البيانات. إذا اجتمعت العناصر الثلاثة في وكيل واحد، فإن قطعة نص واحدة قد تكفي لتحويله من مساعد منتج إلى وسيلة تسريب فعالة.

• العنصر الأول: صلاحية على بيانات أو مشاريع خاصة
• العنصر الثاني: قراءة محتوى يمكن للآخرين كتابته أو التأثير فيه
• العنصر الثالث: قدرة على التعليق أو الإرسال أو النشر أو التعديل في مكان ما

بمجرد اكتمال هذه الدائرة، يصبح السؤال ليس هل يمكن نظرياً إساءة الاستخدام، بل متى وأين ستظهر الفجوة التالية التي تسمح بتحويل النص إلى تصرفات عملية.

كيف تقلل المؤسسات خطر ثغرة أزور ديف أوبس MCP؟

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

كما أشارت الشركة إلى أن الاستغلال يتطلب من المهاجم امتلاك وصول كتابي إلى مشروع ما، وأن يقوم مستخدم ثانٍ بتشغيل أداة ذكاء اصطناعي فوق هذا المحتوى. التوصية الرسمية كانت الحد من وصول المشاريع ومراجعة التغييرات المقترحة قبل مطالبة أداة الذكاء الاصطناعي بالتصرف حيالها.

غير أن هذه النصيحة تصطدم بعقبة جوهرية: الحمولة هنا غير مرئية داخل الواجهة التي يراجعها الإنسان. أي أن مطالبة البشر بمراجعة المحتوى لا تكفي وحدها إذا كانت واجهة المراجعة نفسها لا تعرض كل ما سيقرأه الوكيل.

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

• استخدم رموز وصول ذات صلاحيات محدودة لا تتجاوز المشروع الجاري مراجعته
• احصر الوكيل في نطاق المشروع المطلوب بدلاً من منحه وصولاً واسعاً متعدد المشاريع
• حمّل فقط مجالات MCP التي تتطلبها المهمة فعلاً
• استبعد قدرات مثل تشغيل Pipelines أو قراءة Wiki أو نشر التعليقات من مجموعة أدوات مراجعة الكود إن لم تكن ضرورية

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

كذلك يُنصح بإبقاء الأفعال الحساسة خارج تدفق مراجعة الشفرة كلما أمكن. مراجعة الكود لا تحتاج عادة إلى تشغيل خطوط تنفيذ في مشروع آخر أو قراءة صفحات ويكي سرية أو نشر تعليقات آلية من دون تدقيق. كل أداة إضافية في هذا المسار تزيد مساحة الهجوم من دون عائد ضروري.

ومن الإجراءات المهمة أيضاً فرض مطالبات تأكيد على الأفعال الحساسة. صحيح أن هذا قد يقلل السلاسة، لكنه يضيف نقطة فحص بشرية يمكنها كشف السلوك الغريب، خصوصاً عندما يحاول الوكيل تنفيذ شيء لا ينسجم مع مهمة "راجع هذا PR".

كيف تكتشف ما إذا كان الهجوم قد وقع بالفعل؟

التحقق ينبغي أن يبدأ من سجلات الوكيل أو traces الخاصة بالأدوات. إذا ظهر أثناء مراجعة طلب سحب أن الوكيل شغّل Pipeline في مشروع آخر، أو قرأ صفحات Wiki غير مرتبطة، أو نشر تعليقات غير متوقعة، فهذه إشارات قوية إلى احتمال وجود استغلال مبني على تعليمات مزروعة.

من المفيد أيضاً فحص أوصاف طلبات السحب المفتوحة بحثاً عن تعليقات HTML مخفية. صحيح أن المراجع البشري لا يراها في الواجهة العادية، لكن تحليل النص الخام عبر API أو أدوات فحص داخلية يمكن أن يكشف وجود تعليمات مطمورة بين الوصف الشرعي.

كما ترى تيكبامين، لا يجب التعامل مع "المراجعة البشرية" كعنصر تحكم كافٍ إذا كان الإنسان يرى نسخة مختلفة مما يراه الوكيل. الضبط الحقيقي يجب أن يحصل عند مستوى نقل البيانات، وفصل المحتوى غير الموثوق، وتضييق الصلاحيات، ومراقبة الأدوات التي يمكنها إخراج البيانات من البيئة.

حتى مع اعتماد تقنيات مثل spotlighting، فإن حقن الأوامر غير المباشر لا يختفي تماماً. هذه التقنيات ترفع العتبة، لكنها لا تلغي الحاجة إلى تصميم أمني يعتبر النص القادم من المستخدمين أو المساهمين بيانات عدائية محتملة، خصوصاً عندما يكون الوكيل قادراً على اتخاذ أفعال فعلية وليس مجرد تقديم اقتراحات.

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