مطالبة واحدة، وكيل واحد، حساب AWS كامل: داخل AgentCorruption على Amazon Bedrock AgentCore

في 8 أكتوبر 2026، Zenity Labs كشفت AgentCorruption: سلسلة من الثغرات في Amazon Bedrock AgentCore، المنصة المُدارة من AWS لنشر وتشغيل وكلاء الذكاء الاصطناعي، التي مكّنت مُوجّهًا واحدًا باللغة الطبيعية لوكيل عام واحد من التحكم في كل وكيل AgentCore في نفس حساب AWS والمنطقة. نُشر البحث إلى جانب محاضرة في SecTor 2026 في تورونتو، حيث قدم مدير أبحاث الأمن في Zenity، تامير إيشاي شربات، العرض (Dark Reading، 8 أكتوبر 2026). تقرير Zenity الخاص، المنسوب إلى شربات، لانا سلامة، دميتري لوزوفوي وجواو دوناتو، يبدأ بالآلية: وكيل AgentCore يمتلك أي أداة قادرة على إجراء طلب خارجي يمكن توجيهه لاستدعاء AWS Instance Metadata Service (IMDS) على العنوان المحلي 169.254.169.254، الذي يُرجع بيانات اعتماد مؤقتة لدور تنفيذ الوكيل نفسه. تذكر Zenity أنها صدّرت تلك البيانات إلى جهازها الخاص وأكدت أنها عملت من هناك. لم يتم تعيين معرف CVE.

يسجّل الأرشيف هذا باعتباره ثغرة — شيئًا تم العثور عليه، وليس بالضرورة استُغِل — بدرجة عالية من الخطورة، وبثقة A، ودون ضرر حقيقي مسجّل، وتورّط مؤكّد للذكاء الاصطناعي. تختلف الأطراف حول التأطير رغم اتفاقها على السلوك: قالت AWS لـ Dark Reading إن البحث "يصوّر سلوكًا متوقعًا وموثّقًا على نحو غير دقيق باعتباره ثغرة."

ما كانت عليه السلسلة في الواقع

تُغلّف AgentCore كل وكيل كحاوية وتشغّله، لكل جلسة، في Firecracker MicroVM. يعيد أول منشور لـ Zenity في هذه السلسلة إنتاج موطئ القدم بالكامل عبر طلب بلغة بسيطة إلى وكيل اختباري مبنيّ باستخدام Strands SDK، إطار عمل الوكلاء مفتوح المصدر من AWS، الذي يوفّر أداة طلب HTTP مدمجة وأداة shell. لم يقيّد microVM حركة المرور إلى خدمة البيانات الوصفية، لذا جاء الطلب من داخل المثيل وأجابت IMDS عليه. ثم تتبّع الباحثون نقاط النهاية: اسم دور IAM، وبيانات اعتماد STS المؤقتة نفسها، ونقطة نهاية بيانات المستخدم — التي أعادت معرّف الحساب وARNs الكاملة ورابط وقت التشغيل وAmazon Elastic Container Registry (ECR) URI الخاص بصورة الوكيل — ووسوم المثيل بما في ذلك سلسلة شهادات mTLS ومفتاح خاص ورابط موقّع مسبقًا لتخزين داخلي. تقول Zenity إن النتيجة نفسها جاءت عبر أداة shell، لأن فشل العزل يقع على مستوى المنصة وليس في أي أداة بعينها.

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

الدور الافتراضي هو حيث تحوّل موطئ القدم إلى حساب.

المشكلة الثانية، التي أُبلغ عنها بشكل منفصل، هي أن الأذونات المرفقة بـ AgentCore افتراضيًا لم تكن مقيّدة بوكيل واحد. وتصف AgentCore أذونات تمتد عبر كل موارد AgentCore في الحساب والمنطقة، بما في ذلك bedrock-agentcore:InvokeAgentRuntime، bedrock-agentcore:ListEvents، bedrock-agentcore:CreateEvent، bedrock-agentcore:DeleteEvent وعند طرف بيانات الاعتماد في السلسلة، bedrock-agentcore:GetResourceApiKey وsecretsmanager:GetSecretValue.

حولت القابلية للتعداد تلك الأحرف البديلة إلى قائمة أهداف. استخدمت Zenity إذن الدور logs:DescribeLogGroups، لأن AgentCore تسمي مجموعة سجلات CloudWatch لكل وكيل /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}، واستنتجت معرفات الوكلاء من أسماء مجموعات السجلات تلك. اتبعت أسماء مستودعات ECR اصطلاحًا لاحظه الباحثون — bedrock-agentcore-<agent_name> — بحيث يمكن سحب صورة كل وكيل في المنطقة. تم العثور على موارد الذاكرة بالطريقة نفسها، من نمط مجموعة السجلات /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}، وأذونات الدور ListActors، ListSessions و ListEvents أنتجت معرفات الفاعل والجلسة اللازمة لقراءة معرفات المحادثة.

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

