ثغرة Amazon Q Developer الحرجة: اختراق بيانات المطورين عبر MCP Configs

مقدمة تحليلية

تم الكشف مؤخرًا عن ثغرة أمنية عالية الخطورة في Amazon Q Developer، المساعد البرمجي المدعوم بالذكاء الاصطناعي من أمازون، والتي كان من الممكن أن تسمح لمستودعات التعليمات البرمجية الخبيثة (malicious repositories) بتنفيذ أوامر وسرقة بيانات اعتماد مطوري السحابة. هذه الثغرة، التي تم تتبعها تحت المعرف CVE-2026-12957 وحصلت على درجة خطورة 8.5 في نظام CVSS، تُبرز تحديات أمن سلسلة التوريد (supply chain security) في بيئات التطوير الحديثة التي تعتمد بشكل متزايد على أدوات الذكاء الاصطناعي. اكتشف باحثو Wiz Research هذه المشكلة، وقد عملت أمازون على معالجتها بسرعة، إلا أن تداعياتها تكشف عن نمط مقلق في كيفية تعامل أدوات المساعدة البرمجية مع الثقة في بيئات العمل. يكشف هذا الاكتشاف عن مسار هجوم قصير ومباشر: بمجرد أن يقوم مطور بفتح مستودع تعليمات برمجية خبيث والثقة في بيئة العمل (workspace)، يمكن لـ Amazon Q أن يقوم بتنفيذ بقية الهجوم تلقائيًا. هذا يعني أن مجرد استنساخ (cloning) مستودع غير موثوق به قد يؤدي إلى اختراق كامل لجلسة السحابة الخاصة بالمطور وسرقة بياناته الحساسة دون الحاجة إلى كلمات مرور إضافية أو خطوات مصادقة ثانية. هذا التهديد يوجه الضوء نحو أهمية التدقيق في المصادر والاعتمادات في منظومة التطوير بأكملها، خاصة مع تزايد دمج الذكاء الاصطناعي في كل مرحلة من مراحل دورة حياة البرمجيات.

التحليل التقني

تكمن الثغرة CVE-2026-12957 في طريقة تعامل Amazon Q مع خوادم Model Context Protocol (MCP). يقوم Amazon Q بقراءة ملف تكوين MCP، تحديدًا `.amazonq/mcp.json`، من بيئة العمل المفتوحة وتشغيل الخوادم التي يحددها هذا الملف. خوادم MCP هي عمليات محلية يمكن للمساعد الذكي تشغيلها للوصول إلى قواعد البيانات أو واجهات برمجة التطبيقات (APIs) أو أدوات البناء. وبالتالي، فإن بدء تشغيل أحد هذه الخوادم يعني فعليًا تشغيل أوامر على جهاز المطور. هذه العمليات المبدئية التي يتم تشغيلها ترث بيئة المطور الكاملة، والتي تشمل عادةً مفاتيح AWS، ورموز CLI الخاصة بالسحابة، وأسرار API، ومقابس وكيل SSH. بدمج هذين العنصرين، يصبح بالإمكان لملف بسيط موجود في مستودع تعليمات برمجية مستنسخ تشغيل تعليمات برمجية عشوائية (arbitrary code) مع جلسة السحابة النشطة للمطور. هذا يسمح للمهاجم بالوصول إلى صلاحيات المطور الحية دون أي خطوات مصادقة إضافية. في إثبات المفهوم (proof of concept) الذي قدمته Wiz، قام الملف بتشغيل aws sts get-caller-identity وإرسال الإخراج إلى خادم المهاجم، مما أدى إلى التقاط جلسة AWS النشطة. تعتمد الخطوات التالية للهجوم على صلاحيات السحابة الخاصة بهذا المطور، والتي يمكن أن تتراوح من اختراق مستخدم IAM لتحقيق الاستمرارية، إلى الوصول إلى الخدمات الداخلية، أو حتى التمحور نحو بيئات الإنتاج. تختلف رواية أمازون و Wiz حول خطوة الموافقة. ينص إشعار أمازون الأمني على أن المستخدم يجب أن يثق في بيئة العمل عند المطالبة بذلك، ويصنف CVSS تفاعل المستخدم على أنه سلبي (passive). ومع ذلك، ذكرت Wiz أنه لم تكن هناك خطوة موافقة منفصلة لخوادم MCP نفسها قبل الإصلاح. يغلق التصحيح الأمني هذه الفجوة: يقوم Amazon Q الآن بتحديد خادم MCP غير موثوق به ويسمح للمطور برفض الأمر قبل تنفيذه. تعيش الثغرة في "Language Servers for AWS"، وهو وقت التشغيل الذي يدعم Amazon Q عبر أدوات التطوير الشهيرة مثل VS Code و JetBrains و Eclipse و Visual Studio. جميع هذه الإضافات (plugins) الأربعة تحتوي على هذا المكون، مما يعني أنها كانت جميعًا معرضة للخطر بالإصدارات التي شحنت نسخة قديمة. للتصحيح، يجب على المستخدمين التحديث. تم إصلاح CVE-2026-12957 في Language Servers for AWS 1.65.0، لكن نشرة AWS توصي بالانتقال إلى الإصدار 1.69.0. هذا البناء أيضًا يغلق مشكلة ثانية، CVE-2026-12958، وهي فحص مفقود للروابط الرمزية (symlink check) قد يسمح بكتابة ملفات عشوائية خارج حدود الثقة الخاصة ببيئة العمل. الحد الأدنى من إصدارات الإضافات التي تم تصحيحها هي:

