عندما يتجه وكيل AI إلى الداخل: يبيّن Loom وToFu أن خادمك هو الوجهة الأخطر

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

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

ما الذي نُشر

ثلاث ثغرات في Loom. في 2 أكتوبر 2026، نشرت AWS النشرة الأمنية 2026-124-AWS بشأن Loom، وهي منصة مفتوحة المصدر من AWS Labs لتنسيق وكلاء AI. توصي AWS بالترقية إلى الإصدار 1.7.0 والتأكد من أن النسخ المتفرعة والشيفرة المشتقة تتضمن الإصلاحات أيضًا. وفقًا للنشرة:

• CVE-2026-103956 (تجاوز المصادقة على الهوية، CWE-306 وCWE-1188): في الإصدارات السابقة لـ1.6.1، عند النشر دون إعداد موفّر هوية، كان بإمكان أي عميل على الشبكة الحصول على صلاحيات إدارية كاملة على مستوى التحكم الخاص بالوكلاء. أتاحت هذه الصلاحيات تسجيل خوادم أدوات، وقراءة بيانات اعتماد محفوظة لعمليات التكامل، وإعادة كتابة سياسات IAM المرتبطة بأدوار الوكلاء. أُصلحت الثغرة في الإصدار 1.6.1، الذي نُشر في 4 أغسطس 2026.
• CVE-2026-103957 (CWE-918 وCWE-201): في الإصدارات السابقة لـ1.7.0، كان بإمكان مستخدم مصادق عليه يملك صلاحية mcp:write أو a2a:write تحديد عنوان اكتشاف OAuth2. كانت الوثيقة الموجودة في ذلك العنوان توجّه الخادم إلى إرسال أسرار عميل OAuth2، أو رمز وصول لمستخدم آخر، إلى نقطة نهاية يتحكم فيها طرف ثالث. وفقًا لـAWS، حظر الإصدار 1.6.1 الوصول إلى العناوين الداخلية عبر هذا المسار، لكنه لم يعالج تسرّب الرموز بالكامل. أُدرج الإصلاح الكامل في 1.7.0.
• CVE-2026-103958 (CWE-918): في الإصدارات السابقة لـ1.7.0، كان بإمكان مستخدم يملك الصلاحيات نفسها توجيه الاتصالات بخوادم الأدوات (MCP) والوكلاء البعيدة (A2A) إلى أي وجهة في الشبكة الداخلية وقراءة الردود. شملت الوجهات أيضًا نقطة النهاية التي توفر بيانات اعتماد للحاوية.

دراسة شملت 273 خادم MCP. في 9 أكتوبر 2026، نشر باحثون من Pennsylvania State University وUniversité Montpellier وDartmouth College الورقة البحثية عن ToFu. طوّروا أداة اختبار تشويشي تولّد اختبارات أمنية من الأوصاف التي تقدمها الأدوات نفسها للنموذج. وشغّلوها على 273 خادم MCP مفتوح المصدر، تضم 3,405 أدوات. وفقًا للورقة، عُثر على 253 خللًا مؤكدًا في 343 أداة ضمن 118 خادمًا. شملت النتائج 64 حالة اجتياز للمسارات، و7 حالات SSRF، و5 حالات تسريب للمعلومات، و3 حالات حقن لأوامر النظام. وضمت الفئة الأكبر 115 حالة تُعاد فيها المخرجات دون تهريب المحارف الخاصة.

تصف الورقة أيضًا هجومًا يسميه الباحثون Repeat-After-Me: يُطلب من النموذج تكرار نص يبدو كاستدعاء لأداة. تفسّر طبقة التنسيق المخرجات على أنها استدعاء حقيقي وتنفّذه. وفقًا للورقة، أُعيد إنتاج هذا السلوك في ست طبقات تنسيق: LangGraph وMAF وADK 2.0 وAutoGen وStrands وCrewAI. ويخلص الباحثون إلى أنه لا ينبغي اعتبار الوسيط الذي ولّده النموذج مدخلًا موثوقًا، حتى لو كان مطابقًا لمخطط الأداة.

الآلية نفسها في طبقتين

في Loom، فتحت الشيفرة التحتية للمنسّق نفسه اتصالات بأي عنوان يقدمه المستخدم. وهي الشيفرة التي تتولى اكتشاف OAuth2 والاتصال بخوادم الأدوات والوكلاء البعيدة. وفي ToFu، يظهر النمط نفسه في الطبقة الأدنى، داخل الأدوات. في دراسة الحالة الواردة في الورقة، تتحقق أداة لالتقاط صور صفحات الويب فقط من أن المدخل عنوان URL صالح. وفقًا للباحثين، يمكن لوكيل تأثر بمحتوى محقون استخدام هذه الأداة لقراءة ملفات من الخادم والتقاط صور لخدمات تستمع على واجهة loopback وفي الشبكة الخاصة. وفي خادم MCP آخر مخصص لـWordPress، اتصلت الأداة دون قيود بعنوان URL لموقع قدّمه صاحب الطلب. وفقًا للورقة، اكتُشف هذا الخلل في تشغيل فُعّلت فيه جميع الاختبارات. ويُظهر سجل التشغيل اتصالًا بعنوان على 127.0.0.1.

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

