العودة
ثغرة في MCP Python SDK الرسمي تتيح لخوادم ضارة سرقة بيانات OAuth
SiTech AI Team3 წთ. საკითხავი

ثغرة في MCP Python SDK الرسمي تتيح لخوادم ضارة سرقة بيانات OAuth

أظهرت ثغرة أمنية في MCP Python SDK الرسمي إمكانية قيام خادم MCP ضار بإعادة توجيه تسجيل الدخول وسرقة سر العميل ورمز التفويض ومفتاح PKCE. وأُصلحت الثغرة في الإصدارين 1.30.0 و2.2.0.

ما هي الثغرة

يحتوي MCP Python SDK الرسمي على ثغرة أمنية تتيح لخادم MCP ضار أن يخدع تطبيقاً ويدفعه إلى تسليم بيانات OAuth التي يستخدمها لتسجيل الدخول إلى خدمة حقيقية. وقد وصف القائمون على SDK المشكلة في بلاغ أمني نُشر في 28 سبتمبر. وMCP (بروتوكول سياق النموذج) معيار مفتوح لربط تطبيقات الذكاء الاصطناعي بالأدوات والبيانات الخارجية، وهذه الحزمة هي الـ SDK الرسمي له بلغة Python.

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

لماذا يهم ذلك

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

وقد عرضت شركة Cycode، التي أبلغت عن الثغرة، عملية التبادل الكاملة في اختبار وقالت إن الرمز الناتج يحمل كل الأذونات التي مُنحت للتطبيق. وسر العميل طويل الأجل، لذا يظل صالحاً حتى يُغيَّر. وصُنّفت الثغرة عالية بدرجة 7,5 للمزوّدين اللذين يعملان دون حضور شخص، و6,5 للمزوّد التفاعلي. ولم يكن قد أُسند أي معرّف CVE حتى 29 سبتمبر.

من المتأثر

يتأثر التطبيق إذا استخدم SDK كعميل MCP عبر HTTP مع OAuthClientProvider أو ClientCredentialsOAuthProvider أو PrivateKeyJWTOAuthProvider أو المزوّد المهمل RFC7523OAuthClientProvider من الإصدار 1.x، وكان قادراً على الوصول إلى خادم لا يتحكم به بالكامل وهو يحمل بيانات خدمة دخول حقيقية. ولا تتأثر خوادم MCP المبنية بـ SDK، ولا عملاء stdio المحليون، ولا العملاء الذين يستخدمون رموزهم الخاصة.

في خط 1.x تتأثر الإصدارات من 1.9.1 إلى 1.29.1 ويصلحها 1.30.0؛ وفي خط 2.x تتأثر الإصدارات من 2.0.0 إلى 2.1.1 ويصلحها 2.2.0.

ما ينبغي فعله

يجب الترقية إلى 1.30.0 أو 2.2.0. في الإصدارات المصححة يحدد العميل أولاً خدمة الدخول التي يتوقعها، ويرفض أي جهة تشير إلى غيرها.

على التطبيقات التي تستخدم ClientCredentialsOAuthProvider أو PrivateKeyJWTOAuthProvider أن تمرر أيضاً issuer= لتحديد خدمة الدخول التي تنتمي إليها هذه البيانات؛ فمن دون ذلك لا تغيّر الترقية وحدها شيئاً. أما المزوّد المهمل RFC7523OAuthClientProvider فلا يملك خيار issuer=، لذا ينبغي استبداله. وفي الإصدارات الأقدم اتصلوا بخوادم MCP الموثوقة فقط.

ظهرت فحوص issuer في ملاحظات الإصدارين 1.30.0 و2.2.0 في 7 سبتمبر ضمن تغييرات السلوك لا كإصلاح أمني؛ ثم صدر البلاغ في 28 سبتمبر، وهو اليوم نفسه الذي نشرت فيه Cycode تحليلها. ولم يُبلَّغ عن أي هجمات استخدمت الثغرة.

SSiTech

SiTech — تطوير ويب مدعوم بالذكاء الاصطناعي

نبني مواقع سريعة وعصرية وندمج الذكاء الاصطناعي في سير عمل الشركات. لديك مشروع أو سؤال؟ يسعدنا مساعدتك.