MCP क्रेडेंशियल सीमा: MCP सर्वर को यह क्यों नहीं तय करना चाहिए कि आपके OAuth क्रेडेंशियल कहाँ जाएँ

आधिकारिक MCP Python SDK में मिली एक कमज़ोरी ने एक सरल लेकिन महत्वपूर्ण सिक्योरिटी नियम उजागर कर दिया। किसी क्रेडेंशियल को सुरक्षित रखना काफ़ी नहीं है। क्लाइंट को यह भी पता होना चाहिए कि उसे किस अथॉराइज़ेशन सर्वर तक पहुँचने की इजाज़त है।

कोई क्रेडेंशियल पूरी तरह वैध हो सकता है, फिर भी ग़लत जगह भेजा जा सकता है।

सीक्रेट का अंदाज़ा लगाने की ज़रूरत नहीं पड़ती। एन्क्रिप्शन तोड़ने की ज़रूरत नहीं पड़ती। OAuth फ़्लो भी सामान्य ही दिख सकता है।

यह विफलता इसलिए हो सकती है क्योंकि एक सवाल का जवाब देने के लिए ग़लत सिस्टम पर भरोसा कर लिया गया

यह क्रेडेंशियल कहाँ भेजा जाना चाहिए?

28 सितंबर 2026 को सामने आई एक सिक्योरिटी वल्नरेबिलिटी ने आधिकारिक Model Context Protocol (MCP) Python SDK में ठीक यही समस्या उजागर की। प्रभावित OAuth क्लाइंट कॉन्फ़िगरेशनों में, कोई MCP सर्वर यह प्रभावित कर सकता था कि क्लाइंट के क्रेडेंशियल किस अथॉराइज़ेशन सर्वर तक पहुँचें। यानी कोई दुर्भावनापूर्ण या कॉम्प्रोमाइज़्ड MCP सर्वर संवेदनशील OAuth सामग्री को अपने नियंत्रण वाले एंडपॉइंट की ओर मोड़ सकता था।

तुरंत किया गया फ़िक्स मायने रखता है।

लेकिन इससे ज़्यादा टिकाऊ सबक़ यह है

जो सिस्टम आपसे ऑथेंटिकेट करने को कह रहा है, उसे यह तय करने का भरोसा अपने आप नहीं दिया जाना चाहिए कि आपके क्रेडेंशियल कहाँ पहुँचाए जाएँ।

अतिरिक्त भरोसे का निर्णय कहाँ सामने आता है

एक रिमोट MCP क्लाइंट के किसी सुरक्षित MCP सर्वर से जुड़ने की कल्पना कीजिए।

MCP सर्वर ऐसा मेटाडेटा प्रकाशित कर सकता है जो क्लाइंट को बताता है कि उससे कौन-से अथॉराइज़ेशन सर्वर जुड़े हैं।

यह लचीलापन उपयोगी है। अलग-अलग MCP सर्वर अलग-अलग पहचान सिस्टम इस्तेमाल कर सकते हैं।

लेकिन डिस्कवरी और भरोसा एक जैसी चीज़ें नहीं हैं।

जिस क्लाइंट के पास किसी एक अथॉराइज़ेशन सर्वर के लिए क्रेडेंशियल हैं, उसे सिर्फ़ इसलिए उन्हें कहीं और नहीं भेज देना चाहिए क्योंकि MCP सर्वर वहाँ इशारा कर रहा है।

Python SDK में क्या विफल हुआ

यह कमज़ोरी SDK के OAuth क्लाइंट सपोर्ट में थी।

GitHub एडवाइज़री के मुताबिक़, दो सुरक्षा उपाय अधूरे थे।

• हर डिस्कवरी पथ पर अथॉराइज़ेशन-सर्वर मेटाडेटा के issuer की जाँच नहीं की जाती थी।
• स्टोर किए गए या पहले से रजिस्टर्ड क्लाइंट क्रेडेंशियल लगातार उस अथॉराइज़ेशन सर्वर से बाउंड नहीं रहते थे जिनसे वे संबंधित थे।

इसलिए कोई दुर्भावनापूर्ण या कॉम्प्रोमाइज़्ड MCP सर्वर क्लाइंट को अटैकर के नियंत्रण वाले टोकन एंडपॉइंट की ओर निर्देशित कर सकता था।

OAuth फ़्लो के आधार पर, अटैकर को client_secret, कोई ऑथराइज़ेशन कोड, PKCE code_verifier, या कोई साइन किया गया क्लाइंट असर्शन मिल सकता था।

