قد يتسبب SSRF في خادم Azure MCP Server في تسريب رمز الهوية المُدارة الخاص به إلى عنوان URL

نشرت Microsoft في 10 مارس 2026 الثغرة CVE-2026-26118: عيب تزوير طلبات من جانب الخادم في Azure MCP Server Tools، وهي الحزمة التي تتيح لعملاء الذكاء الاصطناعي وعملاء MCP العمل على موارد Azure باللغة الطبيعية. يمكن للمهاجم الذي يستطيع التفاعل مع وكيل مدعوم بـ MCP أن يقدّم عنوان URL ضارًا بدلًا من معرّف مورد Azure عادي؛ حينها يرسل الخادم طلبًا صادرًا إلى ذلك العنوان، ووفقًا لما ذكرته Microsoft، «قد يتضمن رمز هويته المُدارة» — ليسلّم إلى المستدعي بيانات اعتماد لم يكن من المفترض أن يراها. منحت Microsoft الثغرة CVSS 8.8 وصنفتها بأنها Important، والحزمتان اللتان تحملان الإصلاح هما 1.0.2 و2.0.0-beta.17. لا تسجل النشرة أي استغلال ولا أي إفصاح علني قبل التصحيح، ولا يُسجَّل عنها أي ضرر فعلي. هذه الحادثة إحدى المدخلات في أرشيف Orca لحوادث الذكاء الاصطناعي، الذي يحتفظ بالسجل الكامل مع مصادره المذكورة ودرجة الخطورة وتقييم الثقة.

ما يقوله التحذير فعلياً

سجل Microsoft Security Response Center مقتضب، ويكاد كل تفصيل منشور عن هذا العيب ينحدر منه أو من إجابات Microsoft على حفنة من أسئلة المتابعة. الوصف كاملًا: «يسمح تزوير الطلب من جانب الخادم (SSRF) في Azure MCP Server لمهاجم مُصرَّح له برفع الصلاحيات عبر الشبكة». حجز سجل CVE المعرّف في 11 فبراير 2026 وأتاحه للعموم في 10 مارس عند الساعة 14:00 UTC؛ وتحمل كلٌّ من ملاحظة إصدار Microsoft ومدخل NVD ذلك اليوم. حلّل NVD السجل ونشره عند الساعة 18:18 UTC بعد ظهر اليوم نفسه. أما الإشعار التنظيمي الوحيد الذي عُثر عليه لهذا المقال فقد جاء من المغرب: أدرجت وحدة maCERT التابعة لـ DGSSI المرجع CVE-2026-26118 في نشرة مؤرخة 11 مارس 2026، وسردت Azure MCP Server Tools ضمن المنتجات المتأثرة بمستوى مخاطر خاص بها هو Important، من دون درجة منفصلة ومع إشارة رجوع إلى إصدار Microsoft.

يُربط الضعف بـ CWE-918، تزوير الطلب من جانب الخادم، وتصنيف التأثير هو رفع مستوى الصلاحيات. درجة Microsoft الأساسية هي 8.8 وفق المتجه CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H، مع درجة زمنية قدرها 7.7 على E:U/RL:O/RC:C — ويعني المكوّن E:U أنه لم تكن هناك شيفرة استغلال معروفة لدى Microsoft عند تعيين الدرجة، ويعني RL:O توفر إصلاح رسمي. تحمل NVD الدرجة الأساسية نفسها وتضعها في فئة High؛ ويسميها مقياس Microsoft ثلاثي الخطوات Important.

هناك حقلان لا يقلان أهمية عن الدرجة. يقول سجل Microsoft تم استغلاله: لا ومُفصح عنه علنًا: لا. ويتفق سجل قرار SSVC الخاص بـ CISA بشأن مدخل NVD، المؤرخ 5 مارس 2026، على الاستغلال — لا شيء — بينما يقيّم التأثير التقني بأنه كلي، وقابلية الأتمتة بأنها لا. وقد وضع نموذج FIRST EPSS احتمال الاستغلال خلال الثلاثين يومًا القادمة عند نحو 1.0%، عند المئين 62.8، في سحب مؤرخ 3 نوفمبر 2026. هذا عيب تم اكتشافه وإصلاحه، وليس عيبًا معروفًا أنه قد استُخدم.

