ثغرة DynamoDB MCP تنفذ شفرة عبر أسماء الجداول: حدّث إلى 2.1.6
نشرت AWS في 4 سبتمبر 2026 تنبيهاً أمنياً مهماً عن CVE-2026-85654، وهي ثغرة حقن شفرة في مولد CDK ضمن awslabs.dynamodb-mcp-server. وتحدد نشرة AWS الأمنية الإصدارات المتأثرة من 2.0.10 حتى 2.1.5، وتوضح أن أسماء جداول أو فهارس أو سمات مصاغة قد تسمح بتنفيذ شفرة عشوائية على المضيف الذي ينشر التطبيق المولد.
عالجت AWS الخلل بدءاً من الإصدار 2.1.6، ولذلك ينبغي لمن يشغّل مولد CDK التحقق من النسخة الفعلية وترقية أي إصدار داخل النطاق المتأثر. ويسجل تنبيه GitHub للثغرة تاريخ النشر نفسه ويصنفها عالية الخطورة بدرجة 7.1 وفق CVSS 4.0، مع اشتراط نشر التطبيق المولد لبلوغ أثر التنفيذ.
كيف يصل الاسم المصاغ إلى مضيف النشر؟
الثغرة تخص مكوّن توليد CDK في الخادم المفتوح المصدر، ولا تعني وجود خلل عام في خدمة Amazon DynamoDB. توفر الحزمة أداة generate_resources التي تقرأ dynamodb_data_model.json وتولد تطبيق CDK ينشئ جداول DynamoDB وإعداداتها؛ وبذلك تدخل أسماء الجداول والفهارس والسمات في عملية توليد الشفرة.
ينشأ الخلل من عدم تحييد عناصر خاصة يستخدمها محرك القوالب تحييداً سليماً. إذا احتوى ملف النموذج على اسم مُعدّ لهذا الغرض، فقد ينتقل إلى التطبيق المولد، ثم تصبح الشفرة قابلة للتنفيذ عندما ينشر المضيف ذلك التطبيق. هذا هو الأساس الفعلي لوصف العنوان: الاسم وحده ليس حادثاً أمنياً مكتمل الأركان، لكنه قد يتحول إلى شفرة ضمن مسار التوليد والنشر المتأثر.
للاستغلال شروط محددة. تشغيل نسخة متأثرة لا يثبت وقوع اختراق، كما أن مجرد وجود ملف JSON لا يحقق الأثر الموصوف؛ يجب أن يدخل الاسم المصاغ إلى مولد CDK ثم يُنشر التطبيق الناتج على المضيف. لذلك يتركز الفحص على البيئات التي استخدمت generate_resources فعلياً، لا على كل تثبيت لخادم MCP بصرف النظر عن الأدوات المشغلة.
تحقق من النسخة التي تشغّل الخادم فعلياً
في بيئة Python مثبتة تثبيتاً مباشراً، نفّذ python -m pip show awslabs.dynamodb-mcp-server واقرأ قيمة Version. ولتفادي فحص مفسر مختلف عن مفسر التشغيل، يمكن تنفيذ python -c "import importlib.metadata as m; print(m.version('awslabs.dynamodb-mcp-server'))" باستخدام مسار Python نفسه الذي يبدأ منه الخادم.
إذا كانت النتيجة بين 2.0.10 و2.1.5 شاملةً الطرفين، فالبيئة داخل النطاق المتأثر. الإصدار 2.1.6 أو أي إصدار أحدث يقع خارج النطاق الذي حددته النشرة، لكن ينبغي أيضاً مراجعة النسخ المتفرعة أو الشفرة المنسوخة داخلياً؛ فتغيير حزمة PyPI لا يحدّث تلقائياً fork يحتفظ بالمكوّن القديم.
في تشغيل uvx، افحص ملف إعداد MCP الفعلي وابحث عن قيمة الحزمة داخل args، مثل [email protected]. لا تعتمد على وجود نسخة أحدث في مستودع الحزم لإثبات ما تشغله عملية بدأت سابقاً، ولا تستخدم نتيجة pip من بيئة نظام منفصلة بوصفها دليلاً على نسخة بيئة uvx المعزولة.
تحديث uvx من دون إبقاء بيئة قديمة
توضح صفحة الحزمة على PyPI أن أداة generate_resources تولد تطبيق CDK من dynamodb_data_model.json، وأن الإصدار 2.1.6 صدر في 14 أغسطس 2026، بينما توفر إصدار أحدث هو 2.1.7 منذ 26 أغسطس. وبذلك تمثل 2.1.6 الحد الأدنى المصحح، لا أحدث إصدار متاح عند نشر التنبيه.
لبيئة uvx، ثبّت النسخة داخل إعداد MCP على [email protected] على الأقل، أو استخدم awslabs.dynamodb-mcp-server@latest إذا كانت سياسة الفريق تسمح بأحدث إصدار. عند الحاجة إلى إعادة التحقق من بيانات الحزمة المخزنة مؤقتاً، شغّل uvx مع --refresh، ثم أغلق عميل MCP والخادم وأعد تشغيلهما بالكامل.
- سجل إعداد MCP الحالي والنسخة أو القيد الموجود في args.
- استبدل أي إصدار من 2.0.10 إلى 2.1.5 بالإصدار 2.1.6 أو إصدار أحدث.
- حدّث ذاكرة uv المؤقتة عند الحاجة، ثم أعد تشغيل العميل حتى لا تستمر عملية قديمة.
- تحقق من الإعداد الذي تستخدمه العملية الجديدة، ولا تكتف بتعديل نسخة أخرى من ملف الإعداد.
- راجع ملف النموذج، ثم أعد توليد تطبيق CDK وافحص الفرق قبل إعادته إلى مسار النشر.
إذا كان الفريق يستخدم صورة حاوية أو قالب بيئة تطوير أو وكيل CI/CD، فيجب إعادة بناء ذلك الأصل ونشره أيضاً. النسخة المصححة على محطة مطور لا تغير حاوية أو صورة مبنية مسبقاً ما زالت تحمل إصداراً متأثراً.
الإجراء المؤقت عند تعذر التحديث
توصية AWS المؤقتة هي تجنب ملفات نماذج البيانات الآتية من مصادر غير موثوقة أو غير متحقق منها، ومراجعة dynamodb_data_model.json يدوياً قبل تشغيل مولد CDK. إذا تعذر إثبات مصدر الملف وسلامة أسمائه، فالإجراء المحافظ هو إيقاف generate_resources وعدم نشر التطبيق الناتج إلى أن تكتمل المراجعة أو الترقية.
ينبغي أن تغطي المراجعة العناصر التي حددها التنبيه، لا محتوى البيانات التجريبية وحده:
- مطابقة جميع أسماء الجداول مع التصميم المعتمد للفريق.
- مراجعة أسماء الفهارس، بما فيها الفهارس الثانوية، ومقارنتها بالمخطط المتوقع.
- فحص أسماء السمات المستخدمة في الكيانات وتعريفات المفاتيح.
- رفض أي اسم غير متوقع أو غير مقصود، وأي ملف لا يمكن تتبع مصدره أو مراجعته.
- فحص تطبيق CDK المولد وفروق الملفات قبل synth أو deploy، وإبقاء النشر متوقفاً إذا ظهرت تعبيرات لا يفسرها النموذج المعتمد.
يمكن لقائمة سماح بالأسماء المعتمدة ومراجعة التغييرات عبر طلب دمج أن تقللا احتمال مرور مدخل غير مقصود، لكنهما لا تحولان النسخة القديمة إلى نسخة مصححة. وقد تفيد ضوابط عزل خوادم MCP في الحد من صلاحيات العملية والاعتمادات المتاحة لها، بينما تظل معالجة هذه الثغرة مرتبطة بالترقية أو تصحيح الشفرة المشتقة.
ما الذي يظل مطلوباً بعد الترقية؟
المؤكد هو نطاق الإصدارات المتأثرة، ومسار الإدخال عبر أسماء الجداول أو الفهارس أو السمات، ووجود الإصلاح بدءاً من 2.1.6. أما سجل GitHub المستخدم هنا فحالته «غير مراجع»، ولا يسرد حزمة أو نطاق نسخ مصححة في حقوله الخاصة؛ لذلك تبقى نشرة AWS المرجع الأدق لنطاق التأثر، بينما تثبت PyPI توفر ملفات الإصدار وتواريخها.
لا تعرض الصفحات الثلاث دليلاً على استغلال واسع النطاق. مع ذلك، إذا كانت بيئة متأثرة قد ولدت ونشرت تطبيق CDK من ملف مجهول المصدر أو احتوى على أسماء غير متوقعة، فلا تكفي الترقية وحدها لتحديد ما حدث سابقاً؛ يلزم عندئذ مراجعة ملف النموذج، ومخرجات التوليد، وسجلات عملية النشر وفق إجراءات الاستجابة للحوادث لدى الفريق.
اقرأ أيضًا:
اشترك في نشرتنا الإخبارية
احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.