[ مقال تقني ]•أمن النماذج والوكلاء•

٢٨ أغسطس ٢٠٢٦

•٧ دقائق قراءة

ثلاث ثغرات وسبب جذري واحد: أغسطس 2026 يكشف حدود التفويض في الوكلاء

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

لكنها تشترك في سبب جذري واحد: النظام منح الوكيل صلاحية أوسع من صلاحية الطلب الذي استدعاه.

وهذا هو صنف الثغرات الجدير بالفهم، لأنه لا يُعالَج بتحسين صياغة الموجّهات.

ما الذي حدث؟

حدثا إفصاح يفصل بينهما ثمانية أيام.

11 أغسطس — تحديثات مايكروسوفت الشهرية (Patch Tuesday). إصدار ضخم: أحصى فريق Cisco Talos عدد 421 ثغرة منها 62 حرجة، بينما أورد تحليل CrowdStrike الرقم 415. واحدة فقط كانت مستغَلة فعليًا في البرية — CVE-2026-68820، وهي ثغرة تصعيد صلاحيات في مشغّل Windows Ancillary Function Driver الخاص بـ WinSock بدرجة CVSS 7.0. لكن أعلى البنود خطورة كانت في خدمات الوكلاء.

20 أغسطس — دفعة تنبيهات Spring من Broadcom. تتبّعت Sonatype عدد 91 ثغرة عبر إطار Spring والمشاريع المرتبطة به، شملت Spring Security وSpring Cloud Config وSpring AI وSpring Data REST وSpring Integration وReactor Core وReactor Netty وSpring AMQP وSpring Batch. وحتى لحظة النشر، أفادت Sonatype بتأثر 148,608 مكوّنًا برمجيًا عبر سلسلة التوريد.

ثلاث من تلك الثغرات تصف الإخفاق ذاته.

الإخفاقات الثلاثة

CVE-2026-62830 — خدمة Azure SRE Agent (بدرجة 9.9)

خدمة Azure SRE Agent هي خدمة ذكاء اصطناعي تراقب البنية التحتية المستضافة على Azure وتُشخّصها وتعالج أعطالها ذاتيًا. ووصف مايكروسوفت للثغرة: «تفويض مفقود قد يسمح لمهاجم مُصرَّح له بتصعيد صلاحياته عبر الشبكة.»

ما يجعلها بدرجة 9.9 هو متجه الهجوم: تفويض مفقود (CWE-862)، عبر الشبكة، دون أي تفاعل من المستخدم، وبتعقيد هجوم منخفض، والأهم — النطاق: مُتغيّر (Scope: Changed)، مع أثر يطال السرية والسلامة والتوافرية.

و«النطاق المتغيّر» هو جوهر القصة كلها. فهو يعني أن الثغرة تتيح للمهاجم تجاوز حدود أمان الوكيل والوصول إلى موارد خارجه. ونطاق تأثير وكيل SRE تحدده هويته المُدارة (Managed Identity): كتب التشغيل (Runbooks)، وبيانات القياس عن بُعد، وأدوات إدارة الحوادث، وكل مورد على Azure تستطيع تلك الهوية لمسه. الوكيل ليس الهدف؛ الوكيل هو الطريق.

وقد طبّقت مايكروسوفت إصلاحًا من جانب الخدمة — دون حاجة إلى أي ترقيع من العميل.

CVE-2026-59118 — خدمة Microsoft Copilot Cowork (بدرجة 9.3)

«تفويض غير سليم قد يسمح لمهاجم غير مُصرَّح له بتصعيد صلاحياته عبر الشبكة.» التصنيف هنا CWE-285، عبر الشبكة، مع نطاق مُتغيّر، وأثر يطال السرية والسلامة. وخلافًا لثغرة SRE Agent، يُشترط تفاعل من المستخدم — وهو ما أبقى الدرجة عند 9.3 بدل أن ترتفع أكثر.

خطورتها نابعة من اتساع وصولها. فخدمة Copilot Cowork تعمل عبر محتوى Microsoft 365 بأكمله، ما يجعل أي خلل تفويض فيها مسارًا مباشرًا نحو مستندات المؤسسة. وقد عولجت أيضًا من جانب الخدمة دون إجراء مطلوب من العميل.

وفي الإصدار نفسه ظهرت ثغرتان أخريان قريبتان من عالم الوكلاء: CVE-2026-50516 في خدمة Azure Kubernetes (بدرجة 9.4، مصادقة مفقودة لوظيفة حرجة)، وCVE-2026-70335 التي تطال GitHub Copilot وVisual Studio Code.

CVE-2026-59318 — إطار Spring AI (بدرجة 6.5، متوسطة)

أدنى درجة في القائمة هي الأكثر إفادة. وعنوانها الرسمي:

الرجوع الاحتياطي إلى المُحلّل العام في DefaultToolCallingManager يسمح بإرسال أدوات غير مُعلنة عبر حقن الموجّهات

فتحت ظروف معينة، قد يؤدي هجوم حقن موجّهات إلى دفع Spring AI لاستدعاء أداة لم تُتَح للطلب الحالي أصلًا — متجاوزًا حدود الطلب ومؤديًا إلى تصعيد محتمل للصلاحيات.

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

القيد كان موجودًا. لكنه ببساطة لم يُفرَض عند لحظة الإرسال.

لماذا يهم هذا؟