كيف يتحوّل معرّف المورد إلى طلب صادر

Azure MCP Server هو تنفيذ Microsoft لبروتوكول Model Context Protocol، الواجهة التي يستخدمها وكلاء الذكاء الاصطناعي لاستدعاء الأدوات. تأخذ أدواته المعلمات التي يوفّرها الوكيل — اسم حساب تخزين، ومعرّف اشتراك، واسم قاعدة بيانات — وتحوّلها إلى استدعاءات موجّهة إلى مستويَي الإدارة والبيانات في Azure. وتصف وثائق Microsoft الخادم بأنه يصادق عبر Entra ID باستخدام «بيانات اعتماد مستخدم Azure أو الهوية المُدارة»، مع تقييد الوصول وفق التحكم في الوصول المستند إلى الأدوار في Azure.

يكمن العيب في النقطة التي يُقبل فيها معامل من المفترض أن يحدد اسم مورد Azure على أنه عنوان URL بدلاً من ذلك. شرح Microsoft نفسه: يمكن للمهاجم «استغلال هذه المشكلة عبر إرسال مدخلات مصممة خصيصاً إلى أداة Azure Model Context Protocol (MCP) Server تقبل معاملات يقدمها المستخدم. وإذا كان بإمكان المهاجم التفاعل مع الوكيل المدعوم بـ MCP، فيمكنه تقديم عنوان URL ضار بدلاً من معرّف مورد Azure عادي». ثم يرسل الخادم الطلب إلى المكان الذي أُخبر به، بدلاً من المكان الذي كانت الأداة تقصده.

الجزء الذي يحوّل الأمر المزعج إلى تصعيد امتيازات هو ما يُحمَل معه. تقول Microsoft إن الطلب الصادر "قد يتضمن رمز هويته المُدارة"، مما يتيح للمهاجم التقاط ذلك الرمز "دون الحاجة إلى وصول إداري". ورمز الهوية المُدارة هو بيانات اعتماد حاملة: فمن يحمله يمكنه تقديمه إلى خدمات Azure المخوَّل بها ذلك الهوية، إلى أن تنتهي صلاحيته. أما النصف المخفِّف من الفقرة نفسها فليس أقل أهمية — إذ يحصل المهاجم على "الأذونات المرتبطة بالهوية المُدارة لخادم MCP"، وبكلمات Microsoft، "لا يحصل على أذونات أوسع على مستوى المستأجر أو أذونات مسؤول؛ بل فقط تلك المرتبطة بالهوية المُدارة المخترقة". ونطاق الضرر هو كل ما منحه أحدهم لتلك الهوية، وهو عملياً غالباً أكثر مما احتاجته أداة واحدة.

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

الإصلاح، والحزم التي حملته

لم يكن هذا تحديث Windows. تُوزَّع أدوات Azure MCP Server Tools كحزمة NuGet لـ .NET، وحزمة npm، وحزمة Python على PyPI، ويكمن الإصلاح في رفع الإصدار في أيٍّ من هذه الحزم يستخدمه النشر. تسرد نشرة Microsoft النطاقات المتأثرة على النحو التالي: من 1.0.0 حتى 1.0.2 باستثناءها، ومن 2.0.0-beta.1 حتى 2.0.0-beta.17 باستثناءها، عبر توزيعات NuGet وnpm وPyPI.