अटैकर क्रेडेंशियल को हराता नहीं है।

वह उसकी मंज़िल बदल देता है।

यही वजह है कि इसे केवल एक OAuth बग की बजाय एक क्रेडेंशियल-सीमा (boundary) की विफलता के रूप में समझना बेहतर है।

चित्र 1 का सुलभ (accessible) पाठ विकल्प

अपेक्षित फ़्लो: 1. MCP क्लाइंट के पास एक अथॉराइज़ेशन सर्वर के लिए क्रेडेंशियल है। 2. अपेक्षित इशूअर, क्लाइंट को पहले से पता है कि वह किस इशूअर पर भरोसा करता है। 3. अथॉराइज़ेशन सर्वर वैरिफ़ाई किया गया, डिस्कवर किए गए मेटाडेटा की उससे जाँच की जाती है। 4. भरोसेमंद टोकन एंडपॉइंट, पहचान मेल खाने पर ही क्रेडेंशियल भेजा जाता है। टूटा हुआ फ़्लो: 1. MCP क्लाइंट के पास एक अथॉराइज़ेशन सर्वर के लिए क्रेडेंशियल है। 2. MCP सर्वर मंज़िल को प्रभावित करता है, यह विज्ञापित करते हुए कि ऑथराइज़ेशन कहाँ होना चाहिए। 3. क्लाइंट उस मंज़िल को स्वीकार कर लेता है, इशूअर की स्वतंत्र रूप से कभी जाँच नहीं हुई। 4. अटैकर-नियंत्रित एंडपॉइंट, क्रेडेंशियल उजागर हो जाता है, केवल दुरुपयोग नहीं होता।

issuer किसकी सुरक्षा करता है?

OAuth की शब्दावली इसे असल से कहीं ज़्यादा जटिल लगवा सकती है।

इस चर्चा के लिए, issuer एक व्यावहारिक सवाल का जवाब देता है

इस रिश्ते के लिए हम किस अथॉराइज़ेशन सर्वर पर भरोसा करते हैं?

मान लीजिए कोई क्लाइंट सीक्रेट auth.example.com का है।

क्लाइंट फिर एक ऐसे MCP सर्वर से जुड़ता है जो ऑथेंटिकेशन को किसी दूसरे अथॉराइज़ेशन सर्वर की ओर मोड़ने की कोशिश करता है।

वैध दिखने वाला OAuth मेटाडेटा होना ही काफ़ी नहीं होना चाहिए।

क्लाइंट को एक स्वतंत्र अपेक्षा चाहिए जो कहे: यह क्रेडेंशियल इस इशूअर का है।

फ़िक्स किया गया SDK अथॉराइज़ेशन-सर्वर मेटाडेटा को प्रोसेस करने से पहले अपेक्षित इशूअर तय करता है, अलग इशूअर वाले मेटाडेटा को अस्वीकार करता है, और स्टोर की गई रजिस्ट्रेशन को उसी इशूअर से बाँधता है।

जुलाई 2026 का MCP स्पेसिफिकेशन भी इसी सिद्धांत को मज़बूत करता है। पर्सिस्ट किए गए क्लाइंट क्रेडेंशियल उसी अथॉराइज़ेशन सर्वर से जुड़े रहने चाहिए जिनसे वे संबंधित हैं, न कि अथॉराइज़ेशन सर्वर बदलने पर उन्हें दोबारा इस्तेमाल कर लिया जाए।

असल में कौन प्रभावित है?

इस मुद्दे का यह मतलब नहीं है कि हर MCP क्लाइंट या सर्वर असुरक्षित है।

यह एडवाइज़री तभी लागू होती है जब ये दोनों शर्तें सही हों।

1. एप्लिकेशन Python SDK का इस्तेमाल HTTP पर MCP क्लाइंट के रूप में, प्रभावित बिल्ट-इन OAuth प्रोवाइडरों में से किसी एक के साथ करता है।
2. क्लाइंट किसी ऐसे MCP सर्वर से जुड़ सकता है जिस पर उसे पूरा भरोसा नहीं है, जबकि उसके पास किसी वैध अथॉराइज़ेशन सर्वर के क्रेडेंशियल मौजूद हैं।

प्रभावित प्रोवाइडरों में OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, और डिप्रीकेटेड 1.x RFC7523OAuthClientProvider शामिल हैं।

