كشفت تحذيرات أمنية حديثة عن وجود ثغرة عالية الخطورة في حزمة Python SDK الرسمية الخاصة ببروتوكول Model Context Protocol (MCP)، وهي الثغرة التي قد تسمح لخوادم MCP الخبيثة بسرقة بيانات اعتماد OAuth الحساسة المستخدمة في المصادقة على الخدمات الحقيقية، ما يضع تطبيقات الذكاء الاصطناعي المتصلة بالخدمات الخارجية أمام مخاطر اختراق واسعة النطاق.
ووفقًا للتفاصيل التي نشرها الباحثون الأمنيون، فإن العيب البرمجي يؤثر على عدد من الإصدارات الرسمية من حزمة MCP Python SDK، حيث يمكن لخادم MCP ضار خداع التطبيق وإقناعه بإرسال بيانات اعتماد OAuth إلى جهة يسيطر عليها المهاجم بدلاً من خادم المصادقة الشرعي.
ما هو بروتوكول MCP ولماذا يشكل عنصرًا حيويًا في منظومة الذكاء الاصطناعي؟
يُعد بروتوكول Model Context Protocol المعروف اختصارًا بـ MCP معيارًا مفتوحًا صمم لتمكين تطبيقات الذكاء الاصطناعي من الاتصال بالأدوات الخارجية وقواعد البيانات والخدمات المختلفة بطريقة موحدة. وخلال الأشهر الأخيرة، أصبح MCP أحد المكونات الأساسية في بناء أنظمة الوكلاء الأذكياء وتطبيقات الذكاء الاصطناعي القادرة على التفاعل مع مصادر البيانات الخارجية وتنفيذ المهام بشكل مستقل.
وتُستخدم حزمة Python SDK الرسمية لتطوير عملاء وخوادم MCP، ما يجعلها حجر أساس في عدد متزايد من المشاريع التي تعتمد على الذكاء الاصطناعي التوليدي والأتمتة الذكية.
وتكتسب هذه الثغرة أهمية خاصة لأن استغلالها لا يستهدف التطبيق النهائي فحسب، بل يضرب في صميم آلية المصادقة التي تسمح للتطبيقات بالوصول إلى الخدمات السحابية والأنظمة المؤسسية نيابة عن المستخدمين.
كيف تنجح الخوادم الخبيثة في سرقة بيانات الاعتماد؟
عند محاولة عميل MCP تسجيل الدخول إلى خدمة معينة، فإنه يطلب من الخادم الذي يتصل به معلومات خادم التفويض المسؤول عن المصادقة. لكن الإصدارات المتأثرة من الحزمة لم تكن تتحقق بصورة كافية من صحة المعلومات المستلمة.
ويستغل المهاجم هذه الثغرة عبر تشغيل خادم MCP مزيف يقوم بإرجاع بيانات مضللة تشير إلى خادم مصادقة يتحكم به المهاجم، أو تقديم معلومات تبدو شرعية ظاهريًا بينما يتم توجيه بيانات الاعتماد الحساسة إلى جهة أخرى.
ونتيجة لذلك، يقوم العميل بإرسال ثلاثة عناصر حساسة للغاية إلى خادم المهاجم:
- الرمز السري للعميل Client Secret.
- رمز التفويض Authorization Code.
- مفتاح إثبات PKCE المستخدم لحماية تدفق المصادقة.
وتكمن خطورة الأمر في أن آلية PKCE صممت أساسًا لمنع إعادة استخدام رموز التفويض المسروقة، لكن تسليم مفتاح الإثبات نفسه للمهاجم يؤدي عمليًا إلى تعطيل هذه الطبقة الأمنية بالكامل.
وبمجرد حصول المهاجم على تلك البيانات، يصبح بإمكانه طلب رمز وصول Access Token صالح من خدمة المصادقة الحقيقية، ثم استخدامه للوصول إلى الموارد المصرح بها للتطبيق بنفس الصلاحيات الأصلية الممنوحة له.
وقد أكدت شركة الأمن السيبراني Cycode، التي اكتشفت الثغرة وأبلغت عنها، إمكانية تنفيذ عملية الاستغلال كاملة عمليًا في بيئة اختبارية، ما يثبت أن المخاطر ليست نظرية بل قابلة للتحقق الفعلي.
من هي الجهات والتطبيقات المعرضة للخطر؟
لا تتأثر جميع تطبيقات MCP بهذه المشكلة الأمنية، بل تقتصر المخاطر على التطبيقات التي تستخدم الحزمة الرسمية كعميل MCP عبر بروتوكول HTTP مع بعض مزودي OAuth المحددين.
وتشمل المكونات المتأثرة:
- OAuthClientProvider
- ClientCredentialsOAuthProvider
- PrivateKeyJWTOAuthProvider
- RFC7523OAuthClientProvider القديم ضمن سلسلة الإصدارات 1.x
ويصبح التطبيق معرضًا للخطر إذا كان قادرًا على الاتصال بخوادم MCP لا يملك سيطرة كاملة عليها، بينما يحتفظ في الوقت نفسه ببيانات اعتماد صالحة لخدمات مصادقة حقيقية.
في المقابل، أوضحت التحذيرات الأمنية أن خوادم MCP المبنية باستخدام الحزمة نفسها لا تتأثر بهذه الثغرة، كما أن العملاء المحليين العاملين عبر stdio أو التطبيقات التي تستخدم رموز وصول جاهزة لا تقع ضمن نطاق الاستغلال.
ومن الناحية التقنية، حصلت الثغرة على تقييم خطورة مرتفع بلغ 7.5 نقاط في السيناريوهات التي تعمل فيها عمليات المصادقة بين الأنظمة دون تدخل بشري، بينما انخفض التقييم إلى 6.5 نقاط في حالات المصادقة التفاعلية التي تتطلب موافقة المستخدم على تسجيل الدخول.
الإصدارات المتأثرة وخطوات المعالجة المطلوبة
بحسب التحذير الأمني، تشمل الإصدارات المتأثرة:
- جميع إصدارات سلسلة 1.x من الإصدار 1.9.1 وحتى 1.29.1.
- جميع إصدارات سلسلة 2.x من الإصدار 2.0.0 وحتى 2.1.1.
وقد تم إصلاح المشكلة رسميًا في:
- الإصدار 1.30.0 لسلسلة 1.x.
- الإصدار 2.2.0 لسلسلة 2.x.
ويعتمد الإصلاح الجديد على قيام العميل بتحديد خادم المصادقة المتوقع مسبقًا قبل جلب أي بيانات منه، ثم رفض أي استجابة تشير إلى خادم مختلف.
إلا أن المطورين حذروا من أن الترقية وحدها ليست كافية في بعض الحالات، وتحديدًا عند استخدام ClientCredentialsOAuthProvider أو PrivateKeyJWTOAuthProvider، حيث يجب تمرير قيمة issuer بشكل صريح لتحديد خادم المصادقة المرتبط ببيانات الاعتماد.
كما أوصت الجهات المختصة بحذف تسجيلات عملاء OAuth المخزنة سابقًا بعد الترقية، لأن بعض البيانات القديمة لا تحتوي على ارتباط واضح بخادم المصادقة الشرعي.
وفي حال وجود احتمال بأن التطبيق قد اتصل سابقًا بخادم MCP غير موثوق، ينصح الخبراء بتغيير Client Secret فورًا وإبطال جميع رموز الوصول الصادرة سابقًا من مزود الهوية المستخدم.
ويأتي الكشف عن هذه الثغرة في وقت يشهد فيه بروتوكول MCP اعتمادًا متزايدًا داخل منظومات الذكاء الاصطناعي الحديثة، الأمر الذي يعكس التحديات الأمنية المتنامية المرتبطة بربط نماذج الذكاء الاصطناعي بالخدمات الخارجية. ورغم عدم رصد أي هجمات فعلية استغلت الثغرة حتى الآن، فإن الباحثين يؤكدون أن سرعة تطبيق التحديثات الأمنية تبقى عاملًا حاسمًا لمنع تحول هذا الخلل إلى وسيلة فعالة للاستيلاء على الحسابات وسرقة بيانات الاعتماد الحساسة في بيئات الذكاء الاصطناعي المتقدمة.