كانت الذاكرة هي الجزء الذي بقي بعد انتهاء التوجيه.

يحتفظ AgentCore Memory بالمحادثة نفسها كذاكرة قصيرة المدى ويخزّن السجلات المستخرجة كذاكرة طويلة المدى، باستخدام استراتيجيات تُسمى SEMANTIC، USER_PREFERENCE، SUMMARIZATION وEPISODIC. استخدمت Zenity CreateEvent لكتابة أحداث المحادثة في موارد ذاكرة الوكلاء الآخرين. ويتوخى منشورها الحذر بشأن ما يمكن لتلك الوظيفة الأولية فعله وما لا يمكنها فعله: لا يسمح CreateEvent للمستدعي باختيار نطاق أسماء طويل المدى أو الكتابة فوق سجل مباشرةً — فالاستراتيجيات المُهيأة للذاكرة الهدف هي التي تقرر ما يتم استخراجه وأين يستقر. تصف Zenity أيضًا DeleteEventبأنه يُستخدم لإزالة أحداث نتائج الأدوات حتى يستنتج الوكيل استنتاجًا خاطئًا من بيانات مفقودة، ولطمس الآثار عبر حذف الحدث الذي زرع ذاكرة.

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

بيانات الاعتماد خارج AWS

المنشور الأخير في السلسلة يغلق الحلقة على الأدوات المتصلة. يخزّنان AgentCore Identity و Outbound Auth بيانات اعتماد الأدوات كأسرار في AWS Secrets Manager، تحت أسماء مبنية من اسم المزوّد ونمط ثابت مثل bedrock-agentcore-identity!default/apikey/{provider_name}. استعادت Zenity أسماء المزوّدين عن طريق كشط الكود المصدري للوكيل الذي كانت قد سحبته بالفعل من ECR، واستعادت أخرى عن طريق القوة الغاشمة: وتذكر أن اللاحقة الافتراضية المكوّنة من خمسة أحرف يتم توليدها من جانب العميل من الأرقام والحروف الصغيرة، مما يعطي 2 x (10+26)^5 = 120,932,352 توليفة عبر نوعي المزوّدين. بالمعدل الذي يمكنها تحمّله من الطلبات ضد Secrets Manager، تقول Zenity إن التعداد الكامل يستغرق عدة ساعات — أطول مما تدوم بيانات اعتماد STS — لذلك بنت حلقة تعيد الاستعلام من نقطة نهاية IMDS الخاصة بالوكيل للحصول على بيانات اعتماد جديدة عند انتهاء صلاحية القديمة. تضيف Zenity أن متغيرات البيئة كانت قابلة للقراءة من خلال نقطة نهاية بيانات المستخدم الوصفية مع كل اسم مسبوق بـ CONTAINER_ENV_، بما في ذلك المفتاح الذي يستخدمه الوكيل للمصادقة مع مزوّد النموذج الخاص به، وأن استدعاء كل وكيل مكتشف بمطالبة مناسبة يحصد تلك القيم على نطاق واسع.

مُثبَت، ومُتنازَع عليه بسبب مسألة شكلية.

ما تم إثباته ضيّق ومحدد. كان بإمكان وكلاء AgentCore الوصول إلى IMDS والحصول على بيانات الاعتماد المؤقتة الخاصة بدور التنفيذ الخاص بهم — ولا تنازع AWS في ذلك، واصفةً إياه في بيانها بأنه "موثّق ومتوقع". كان دور التنفيذ الافتراضي يحمل أذونات محددة النطاق على مستوى الحساب والمنطقة لا على مستوى وكيل واحد؛ وقد غيّرت AWS ذلك منذ ذلك الحين، وتقول Zenity إن اختبارها الخاص أكد هذا التقليص. هذا البحث عرض توضيحي، وليس حملة مرصودة: قال Sharbat لـ Dark Reading إن Zenity لم تر أي دليل على استغلال الثغرة في الواقع قبل الإصلاح، وعزا ذلك جزئيًا إلى صعوبة تحديد المنظمات التي تشغّل وكلاء على AgentCore، وأضاف أنه "متأكد بنسبة 100% من وجود طرق للقيام بذلك".