एडवाइज़री साफ़ तौर पर कहती है कि यह मुद्दा SDK से बने MCP सर्वरों, stdio क्लाइंटों, या ऐसे क्लाइंटों को प्रभावित नहीं करता जो प्रभावित OAuth हैंडलरों के बजाय अपने खुद के टोकन या हेडर जोड़ते हैं।

प्रभावित और पैच किए गए MCP Python SDK वर्शन

SDK लाइन	प्रभावित	पैच किया गया
1.x	>=1.9.1, <1.30.0	1.30.0
2.x	>=2.0.0a1, <2.2.0	2.2.0

इसलिए सही निष्कर्ष यह नहीं है कि MCP ऑथेंटिकेशन असुरक्षित है।

सही निष्कर्ष यह है कि एक विशेष OAuth क्लाइंट इम्प्लीमेंटेशन एक अथॉराइज़ेशन-सर्वर ट्रस्ट बाउंड्री बनाए रखने में विफल रहा।

अपग्रेड करना क्यों काफ़ी नहीं हो सकता

प्रभावित वर्शन इस्तेमाल कर रही टीमों को 1.x लाइन पर 1.30.0 या उसके बाद, या 2.x लाइन पर 2.2.0 या उसके बाद अपग्रेड करना चाहिए।

लेकिन एक महत्वपूर्ण कॉन्फ़िगरेशन विवरण है।

ClientCredentialsOAuthProvider या PrivateKeyJWTOAuthProvider इस्तेमाल करने वाले एप्लिकेशनों को अपेक्षित issuer= भी देना होगा।

ऐसा न करने पर, ये प्रोवाइडर अब भी उसी अथॉराइज़ेशन सर्वर का अनुसरण कर सकते हैं जिसे MCP सर्वर विज्ञापित करता है।

इससे एक और उपयोगी सिक्योरिटी सिद्धांत सामने आता है

पैच की गई लाइब्रेरी उस ट्रस्ट रिश्ते का अनुमान नहीं लगा सकती जिसे एप्लिकेशन ने कभी परिभाषित ही नहीं किया।

लाइब्रेरी इशूअर बाइंडिंग लागू करा सकती है।

लेकिन एप्लिकेशन को अब भी यह बताना पड़ता है कि किस इशूअर पर भरोसा किया जाए।

पुरानी रजिस्ट्रेशन अब भी समस्या बन सकती हैं

अपग्रेड करने से आगे का व्यवहार बदलता है। यह अपने आप पहले बनाए गए हर क्रेडेंशियल रिश्ते की मरम्मत नहीं कर देता।

इशूअर जानकारी के बिना स्टोर की गई OAuth रजिस्ट्रेशन अपग्रेड के बाद भी अनबाउंड रह सकती हैं।

इसलिए एप्लिकेशनों को उन रिकॉर्ड्स को हटाकर दोबारा रजिस्टर करना पड़ सकता है, या जहाँ वे ख़ुद पहले से रजिस्टर्ड क्लाइंट जानकारी मैनेज करते हैं वहाँ सही इशूअर जोड़ना पड़ सकता है।

अगर कोई प्रभावित क्लाइंट पहले किसी अविश्वसनीय MCP सर्वर से जुड़ा हो सकता है, तो टीमों को उसके क्लाइंट सीक्रेट को रोटेट करने और संबंधित टोकन को रद्द करने पर भी विचार करना चाहिए।

यह फ़र्क़ महत्वपूर्ण है। सॉफ़्टवेयर को पैच करने का हमेशा यह मतलब नहीं होता कि पिछला एक्सपोज़र भी हट गया।

इशूअर और ऑडियंस अलग-अलग सीमाओं की सुरक्षा करते हैं

MCP का एक और अथॉराइज़ेशन नियंत्रण है जिसे इशूअर बाइंडिंग समझ लेना आसान है।

MCP अथॉराइज़ेशन स्पेसिफिकेशन क्लाइंटों को इच्छित रिसोर्स की पहचान करने और सर्वरों को यह वैरिफ़ाई करने की माँग करता है कि एक्सेस टोकन उसी रिसोर्स के लिए जारी किए गए थे।

यही है ऑडियंस या रिसोर्स बाइंडिंग।

ये दोनों नियंत्रण अलग-अलग चरणों की सुरक्षा करते हैं।

इशूअर बाइंडिंग यह पूछती है: इन क्रेडेंशियल को पाने और मैनेज करने के लिए किस अथॉराइज़ेशन सर्वर पर भरोसा किया जाता है?