تُظهر تواريخ سجل npm أن عمليات البناء المُصلحة كانت موجودة على السجل قبل النشرة الأمنية. الإصدار 1.0.2 من @azure/mcp نُشر في 6 مارس 2026، أي قبل أربعة أيام من إعلان CVE للعموم؛ ونُشر 2.0.0-beta.17 في 6 فبراير 2026، أي قبل خمسة أيام من حجز Microsoft لمعرّف CVE وقبل شهر من ظهور النشرة الأمنية. ومهما كان التسلسل داخل Microsoft، فإن الكود المُرقّع لم يُكتب استجابةً ليوم النشر. يتفق NVD وقاعدة بيانات النشرات الأمنية لدى GitHub على هذين الحدين الأعلى. ويختلفان قليلًا عند الحد الأدنى لنطاق PyPI — إذ يقول NVD إنه 2.0.0-beta.1، بينما تقول نشرة GitHub الأمنية إنه 2.0.0b14 — وهو تباين ظلّ السجلان يحملانه منذ النشر، ولا يؤثر إلا في المدى الزمني الذي يحتاج نشر Python إلى الرجوع إليه.

تم تنقيح الاستشارة نفسها في 20 مارس 2026، أي بعد عشرة أيام من نشرها، بملاحظة مفادها أن Microsoft «أضافت منتجات إلى جدول تحديثات الأمان توثّق طرق التغليف المختلفة المستخدمة لتسليم Azure MCP Server Tools». وبعبارة أخرى، فقد سمّت النسخة الأولى من الاستشارة المنتج لكنها لم تذكر كل قناة جرى توزيعه عبرها، وهو أمر مهم عندما يكون العلاج هو «ترقية الحزمة» بدلاً من «تثبيت هذا KB».

ما الذي لم يتم إثباته؟

من وجده.لا يذكر كلٌّ من تنبيه Microsoft وسجل CVE.org اسم المُبلِّغ؛ وحقل الاعتمادات في CVE فارغ. وهذا ليس دليلًا على أنه لم يُمنح أحدٌ اعتمادًا على نحو خاص، بل فقط على أنه لا يوجد اعتماد علني.

أي استغلال. لا تسجّل Microsoft أي حالة، ويتوافق تقييم SSVC الصادر عن CISA مع ذلك، ولا يصف أي مصدر تمت مراجعته لهذا المقال هويةً مخترقة في البرية. حقل الضرر الحقيقي في السجل قيمته "false"، بما يتسق مع ذلك. انخفاض EPSS توقّع وليس نتيجة، وغياب حادثة مُبلّغ عنها ليس دليلاً على عدم وقوع أي منها.

ما إذا كان هناك استغلال عام موجود. هنا تتباين التغطية الثانوية. يشير منشور على مدونة Blueinfy بتاريخ مارس 2026 إلى وجود «استغلالات إثبات مفهوم علنية، مثل تلك الموجودة على GitHub» ويحذر من «تسليح سريع»، لكنه لا يقدم رابطًا ولا حمولة ولا شرحًا خطوة بخطوة، ولا يثبت وجود الثغرة. وتقول سجلات Microsoft إن الثغرة لم تُكشف علنًا قبل التصحيح. وأعاد البحث في مستودعات GitHub عن معرّف CVE في 4 نوفمبر 2026 مستودعًا واحدًا — وهو مختبر كشف Microsoft Sentinel نُشر في 17 مارس 2026، وليس استغلالًا — وتذكر صفحة الثغرة الخاصة بـ Mallory أنه تم فحص استغلالين محتملين ورفضهما. إن الادعاء بوجود شيفرة استغلال عامة فعّالة هو، بحسب الأدلة المتاحة، ادعاء لا أساس له؛ كما أن الادعاء بأن أحدًا لم يحاول هو أيضًا غير مُثبت.

التأطير.تُعيد صفحة على PolicyLayer، وهو موقع ملخصات حوادث تابع لجهة بائعة، صياغة CVE-2026-26118 بوصفه سلسلة تنفيذ تعليمات برمجية عن بُعد دون مصادقة تنتهي بالاستيلاء الكامل على المستأجر، مع نسبة الفضل إلى باحث مذكور بالاسم وإلى عرض توضيحي في RSAC 2026. أما المصادر التي تستشهد بها تلك الصفحة نفسها فتحمل عناوين SSRF، ولا تتوافق تواريخها مع الجدول الزمني لـ CVE، ولا يصف أي من تنبيه Microsoft أو تقرير SecurityWeek المؤرخ 10 مارس تنفيذ التعليمات البرمجية. وتتعامل هذه المقالة مع رواية SSRF والرمز المميز باعتبارها الرواية المعتمدة، ولا تكرر تأطير RCE.