موضع الخلاف هو ما إذا كان ينبغي تسمية أي من ذلك ثغرة أمنية. وجاء في بيان AWS، كما ورد إلى Dark Reading وThe Next Web: "تدرك AWS البحث المنشور حول Amazon Bedrock AgentCore، الذي يصوّر سلوكًا متوقعًا وموثقًا على نحو غير دقيق باعتباره ثغرة أمنية. لا يستطيع الوكيل الوصول إلى موارد في حساب AWS آخر إلا إذا منح المطوّر صلاحيات صراحةً على كل من دور تنفيذ الوكيل والمورد الهدف." ويحافظ بيان AWS الذي أُعيد نشره في منشورات Zenity نفسها على جوهر الجملة الأولى — "السلوك الموصوف موثّق ومتوقع" — ويضيف أنه ينبغي للعملاء منح أدوار التنفيذ فقط الصلاحيات التي تحتاجها وكلاؤهم. ثمة أمران يكمنان وراء الخلاف. تضع AWS الحدود في إطار الوصول إلى موارد في حساب AWS آخر، بينما يتعلق اكتشاف Zenity بوكلاء داخل حساب AWS ومنطقة واحدة؛ كما أن الأدوار التي تصفها Zenity جاءت من الإعدادات الافتراضية للمنصة وليس من عميل يكتب سياسة يدويًا.

تصحيح The Next Web لقصتها الخاصة جدير بالتسجيل، لأنه يُظهر أن الادعاء ضُيّق نطاقه من شخص غير الباحثين. فقد نشرت أولاً، ثم صححت لاحقاً، عنواناً يقول إن الباحثين سيطروا على كل وكيل AgentCore في منطقة واحدة؛ وتذكر النسخة المصححة أن البحث شمل وكلاء داخل حساب AWS واحد ومنطقة واحدة، وتلاحظ أن العنوان السابق كان قد عرض ادعاء الباحثين على أنه حقيقة.

الجدول الزمني للإفصاح

قدمت Zenity تقريرين بدلاً من واحد، وتم الرد عليهما بشكل مختلف. تم تقديم تقرير الوصول إلى IMDS في 25 ديسمبر 2025؛ أغلقت AWS التقرير في 12 أبريل 2026 كـ "معلوماتي"، وكتبت أن AgentCore لم تستخدم IMDSv2 إلا منذ 14 فبراير 2026، حيث تطلق الوكلاء المنشورة حديثًا بهذه الطريقة. هذا التعديل مهم لتفاصيل هذا البحث، لأن IMDSv2 يتطلب رمز جلسة في كل طلب ويكسر الجلب العادي غير الموثق الذي استخدمه الباحثون للحصول على بيانات الاعتماد. التقرير الثاني، حول الدور الافتراضي ونطاق تأثيره، تم تقديمه في 12 يناير 2026. أخبرت AWS شركة Zenity في 25 فبراير 2026 أن الفريق كان يعمل عليه بينما بقي الدور كما هو؛ راجعت Zenity الدور مرة أخرى في 22 يونيو 2026 ووجدت أن أذوناته لم تتغير. مراجعة نهائية في 29 سبتمبر 2026 وجدت أن الدور قد ضُيّق بشكل كبير، ويذكر البيان الصحفي لـ Zenity أن الإزالة شملت استدعاء وكلاء آخرين، وقراءة المحادثات الخاصة، والوصول إلى الأسرار في AWS Secrets Manager، مع تقييد الأذونات الأخرى بشكل كبير أيضًا. وتشير منشورات Zenity الخاصة إلى أن AWS جعلت منذ ذلك الحين IMDSv2 هو الافتراضي لعمليات نشر AgentCore وأن الجانبين تعاونا خلال هذه العملية.

ما هو غير معروف

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

قال شربات لـ Dark Reading إن Zenity تدرس الآن منصات سحابية أخرى بحثًا عن مشكلات مماثلة تتعلق بالوصول إلى البيانات الوصفية، وإن الشركة لم تسمِّها بعد. وتتعلق الخلاصة التي ذكرها بالأذونات وليس بخدمة البيانات الوصفية وحدها: "حتى إذا وصل شخص ما إلى IMDS، فإن نطاق التأثير سيكون أصغر بكثير."

لماذا يتم الاحتفاظ بهذا السجل

ليس ما يجعل AgentCorruption لافتًا هو أن نقاط نهاية البيانات الوصفية فكرة جديدة. فقد لفت Sharbat انتباه جمهور SecTor إلى اختراق Capital One عام 2019، حيث وصل هجوم SSRF إلى IMDS وتحوّل إلى بيانات اعتماد مسروقة، ووصف ذلك بأنه فشل في أقل صلاحية من النوع نفسه. الجديد هو الجهة الفاعلة التي تقوم بالجلب. فالطلب الذي أنتج هوية AWS صدر عن وكيل ذكاء اصطناعي ينفّذ ما طُلب منه، بلغة عادية، عبر أداة أُعطيت له كي يكون مفيدًا — وقد أعاد الوكيل تمرير الإجابة. والشرطان اللذان حوّلا ذلك إلى مشكلة على مستوى الحساب هما نقطة نهاية بيانات وصفية لم تحجبها البيئة المعزولة، ودور افتراضي أوسع من الوكيل الذي كان يحمله.

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

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