ऑडियंस या रिसोर्स बाइंडिंग यह पूछती है: नतीजे में मिलने वाला एक्सेस टोकन किस MCP सर्विस के लिए बनाया गया है?

चित्र 2 का सुलभ (accessible) पाठ विकल्प

छह-चरणों की श्रृंखला: 1. क्लाइंट क्रेडेंशियल, एक सीक्रेट, कोड या साइन किया गया असर्शन। 2. भरोसेमंद इशूअर, वह अथॉराइज़ेशन सर्वर जिसकी क्लाइंट को उम्मीद है। 3. अथॉराइज़ेशन सर्वर, उस भरोसेमंद इशूअर के मुक़ाबले वैरिफ़ाई किया गया। 4. एक्सेस टोकन, इशूअर जाँच सफल होने के बाद जारी किया गया। 5. अपेक्षित रिसोर्स, वह MCP सर्वर जिसे टोकन ऑडियंस के रूप में नाम देता है। 6. MCP सर्वर, टोकन को तभी स्वीकार करता है जब वह नामित ऑडियंस हो। चरण 1 से 3 को इशूअर बाइंडिंग के रूप में समूहित किया गया है। चरण 4 से 6 को ऑडियंस या रिसोर्स बाइंडिंग के रूप में समूहित किया गया है। एक समापन टिप्पणी बताती है कि इशूअर बाइंडिंग यह सुरक्षित करती है कि क्रेडेंशियल कहाँ भेजा जाता है, जबकि ऑडियंस बाइंडिंग यह सुरक्षित करती है कि नतीजे में मिला टोकन कहाँ इस्तेमाल हो सकता है।

एक सरल किया हुआ रिश्ता कुछ इस तरह दिखता है: क्लाइंट क्रेडेंशियल, भरोसेमंद इशूअर, अथॉराइज़ेशन सर्वर, एक्सेस टोकन, अपेक्षित रिसोर्स, MCP सर्वर।

इशूअर बाइंडिंग पहले ट्रस्ट रिश्ते की सुरक्षा करती है।

ऑडियंस बाइंडिंग टोकन के जारी होने के बाद उसकी सुरक्षा करती है।

दोनों ही मायने रखते हैं।

MCP में यह ख़ासतौर पर क्यों महत्वपूर्ण है

MCP क्लाइंट कई सर्वरों से जुड़ सकते हैं और अलग-अलग अथॉराइज़ेशन सिस्टम के साथ इंटरैक्ट कर सकते हैं।

इससे अथॉराइज़ेशन-सर्वर मिक्स-अप के मौक़े बनते हैं। एक रिश्ते से मिले क्रेडेंशियल या अथॉराइज़ेशन रिस्पॉन्स ग़लती से किसी दूसरे रिश्ते में इस्तेमाल हो सकते हैं।

MCP स्पेसिफिकेशन में इस तरह की समस्या के लिए सुरक्षा उपाय शामिल हैं, जिनमें फ़्लो में पहले दर्ज किए गए इशूअर के मुक़ाबले अथॉराइज़ेशन रिस्पॉन्स को वैरिफ़ाई करना, और पर्सिस्ट किए गए क्लाइंट क्रेडेंशियल को सही इशूअर से जोड़े रखना शामिल है।

यह एक बड़े सबक़ को मज़बूत करता है

OAuth सिक्योरिटी सिर्फ़ क्रेडेंशियल को गुप्त रखने के बारे में नहीं है। यह उन रिश्तों को भी बनाए रखने के बारे में है जिनसे ये क्रेडेंशियल जुड़े हैं।

कौन-सा क्लाइंट? कौन-सा अथॉराइज़ेशन सर्वर? कौन-सा रिसोर्स? कौन-सा MCP सर्वर?

कोई क्रेडेंशियल क्रिप्टोग्राफ़िक रूप से वैध हो सकता है, फिर भी ख़तरनाक बन सकता है अगर इनमें से कोई एक रिश्ता बिना स्वतंत्र वैरिफ़िकेशन के बदल जाए।

MCP टीमों को अभी क्या जाँचना चाहिए?

यहाँ जवाब सीमित और केंद्रित रह सकता है।

1. SDK वर्शन जाँचें

प्रभावित इंस्टॉलेशन को 1.x पर 1.30.0 या उसके बाद, या 2.x पर 2.2.0 या उसके बाद ले जाएँ।

2. OAuth प्रोवाइडर की पहचान करें