• VS Code: 2.20 أو أحدث
• JetBrains: 4.3 أو أحدث
• Eclipse: 2.7.4 أو أحدث
• Visual Studio toolkit: 1.94.0.0 أو أحدث

يتم تحديث خادم اللغة تلقائيًا ما لم تحجبه الشبكة، ويؤدي إعادة تحميل بيئة التطوير المتكاملة (IDE) إلى سحب أحدث إصدار. لا يوجد استغلال عام معروف للثغرة حاليًا، حيث تسرد قاعدة بيانات CISA ADP الثغرة CVE-2026-12957 على أنها "لا يوجد". اكتشفت Wiz الثغرة من خلال البحث وأبلغت عنها بالتنسيق مع أمازون، حيث تم الإبلاغ في 20 أبريل وتم توفير الإصلاح في 12 مايو، قبل النشر العام للمعلومات في 26 يونيو.

السياق وتأثير السوق

لا تعتبر ثغرة Amazon Q مجرد حادثة منعزلة، بل هي جزء من نمط متكرر في مساعدات البرمجة المدعومة بالذكاء الاصطناعي. ففي حين أن الأخطاء ليست متطابقة تمامًا، إلا أنها تشترك في جوهر واحد: تحويل تكوين المشروع إلى سلوك قابل للتنفيذ، وفشل فحوصات الثقة حول هذا التحول مرارًا وتكرارًا. لقد شهدنا حوادث مماثلة مع مساعدات برمجية أخرى. فثغرات Claude Code (CVE-2025-59536) و Cursor (CVE-2025-54136) كانتا كلتاهما تتعلقان بتكوين MCP على مستوى المشروع أدى إلى تنفيذ الأوامر. حتى Windsurf (CVE-2026-30615) وصل إلى نفس النتيجة عبر مسار مختلف، حيث سمح محتوى يتحكم فيه المهاجم بإعادة كتابة تكوين MCP المحلي لتسجيل خادم خبيث. يكمن التحدي الأساسي في الموازنة بين سهولة ومرونة السماح لمجلد المشروع بتكوين وكيل الذكاء الاصطناعي، وبين المخاطر الأمنية الكامنة في هذه العملية. تكوين المستودع (repo-carried config) هو في جوهره مدخل غير موثوق به. إن تحويله إلى عملية قيد التشغيل يجب أن يتطلب موافقة صريحة من المستخدم. إن الاعتماد المتزايد على أدوات الذكاء الاصطناعي في دورة حياة التطوير يعني أن هذه الثغرات يمكن أن يكون لها تأثير مضاعف على أمن سلسلة التوريد البرمجية بأكملها. مع استمرار تطور هذه الأدوات، ستزداد الحاجة إلى مراجعات أمنية صارمة ونماذج ثقة محسنة لمنع استغلال مماثل في المستقبل. إن السوق يتجه نحو دمج أعمق للذكاء الاصطناعي في بيئات التطوير، مما يجعل هذه القضايا الأمنية نقطة محورية للمنافسة والابتكار.

رؤية Glitch4Techs

من منظور Glitch4Techs، تُظهر ثغرة Amazon Q Developer نمطًا مزعجًا يُسلط الضوء على تضارب جوهري بين "الراحة" التي توفرها مساعدات البرمجة الذكية و"الأمان" الذي يجب أن يكون أولوية قصوى. على الرغم من أن أمازون قد قامت بالتصحيح وأضافت خطوة موافقة صريحة لتشغيل خوادم MCP غير الموثوق بها، إلا أن هذا لا يعالج الجذر العميق للمشكلة: الميل إلى الثقة الضمنية في التكوينات المستندة إلى المستودعات. إن "تفاعل المستخدم السلبي" الذي أشارت إليه CVSS لا يقلل من خطورة الهجوم؛ ففي بيئات التطوير سريعة الوتيرة، غالبًا ما يتم النقر على مطالبات الثقة دون تدقيق كافٍ، مما يجعل المطورين عرضة للخطر. تثير هذه الثغرات مخاوف أمنية بالغة الأهمية حول سلسلة التوريد البرمجية. فمع ازدياد اعتماد الفرق على مستودعات خارجية، سواء كانت مفتوحة المصدر أو داخلية، يصبح أي تكوين قابل للتحكم من قبل المهاجم بمثابة نقطة دخول محتملة. يمكن أن يؤدي استغلال واحد إلى سرقة مفاتيح AWS، مما يمنح المهاجمين وصولاً لا مثيل له إلى البنية التحتية السحابية والتطبيقات الحساسة. يجب على المؤسسات أن تعتمد نهجًا أكثر حذرًا تجاه الثقة في بيئات التطوير المدعومة بالذكاء الاصطناعي، وتطبيق مبدأ "أقل الامتيازات" ليس فقط على المستخدمين ولكن أيضًا على العمليات الآلية والأدوات. نتوقع أن تستمر هذه الثغرات في الظهور مع نضوج سوق مساعدات البرمجة بالذكاء الاصطناعي. إن الضغط من أجل الميزات والراحة قد يتجاوز أحيانًا متطلبات الأمن الصارمة. يجب أن تكون هناك نماذج أمنية أكثر قوة تفرض التحقق الصارم من التكوينات التي تأتي من مصادر خارجية قبل السماح بتنفيذ أي تعليمات برمجية. نتوقع أيضًا زيادة التركيز على أدوات تحليل التعليمات البرمجية الثابتة والديناميكية التي يمكنها اكتشاف مثل هذه التكوينات الخبيثة قبل أن يتمكن المطور من تشغيلها. في النهاية، يقع العبء على المطورين والشركات على حد سواء لتبني ثقافة أمنية أكثر يقظة في عصر الذكاء الاصطناعي التوليدي.