لماذا الرمز المميز، وليس الطلب، هو الاكتشاف

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

توضح وثائق Microsoft أين يتركز هذا الخطر. فهي تصف الخادم المحلي بأنه "مخصص بدقة للاستخدام من قبل المطورين داخل مؤسستك"، بينما تنشر بشكل منفصل أدلة نشر للخوادم البعيدة المستضافة ذاتيًا في Microsoft Foundry وCopilot Studio — وهي التكوينات التي تكون فيها الهوية المُدارة، لا تسجيل دخول المطور نفسه، هي الاعتماد المعتاد المستخدم. ومسار سرقة الرموز المميزة في التنبيه يتعلق تحديدًا بالهوية المُدارة. وهو لا يقول إن كل عملية تثبيت كانت مكشوفة، ولا يقول كم كان عددها.

الدرس العام هو الدرس الذي بات معيار OWASP للتحقق من أمن الذكاء الاصطناعي يستخدم هذه الحالة لتعليمه. ويورد فصل التنسيق في AISVS الثغرة CVE-2026-26118 ضمن أمثلته المشروحة، ويخلص إلى أن "معاملات أدوات MCP يجب أن تُعامَل على أنها خاضعة لسيطرة المهاجم، وأن الطلبات الصادرة من خوادم MCP يجب أن تمر عبر سياسات الخروج والأصل نفسها التي يُتوقع تطبيقها على أي إدخال/إخراج آخر يحرّكه وكيل". وهذه توصية ضوابط، وليست نتيجةً تخص هذه الحادثة، لكنها الإجابة الأكثر ملموسية التي نشرها أي طرف على سؤال ما الذي ينبغي تغييره.

ما الذي تغيّر بعد

ثلاثة أمور، ولا شيء منها دراماتيكي. شحنت Microsoft حزمًا ثابتة في النظم البيئية الثلاثة كلها، وعدّلت التنبيه ليسمّيها. استوعبها نظام استخبارات الثغرات بهدوء: درجة EPSS منخفضة، وسجل NVD آخر تعديل له في 17 يونيو 2026. وتبنّاها مجتمع المعايير كحالة تعليمية، وهذا شكل من الاستجابة أبطأ وأكثر دوامًا من رقعة.

بالنسبة إلى أي شخص لا يزال يشغّل إصدارًا متأثرًا، فإن المعالجة لم تتغير وليست مبهرة: انتقل إلى 1.0.2 أو أحدث على مسار الإصدارات المستقرة، أو إلى 2.0.0-beta.17 أو أحدث على مسار المعاينة، في كل مدير حزم يتعامل معه النشر. علاوة على ذلك، فإن منطق التنبيه الأمني نفسه يستلزم ثلاثة ضوابط — تقييد ما يمكن للخادم الوصول إليه صادرًا، ومنح الهوية المُدارة فقط الأدوار التي تحتاجها أدواتها فعلاً، والتعامل مع أي معامل أداة يمكن أن يصبح عنوان URL باعتباره مدخلات عدائية. لا يُشترط أي منها للنجاة من CVE-2026-26118. وسيقلل كل منها من قيمة الضابط التالي بالنسبة إلى المهاجم.

كيف يصنّف الأرشيف هذا

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

يأتي أحد الحقول مختلفًا عن التقييم المنشور. تُسجَّل شدة الأرشيف بوصفها متوسطة، على مقياسه الخاص؛ أما الرقم الذي تنشره كل من Microsoft وNVD فهو 8.8، وهو الرقم الذي تسميه Microsoft «Important» وتصنّفه NVD ضمن «High». ويستهل ملخص السجل بذلك الرقم 8.8، والتباين هنا اختلاف في التصنيف الفئوي لا في الوقائع.

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