من يتحكم في URL

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

لماذا إلى الداخل تحديدًا

من الخارج، تبدو الوجهة الداخلية أكثر أمانًا من وجهة على الإنترنت. لكن الوضع معكوس من منظور المهاجم. فقد تضم الوجهات الداخلية خدمات لم تُحصّن لأنها «موجودة على localhost فقط»، ومستوى التحكم الخاص بالوكلاء نفسها، ونقاط نهاية توفر بيانات اعتماد. في CVE-2026-103958، لا يصل المهاجم إلى نقطة النهاية التي توفر بيانات اعتماد للحاوية فحسب، بل يقرأ الرد أيضًا. لذلك، إذا قُرئت بيانات اعتماد دور الحاوية، توصي AWS باستبدال بيانات اعتماد الجلسة لدور IAM والتحقق في CloudTrail مما إذا كانت قد استُخدمت على نحو غير متوقع. وهكذا ينتقل الضرر من الخادم إلى الحساب السحابي.

تحدد اختبارات SSRF التي طوّرها الباحثون لـToFu الوجهات المحظورة بالطريقة نفسها: loopback، ونطاقات RFC 1918، وعناوين link-local، وعناوين البيانات الوصفية للسحابة. وفقًا لجدول الأثر في الورقة، يُعدّ اتصال الخادم بعنوان حدده المهاجم خلل SSRF، بما في ذلك العناوين من هذه الأنواع. يخالف هذا الاتصال شرط اقتصار طلبات الخادم على الوجهات المخصصة لها.

لماذا لا يكفي الإصلاح على مستوى المكوّن

لذلك ثلاثة أسباب. الأول: تأتي الإصلاحات على مراحل. في Loom، حظر الإصدار 1.6.1 العناوين الداخلية في مسار الاكتشاف. ومع ذلك، استلزم علاج تسرّب الرموز بالكامل إصدارًا آخر. الثاني: وجد ToFu عددًا قدره 7 من عيوب SSRF في الأدوات التي اختُبرت. وفقًا للورقة، تفوّت أدوات الفحص التي تبحث في الشيفرة عن قائمة ثابتة من العمليات الخطرة خاصية مثل «الوجهة مقيدة بقائمة سماح». فلا توجد نقطة محددة في الشيفرة يمكن البحث عنها للتحقق من هذه الخاصية. الثالث: وفقًا للورقة، أمكن تشغيل 273 فقط من أصل 1,404 مستودعات تتيح أدوات أثناء الاختبار. أما البقية، فإما تعذّر بناؤها، أو لم تبدأ، أو تطلبت بيانات اعتماد. تصف الأرقام ما أمكن اختباره، لا جميع المستودعات.

يوصي الباحثون بأن تفرض كل أداة بنفسها القيود التي تعلن عنها. هذه توصية صحيحة لمطوّري الأدوات، لكنها لا تكفي لمسؤول خادم يشغّل عشر أدوات من عشرة مطوّرين. المضيف هو المكان الذي تملك فيه التحكم. فالقاعدة التي تُفرض على العنوان الذي تتصل به العملية فعليًا لا تعتمد على طريقة كتابة URL. يختبر ToFu في المدخلات تمثيلات بديلة لعناوين IP، مثل الكتابة بالنظام الثماني أو الست عشري وعناوين IPv4 المضمّنة في IPv6. عند مستوى الاتصال، يكون العنوان قد فُسّر بالفعل، ولا تعود لهذه الاختلافات أهمية.

loopback ليس حاجزًا أمام عملية محلية

الإجراء المؤقت الذي توصي به AWS لمعالجة CVE-2026-103956 هو التأكد من إعداد موفّر هوية قبل إتاحة الوصول إلى الواجهة الخلفية من خارج loopback. يحمي الربط بـloopback من عملاء الشبكة، وهذه هي تحديدًا المشكلة في هذه الثغرة. لكنه لا يحمي من SSRF: فالوكيل الذي يعمل على المضيف نفسه يصل إلى 127.0.0.1 دون صعوبة. لذلك يجب معالجة الجانبين. ينبغي ربط مستويات التحكم بـloopback، وتقييد عمليات الوكلاء بالوجهات التي وافقت عليها صراحة، دون أي وصول آخر إلى loopback الخاص بالمضيف.

خطوات عملية على الخادم

إذا كنت تشغّل Loom:

• رقِّ إلى 1.7.0 وتحقق من أن نسخك المتفرعة تتضمن الإصلاحات أيضًا.
• إلى حين الترقية: تأكد من اكتمال إعداد مجموعة مستخدمي Cognito أو موفّر هوية خارجي قبل إتاحة الوصول إلى الواجهة الخلفية من خارج loopback. وتأكد أيضًا من عدم ضبط المتغير LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV في أي بيئة منشورة ليست بيئة تطوير محلية. هذه هي إرشادات AWS. وخلافًا لما ورد في تغطية GBHackers، فهي لا تقتصر على بيئة الإنتاج. كذلك، احصر صلاحيتي mcp:write وa2a:write في المسؤولين الموثوقين. وفقًا لـAWS، تقلل هذه الخطوة المخاطر، لكنها لا تزيلها دون الإصلاح.
• بعد الترقية: استبدل أسرار عميل OAuth2 في تكاملات MCP وA2A. ألغِ الرموز التي كانت نشطة خلال الفترة التي كان فيها النظام عرضة للثغرة، وأصدر رموزًا جديدة. إذا قُرئت بيانات اعتماد دور الحاوية، فاستبدل بيانات اعتماد الجلسة وافحص CloudTrail.

لكل منظومة وكلاء:

1. احصر المنسّقات والوكلاء وخوادم MCP التي تعمل على الخادم، وحدد أيها يقبل URL أو اسم مضيف أو عنوانًا كمدخل. مثل أدوات جلب الصفحات والتقاط صورها، وخطافات الويب، والاكتشاف.
2. اربط مستويات التحكم وواجهات الإدارة وقواعد البيانات بـ127.0.0.1. تحقق من الوضع الفعلي، لا من ملف الإعدادات وحده.
3. شغّل كل وكيل تحت مستخدم خاص به، في نطاق أسماء شبكة منفصل أو حاوية منفصلة، بحيث لا يكون loopback الخاص به هو loopback الخاص بالمضيف، وتتمكن قواعد الجدار الناري من تمييز حركة بياناته.
4. احظر افتراضيًا لهذه العمليات الوصول إلى loopback الخاص بالمضيف، وعناوين link-local ‏(169.254.0.0/16 وfe80::/10)، ونطاقات RFC 1918 ‏(10.0.0.0/8 و172.16.0.0/12 و192.168.0.0/16)، وعناوين IPv6 الخاصة (fc00::/7). اسمح بالوصول فقط إلى الوجهات الداخلية التي يحتاجها الوكيل فعلًا، كل وجهة على حدة.
5. لا تكتفِ بالحظر دون تسجيل: سجّل كل محاولة من عملية وكيل للوصول إلى عنوان بيانات وصفية أو نقطة نهاية توفر بيانات اعتماد. فهذه المحاولة واقعة تستدعي الفحص.
6. قلّص صلاحيات الدور السحابي المرتبط بالوكيل. إذا تسرّبت بيانات الاعتماد، فستحدد هذه الصلاحيات نطاق الضرر.
7. اختبر خوادم MCP الجديدة في بيئة معزولة. وفقًا للورقة، أثّرت أربعة خوادم في المضيف أثناء الاختبارات: حذفت ملفات خارج مساحة العمل، ووصلت إلى مسار خارج المجلد المخصص، وأغلقت جلسات طرفية لا تخصها، وشغّلت عمليات دون قيود. يشير الباحثون إلى أن هذه الحالات سبب إضافي لإجراء مثل هذه الاختبارات في بيئة اختبار معزولة.

كيف يساعد nuDefend

يعرض الأمر nudefend workloads أدوات AI التي تعمل على الخادم، ومنها منصات الوكلاء وخوادم MCP، سواء كانت تعمل مباشرة على المضيف أو داخل حاوية. وتظهر بجانب كل أداة المعلومات التي استُخدمت للتعرّف عليها.

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

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

يعرض الأمر nudefend expose كل خدمة تستمع على الخادم والجهات التي يمكنها الوصول إليها، من منظور الخادم نفسه. تُوسم الخدمة المرتبطة بـ127.0.0.1 أو بـ::1 بأنها local-only. إذا أصبحت خدمة كانت داخلية فقط متاحة من الخارج، يرصد nuDefend التغيير وينبّه إليه. وإذا كانت خدمة مكشوفة دون قصد، فيمكن حظر منفذها من لوحة التحكم أو سطر الأوامر، بعد معاينة تعرض بدقة ما سيُحظر. تتوفر تفاصيل إضافية في صفحة حركة البيانات الصادرة وصفحة الانكشاف.

الخلاصة

تصف ثغرات Loom ونتائج ToFu المشكلة نفسها في طبقتين: يتلقى مكوّن في منظومة الوكلاء عنوانًا من شخص غير المسؤول، ويفتح اتصالًا به من داخل الخادم. غالبًا ما تكون الوجهة هي الخادم نفسه، أو الشبكة الخاصة، أو نقطة نهاية توفر بيانات اعتماد. رقِّ Loom إلى 1.7.0 وتعامل مع بيانات الاعتماد وفق إرشادات AWS. وإلى جانب ذلك، لا تنتظر أن يصلح كل مطوّر أداة طريقة التعامل مع URL. اربط مستويات التحكم بـloopback، وافصل كل وكيل على مستوى الشبكة، واحظر افتراضيًا وصول عمليات الوكلاء إلى الوجهات الداخلية. تعامل مع كل اتصال منها بعنوان بيانات وصفية على أنه حدث يستدعي الفحص.