जाँचें कि क्लाइंट प्रभावित बिल्ट-इन OAuth प्रोवाइडरों में से किसी एक का इस्तेमाल करता है या नहीं।

3. अपेक्षित इशूअर कॉन्फ़िगर करें

ClientCredentialsOAuthProvider और PrivateKeyJWTOAuthProvider के लिए, उस अथॉराइज़ेशन सर्वर को साफ़ तौर पर परिभाषित करें जिससे क्रेडेंशियल संबंधित हैं।

4. स्टोर की गई रजिस्ट्रेशन की समीक्षा करें

ऐसी पुरानी रजिस्ट्रेशन को साफ़ करें या ठीक करें जिनमें इशूअर बाइंडिंग नहीं है।

5. पिछले एक्सपोज़र पर विचार करें

अगर क्लाइंट वल्नरेबल रहते हुए किसी अविश्वसनीय MCP सर्वर से जुड़ा हो सकता है, तो क्रेडेंशियल रोटेशन और टोकन रद्द करने पर विचार करें।

6. टोकन ऑडियंस को अलग से वैरिफ़ाई करें

पुष्टि करें कि एक्सेस टोकन केवल उनके इच्छित MCP रिसोर्स के लिए अनुरोधित और स्वीकृत होते हैं।

सिर्फ़ सीक्रेट की नहीं, रिश्ते की रक्षा करें

यह SDK कमज़ोरी आख़िरकार एक पुरानी एडवाइज़री बन जाएगी।

लेकिन इसके पीछे का सिक्योरिटी सिद्धांत प्रासंगिक बना रहेगा।

आधुनिक सिस्टम सर्विसेज़ को तेज़ी से डायनामिक तरीक़े से खोज रहे हैं। क्लाइंट मेटाडेटा का अनुसरण करते हैं। एजेंट टूल्स से जुड़ते हैं। ऑथेंटिकेशन कई स्वतंत्र कंपोनेंट में से गुज़रता है।

इससे एक सवाल लगातार ज़्यादा ज़रूरी होता जाता है: यह तय करने का अधिकार किसे है कि क्रेडेंशियल कहाँ जाएगा?

इस Python SDK ख़ामी के लिए, जवाब अथॉराइज़ेशन-सर्वर इशूअर बाइंडिंग के ज़रिए लागू किया जाता है।

नतीजे में मिलने वाले एक्सेस टोकन के लिए, MCP अलग से रिसोर्स या ऑडियंस बाइंडिंग की माँग करता है।

इसलिए टिकाऊ सिक्योरिटी नियम सिर्फ़ क्रेडेंशियल की रक्षा करने से कहीं बड़ा है।

क्रेडेंशियल को उस रिश्ते से बाँधें जिससे वह संबंधित है।

कोई सीक्रेट सिर्फ़ इसलिए सुरक्षित नहीं होता क्योंकि उसका कोई अंदाज़ा नहीं लगा सकता।

उसे सही जगह भी पहुँचना ज़रूरी है।

संदर्भ और आगे पढ़ने के लिए

• MCP Python SDK सिक्योरिटी एडवाइज़री GHSA-qx49-fqc8-xw99: GitHub, 28 सितंबर 2026 को प्रकाशित। प्रभावित वर्शन, एक्सप्लॉइट की शर्तों, प्रभावित OAuth प्रोवाइडरों, अप्रभावित कॉन्फ़िगरेशनों, पैच किए गए वर्शन, issuer= दिशा-निर्देश, स्टोर की गई रजिस्ट्रेशन के सुधार और क्रेडेंशियल रोटेशन दिशा-निर्देश के लिए प्राथमिक स्रोत।
• Model Context Protocol: Authorization: मौजूदा MCP अथॉराइज़ेशन स्पेसिफिकेशन, जो अथॉराइज़ेशन-सर्वर डिस्कवरी, रिसोर्स इंडिकेटर, और टोकन वैलिडेशन को कवर करता है।
• Model Context Protocol: Authorization Security Considerations: रिसोर्स और ऑडियंस बाइंडिंग तथा टोकन-वैलिडेशन आवश्यकताओं के लिए प्राथमिक संदर्भ।
• Model Context Protocol: Security Best Practices: मिक्स-अप अटैक, अथॉराइज़ेशन बाउंड्री, टोकन हैंडलिंग, और संबंधित MCP सिक्योरिटी जोखिमों को कवर करने वाला अतिरिक्त मार्गदर्शन।