يُصاغ حقن الموجّهات عادةً بوصفه مشكلة محاذاة في النموذج: النموذج انخدع. وهذه الصياغة خاطئة هنا، وخطؤها هو بيت القصيد.

ففي الحالات الثلاث جميعًا، يقع الإخفاق أسفل النموذج لا داخله:

Azure SRE Agent — فحص التفويض غائب تمامًا
Copilot Cowork — فحص التفويض موجود لكنه غير سليم
Spring AI — القيد الخاص بالطلب تجاوزه رجوعٌ احتياطي عام

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

وهذا أيضًا يفسّر ترتيب درجات CVSS. فثغرة «متوسطة» بدرجة 6.5 داخل إطار عمل تعتمده آلاف التطبيقات قد تكون أثقل أثرًا في المجموع من ثغرة 9.9 في خدمة مُدارة يتولى مزوّدها ترقيعها نيابة عنك. الدرجة تقيس الثغرة، لا تقيس مدى انكشافك أنت.

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

ما الذي ينبغي فعله؟

إن كنت تستخدم Spring AI، فهذا هو إجراؤك العملي. فثغرات مايكروسوفت عولجت من جانب الخادم، أما هذه فترقيعها مسؤوليتك أنت.

# الترقية إلى الإصدار الذي يحتوي على الإصلاح
./mvnw versions:set-property -Dproperty=spring-ai.version -DnewVersion=2.0.1

يعالج إصدار Spring AI 2.0.1، الصادر في 21 أغسطس 2026، سبع ثغرات:

الثغرة	المشكلة
CVE-2026-59318	إرسال أدوات غير مُعلنة عبر حقن الموجّهات
CVE-2026-59308	تجاوز عزل المستأجرين في ذاكرة التخزين الدلالية
CVE-2026-59294	اجتياز مسارات في `ResourceCacheService`
CVE-2026-59279	تخصيص جلسات عبر طلبات initialize
CVE-2026-59319	حقن وسوم في RediSearch
CVE-2026-47851	استدعاء تعاودي في مخطط ملفات PDF
CVE-2026-47852	التنبؤ بذاكرة تخزين نماذج ONNX

تنتقل معظم التطبيقات من 2.0.0 إلى 2.0.1 بمجرد رفع رقم الإصدار، لكن راجع ملاحظات الإصدار: فهناك تغييرات كاسرة مصاحبة، منها إيقاف نماذج Mistral المُهملة، وإعادة تسمية وحدة ذاكرة المحادثة في Redis، وتحوّل الوضع الصارم (Strict Mode) في OpenAI إلى false افتراضيًا.

ومن الدفعة ذاتها، تستحق ثغرة أخرى انتباهًا منفصلًا: CVE-2026-59285، وهي فك تسلسل غير آمن في Spring for GraphQL تصنّفها Sonatype بدرجة 9.2 حرجة — وتصبح قابلة للاستغلال حين يتولى Jackson 2.x فك تسلسل JSON وتتوفر أصناف معينة في مسار الأصناف (Classpath).

أما بالنسبة لخدمات Azure وMicrosoft 365، فلا حاجة إلى ترقيع، لكن توجيه مايكروسوفت هو التدقيق على أي حال:

دقّق إسنادات الهويات المُدارة. فخطورة ثغرة SRE Agent جاءت مما تستطيع الهوية الوصول إليه، وتحديد حجم نطاق التأثير هذا يبقى مسؤوليتك.
راجع نطاق صلاحيات RBAC لكل كيان خدمة (Service Principal) تابع لوكيل ذاتي التشغيل. مبدأ الصلاحية الأدنى هو التخفيف الوحيد الذي يصمد أمام الإفصاح القادم.
راقب أي تصعيد صلاحيات شاذ في النافذة الزمنية السابقة لوصول الإصلاح من جانب الخدمة.

أما معماريًا، فالعلاج الدائم واحد في كل البيئات: افرض قائمة الأدوات المسموح بها في طبقة الإرسال (Dispatch)، لا في الموجّه. فإن كان إطار عملك يُحلّل أداة لم يُعلن عنها الطلب الحالي، فأنت تحمل ثغرة Spring AI ذاتها أيًّا كانت اللغة التي كتبت بها.

ويمثل تشديد التفويض في مواصفة MCP 2026-07-28 — من التحقق من المُصدِر وربط بيانات الاعتماد به — إضافةً إلى اتجاه خارطة الطريق نحو DPoP واتحاد هوية أحمال العمل، الاستجابة على مستوى المعايير لهذه المشكلة بالضبط.

القيود

بعض التحفظات التي يجدر ذكرها صراحة.

لم تنشر مايكروسوفت تفاصيل استغلال لثغرتي CVE-2026-62830 وCVE-2026-59118، ولم يُبلَّغ عن استغلال أي منهما في البرية. والاستغلال الفعلي الوحيد المؤكد في إصدار أغسطس هو CVE-2026-68820، وهي غير متصلة بالوكلاء.

كما أن رقمَي إجمالي الثغرات المذكورين أعلاه يختلفان تبعًا لمنهجية كل جهة، وقد أوردناهما معًا بدل التوفيق بينهما. وعنوان تنبيه Spring AI يصف الآلية، لكن منشور الإصدار لا ينشر تفكيكًا تقنيًا أعمق، ما يعني أن الشروط المسبقة الدقيقة لثغرة CVE-2026-59318 ليست معلنة بالكامل.

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

الخلاصة

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

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

افرض القيود عند الحدود. النموذج ليس أداة تحكم أمني.