एमसीपी पाइथन एसडीके (MCP Python SDK) में खामी: सर्वर तय कर सकता था आपका आइडेंटिटी प्रोवाइडर

FACT. SDK का OAuth क्लाइंट (client) समर्थन, mcp.client.auth में, कनेक्ट हो रहे MCP सर्वर को यह तय करने देता था कि क्लाइंट के OAuth क्रेडेंशियल (credentials) कौन-सा ऑथराइजेशन सर्वर (authorization server) प्राप्त करेगा। दो अलग-अलग खामियाँ मिल गईं:

1. ऑथराइजेशन सर्वर मेटाडेटा का issuer हर डिस्कवरी पाथ (discovery path) पर मान्य नहीं किया जाता था।
2. संग्रहीत या पहले से प्रोविज़न किए गए क्लाइंट क्रेडेंशियल उस ऑथराइजेशन सर्वर से बंधे (bound) नहीं थे जिनके वे थे।

FACT. इसलिए कोई दुर्भावनापूर्ण या समझौता-ग्रस्त (compromised) MCP सर्वर क्लाइंट के क्रेडेंशियल अपनी पसंद के टोकन एंडपॉइंट (token endpoint) की ओर भेज सकता था, दो तरीकों से:

• अपने संरक्षित संसाधन मेटाडेटा (protected resource metadata) में अपना ही ऑथराइजेशन सर्वर नाम देकर, या
• कुछ भी प्रकाशित न करके और ऐसा मेटाडेटा परोसकर जो उपयोगकर्ता के असली ऑथराइजेशन सर्वर को issuer के रूप में पेश करता है।

FACT. इसके बाद हमलावर को असली ऑथराइजेशन सर्वर के लिए बने client_secret, ऑथराइजेशन कोड और PKCE code_verifier मिल जाते — या PrivateKeyJWTOAuthProvider के मामले में स्थिर सीक्रेट के बजाय एक हस्ताक्षरित क्लाइंट एसर्शन (signed client assertion) (private_key_jwt क्लाइंट ऑथेंटिकेशन सामग्री)।

FACT. इन तीन मानों के साथ हमलावर उन्हें असली ऑथराइजेशन सर्वर के टोकन एंडपॉइंट पर भुना सकता है और असली एक्सेस टोकन (access token) पा सकता है, जिसमें वे सभी स्कोप (scopes) होंगे जो एप्लिकेशन को दिए गए थे। क्लाइंट सीक्रेट लंबे समय तक टिकता है और रोटेट (rotate) होने तक काम करता रहता है।

FACT — डिस्क्लोज़र टाइमलाइन (disclosure timeline).

INTERPRETATION — 21 दिन का अंतर ही असली स्टोरी है। पैच किया गया कोड 7 सितंबर को प्रोडक्शन रजिस्ट्रियों में था। एडवाइज़री 28 सितंबर तक अस्तित्व में नहीं थी। तीन हफ़्ते तक सुरक्षित संस्करण उपलब्ध था और किसी को, हर ऑटोमेटेड स्कैनर सहित, पता नहीं था कि यह सुरक्षित संस्करण है — क्योंकि चेंजलॉग प्रविष्टि ऐसी शीर्षक-पंक्ति के नीचे बैठी थी जो "behaviour" कहती है।

FACT. 2026-09-28 को मॉडल कॉन्टेक्स्ट प्रोटोकॉल (Model Context Protocol, MCP) के आधिकारिक Python SDK के मेंटेनरों ने GitHub सिक्योरिटी एडवाइज़री (GitHub Security Advisory) GHSA-qx49-fqc8-xw99 प्रकाशित की, जिसका शीर्षक था "OAuth client could send credentials to an authorization server chosen by the MCP server". यह एडवाइज़री modelcontextprotocol/python-sdk रिपॉज़िटरी के Security टैब में प्रकाशित हुई है, और प्रभावित पैकेज PyPI पर mcp है।

FACT. गंभीरता उच्च (High) है, CVSS 3.1 बेस स्कोर 7.5, वेक्टर CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. एडवाइज़री कहती है कि यह रेटिंग "scored for the unattended providers" के लिए है; इंटरैक्टिव OAuthClientProvider के लिए, जहाँ कोई व्यक्ति साइन-इन शुरू करता है, एडवाइज़री 6.5 देती है, वेक्टर CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N के साथ।

FACT. एडवाइज़री का CVE फ़ील्ड "No known CVE" पढ़ता है। कमज़ोरियाँ CWE-345 (Insufficient Verification of Data Authenticity) और CWE-522 (Insufficiently Protected Credentials) के रूप में वर्गीकृत हैं। एडवाइज़री आठ रिपोर्टरों को श्रेय देती है: Aviral2642, AlexMelanFromRingo, Gal3m, mrostamipoor, YuvalElbar6, yuvalelbar, RoniGurvich, mahmoudalbustan1.

FACT. एडवाइज़री GitHub उपयोगकर्ता maxisbey ने प्रकाशित की, दिनांक 28 सितंबर, 2026.

INDEPENDENT EVIDENCE. रिपोर्टिंग सुरक्षा फ़र्म Cycode ने तकनीकी राइट-अप "Cycode Uncovers Account Takeover in MCP Python SDK" शीर्षक से प्रकाशित किया, जिसके लेखक Yuval Elbar हैं, मूल रूप से 2026-09-28 को प्रकाशित और अंतिम बार 2026-09-29 को अपडेट. शोधकर्ता को एडवाइज़री में श्रेय योग्य है: एडवाइज़री की श्रेय-सूची में yuvalelbar और YuvalElbar6 दोनों मौजूद हैं। The Hacker News ने 2026-09-29 को इस पर कवरेज की (Swati Khandelwal) और Forkast ने 2026-09-30 को एक विश्लेषण प्रकाशित किया (Heath Callahan).

INDEPENDENT EVIDENCE — डेटाबेस/रजिस्ट्री स्थिति, सीधे सत्यापित. शोध करते समय मैंने चार स्वतंत्र कमज़ोरी रजिस्ट्रियाँ (vulnerability registries) जांचीं:

FACT — किसी शोषण की रिपोर्ट नहीं। न एडवाइज़री और न Cycode इस खामी का इस्तेमाल करके किसी हमले की रिपोर्ट करते हैं, और न Forkast न ही The Hacker News ऐसा कोई हमला बताते हैं। इसलिए "जंगल में शोषित (exploited in the wild)" के लिए साक्ष्य स्थिति नकारात्मक / अज्ञात है, सकारात्मक नहीं।

"Anthropic का आधिकारिक MCP SDK" वाले फ़्रेमिंग (framing) पर

इस फ़्रेमिंग को सावधानी चाहिए, क्योंकि लोकप्रिय हेडलाइनें और एक विक्रेता (vendor) का राइट-अप इसे ढीले ढंग से इस्तेमाल करते हैं।

• FACT. प्रभावित रिपॉज़िटरी modelcontextprotocol/python-sdk है, जो GitHub संगठन modelcontextprotocol के अंतर्गत प्रकाशित है, किसी Anthropic संगठन के अंतर्गत नहीं।
• FACT. PyPI पर mcp प्रोजेक्ट का Homepage https://modelcontextprotocol.io है, Documentation https://py.sdk.modelcontextprotocol.io/ है, और Issues तथा Repository दोनों modelcontextprotocol/python-sdk की ओर इंगित करते हैं। कोई Anthropic-ब्रांडेड प्रोजेक्ट URL नहीं है।
• COMPANY CLAIM. Forkast की हेडलाइन है "Anthropic's Official MCP Python SDK Had an OAuth Credential-Stealing Flaw…". Forkast का अपना बॉडी टेक्स्ट ज़्यादा सतर्क है: "The official Python SDK for the Model Context Protocol."
• COMPANY CLAIM. Cycode अपने बॉडी टेक्स्ट में "Anthropic's MCP Python SDK" लिखता है और कहता है "We reported this to Anthropic's MCP team through their security process."
• INDEPENDENT EVIDENCE. Cycode बताता है कि MCP "is an open standard introduced by Anthropic and donated to the Linux Foundation's Agentic AI Foundation (AAF), which maintains it."
• INTERPRETATION. "Anthropic's SDK" उस प्रोटोकॉल के संदर्भ SDK का शॉर्टहैंड है जिसे Anthropic ने बनाया, साथ में उस व्यावहारिक सच्चाई का भी, कि डिस्क्लोज़र Anthropic से शुरू हुई MCP सुरक्षा प्रक्रिया से होकर गया। इसे Anthropic का कॉर्पोरेट उत्पाद, Anthropic द्वारा मेंटेन की गई रिपॉज़िटरी या Anthropic का बग कहना सही नहीं है। जिन मेंटेनरों ने इसे ठीक किया और एडवाइज़री प्रकाशित की, वे MCP Python SDK के मेंटेनर हैं। रिपोर्टिंग में "आधिकारिक MCP Python SDK (mcp)" का इस्तेमाल होना चाहिए और श्रेय सही तरीके से दिया जाना चाहिए।

FACT — मशीन-पठनीय (machine-readable) प्रभावित रेंज, जैसा एडवाइज़री में प्रकाशित:

• >= 1.9.1, < 1.30.0 — 1.30.0 में पैच किया गया
• >= 2.0.0a1, < 2.2.0 — 2.2.0 में पैच किया गया

FACT — वर्णनात्मक रेंज (narrative ranges), जैसा एडवाइज़री और Cycode के राइट-अप में कहा गया:

• 1.9.1 से 1.29.1 तक: "no issuer check and no credential binding on any path. The entire flow is open."
• 2.0.0 से 2.1.1 तक: "both missing whenever the server publishes no protected resource metadata (the legacy fallback) or answers 403 insufficient_scope."
• दोनों लाइनें, हर पाथ पर: ClientCredentialsOAuthProvider और PrivateKeyJWTOAuthProvider के पास "had no way to name the authorization server their credentials belong to."

FACT — अंतर पर सटीकता का नोट। 2.x लाइन एकसमान रूप से कमज़ोर नहीं थी। v2.2.0 के रिलीज़ नोट्स कहते हैं कि संरक्षित-संसाधन-मेटाडेटा पाथ "has done this since 2.0". यानी 2.0.0–2.1.1 आंशिक रूप से हार्डन किए गए थे: ऐसा सहयोगी MCP सर्वर जो गलत issuer के साथ संरक्षित संसाधन मेटाडेटा प्रकाशित करता, पहले ही अस्वीकार हो जाता था। 2.x पर जो अब भी टूटा था वह था (a) लेगेसी फ़ॉलबैक पाथ और (b) 403 insufficient_scope स्टेप-अप पाथ — ठीक वही दो पाथ जो हमलावर चुनता है। और मशीन-पठनीय रेंज >= 2.0.0a1 में 2.0.0 के अल्फा बिल्ड भी शामिल हैं, जिन्हें वर्णनात्मक "2.0.0 से 2.1.1 तक" स्पष्ट नहीं करता।

FACT — क्या 1.30.0 बैकपोर्ट लाइन है? हाँ। v1.30.0 के रिलीज़ नोट्स इस तरह खुलते हैं: "Maintenance release of the 1.x line. 2.x is the current line; 1.x docs are at https://py.sdk.modelcontextprotocol.io/v1/." फ़िक्स PR एक-दूसरे के प्रतिबिंब हैं: 2.x पर #3398 ("Validate the authorization server metadata issuer on every discovery path") और 1.x पर #3431 ("[v1.x] Validate the authorization server metadata issuer on every discovery path"). PyPI पर 2026 भर 1.x और 2.x रिलीज़ एक-दूसरे के बीच आते दिखते हैं (कुल 73 रिलीज़), इसलिए 1.x वास्तव में मेंटेन की जाने वाली रखरखाव शाखा है, परित्यक्त नहीं।

FACT — फ़िक्स किए गए संस्करण असल में क्या करते हैं। एडवाइज़री के अनुसार, फ़िक्स किया गया क्लाइंट यह भी करता है:

• हर पाथ पर, कोई भी ऑथराइजेशन सर्वर मेटाडेटा लाने से पहले तय करता है कि वह किस issuer की अपेक्षा करता है;
• ऐसा मेटाडेटा अस्वीकार करता है जिसका issuer अलग हो, और OAuthFlowError उठाता है;
• संग्रहीत रजिस्ट्रेशन को उस issuer से बांधता है, और किसी अलग issuer से बंधे रिकॉर्ड को रद्द कर देता है ताकि क्लाइंट फिर से रजिस्टर करे।

v1.30.0 और v2.2.0 के रिलीज़ नोट्स के अनुसार, दोनों यह भी करते हैं: संरक्षित संसाधन मेटाडेटा से 5xx/429 आने पर लेगेसी एंडपॉइंट पर फ़ॉलबैक करने के बजाय अस्वीकार करते हैं; दोबारा कोशिश करने के बजाय कॉलर को गैर-insufficient_scope 403 लौटाते हैं; और HTTP रीडायरेक्ट (redirects) केवल एंडपॉइंट के अपने ओरिजिन (origin) के भीतर फ़ॉलो करते हैं (1.x पर #3448, 2.x पर #3397, कमिट c6762e82).

FACT — नया व्यवहार opt-in और चेतावनी-आधारित है, लागू (enforced) नहीं। दोनों रिलीज़ नोट्स एक नई डेप्रिकेशन चेतावनी (deprecation warning) जोड़ते हैं: ClientCredentialsOAuthProvider / PrivateKeyJWTOAuthProvider issuer= के बिना। एडवाइज़री कहती है कि एडवाइज़री-चेतावनी वाली यह स्थिति "becomes required in 3.0", और 1.30.0 पर यह एक DeprecationWarning है, जिसे Python डिफ़ॉल्ट रूप से छिपा देता है।

FACT — डेप्रिकेटेड 1.x प्रोवाइडर एक बंद रास्ता है। RFC7523OAuthClientProvider में "has no issuer option". एडवाइज़री टीमों को निर्देश देती है कि वे बाक़ी दो प्रोवाइडरों में से किसी एक पर चली जाएँ। अलग से, कमिट इतिहास दिखाता है कि RFC7523OAuthClientProvider को 2026-07-25 को मुख्य लाइन से हटा दिया गया था (7163d826, PR #3169), जो एडवाइज़री के इसे "1.x" प्रोवाइडर बताने से मेल खाता है।

पहले

SDK के OAuth प्रोवाइडरों का उपयोग करने वाला MCP क्लाइंट ऑथराइजेशन-सर्वर डिस्कवरी करता था और फिर परिणाम पर भरोसा करता था। issuer-वैलिडेशन हेल्पर मौजूद था। क्रेडेंशियल-बाइंडिंग लेबल मौजूद था। Audience प्रतिबंध मौजूद था। लेकिन तीनों एक ही इनपुट खाते थे, और लेगेसी फ़ॉलबैक पाथ पर वह इनपुट कभी बना ही नहीं, इसलिए:

if self.context.auth_server_url is not None:
    validate_metadata_issuer(asm, self.context.auth_server_url)

जब auth_server_url None था — क्योंकि सर्वर ने डिस्कवरी अनुरोध का जवाब 404 से दिया — तो गार्ड शॉर्ट-सर्किट हो गया और जांच चली ही नहीं। वह fail closed नहीं हुई। वह बस कभी निष्पादित ही नहीं हुई।

बदलाव

Cycode का प्रस्तावित मूल फ़िक्स जांच चलने से पहले एक मान का अस्तित्व ज़रूरी कर देता है, ताकि हमलावर की पहुँच में कोई "अनुपस्थित" केस न रहे:

expected = self.context.auth_server_url or self.context.get_authorization_base_url(url)
validate_metadata_issuer(asm, expected)

यह फ़िक्स क्रेडेंशियल बाइंडिंग को हमलावर-आपूर्ति डेटा से स्वतंत्र भी बनाता है, और उन पाथों पर ऑथराइजेशन कोड पर audience लगाता है जहाँ पहले ऐसा नहीं होता था।

बाद में

• ऐसा मेटाडेटा जिसका issuer अपेक्षित नहीं है, OAuthFlowError: Authorization server metadata issuer mismatch के साथ अस्वीकार हो जाता है।
• संग्रहीत क्लाइंट रजिस्ट्रेशन पर issuer लेबल होता है; किसी अलग issuer से बंधा रजिस्ट्रेशन रद्द हो जाता है और क्लाइंट फिर से रजिस्टर करता है।
• लेगेसी-फ़ॉलबैक और स्टेप-अप पाथ कवर होते हैं, जिससे 2.0.0 में बचे दो छेद बंद हो जाते हैं।
• रीडायरेक्ट केवल एंडपॉइंट के अपने ओरिजिन तक सीमित रहते हैं।
• issuer= दोनों मशीन-टू-मशीन प्रोवाइडरों पर मौजूद है, अनुपस्थित होने पर चेतावनी आती है, और 3.0 में अनिवार्य हो जाता है।
• अपग्रेड से पहले सहेजे गए रजिस्टर्ड क्लाइंट अनबाउंड (unbound) रह जाते हैं और उन्हें एक बार हाथ से साफ़ करना पड़ता है।

FACT — इच्छित, सुरक्षित डिस्कवरी क्रम (RFC 8414 / RFC 9728 शैली, जैसा लागू है):

1. MCP क्लाइंट MCP सर्वर से पूछता है "तुम्हारे लॉगिन कौन संभालता है?" सर्वर संरक्षित संसाधन मेटाडेटा (protected resource metadata) के साथ जवाब देता है, जो एक ऑथराइजेशन सर्वर URL (auth_server_url) की ओर इंगित करता है।
2. SDK उस ऑथराइजेशन सर्वर का कॉन्फ़िगरेशन मेटाडेटा (/.well-known/oauth-authorization-server) लाता है।
3. SDK जांचता है कि कॉन्फ़िगरेशन का issuer फ़ील्ड — लॉगिन प्रोवाइडर की खुद घोषित पहचान — उस URL से मेल खाता है जो स्टेप 1 में स्वतंत्र रूप से मिला था। ऐसा दुर्भावनापूर्ण सर्वर जो अपने लॉगिन प्रोवाइडर के बारे में झूठ बोलता है, यहीं पकड़ा जाता है।

FACT — फ़ॉलबैक पाथ (लेगेसी). अगर स्टेप 1 विफल हो (MCP सर्वर 404 लौटाता है), तो SDK खुद MCP सर्वर से सीधे लॉगिन कॉन्फ़िगरेशन मांगता है। उस पाथ पर auth_server_url None होता है, इसलिए स्टेप-3 का गार्ड नहीं चलता।

FACT — हमलावर झूठ से दूसरे नियंत्रण को कैसे संतुष्ट करता है। SDK की क्रेडेंशियल-बाइंडिंग जांच संग्रहीत क्रेडेंशियल पर लगे issuer लेबल की तुलना oauth_metadata.issuer से करती है — ठीक उसी फ़ील्ड से जिसे हमलावर नियंत्रित करता है, क्योंकि पहली जांच कभी चली ही नहीं। हमलावर बस issuer को पीड़ित के असली पहचान प्रदाता (identity provider) का नाम सेट कर देता है (Google, Okta, Azure AD). बाइंडिंग जांच पूछती है "क्या ये क्रेडेंशियल इस लॉगिन प्रोवाइडर के हैं?" और उसे हाँ कह दिया जाता है।

FACT — तीसरा नियंत्रण भी इसी वजह से विफल होता है। Audience बाइंडिंग ऑथराइजेशन कोड पर "केवल सर्वर X पर मान्य" मोहर लगाती है। SDK यह मोहर केवल आधुनिक डिस्कवरी पाथ पर लगाता है। थोपे गए फ़ॉलबैक पाथ पर कोई audience मोहर नहीं होती, इसलिए ऑथराइजेशन कोड कहीं भी काम करता है।

FACT — यह व्यवहार में शोषण-योग्य क्यों है, सैद्धांतिक क्यों नहीं। हमलावर का कॉन्फ़िगरेशन authorization_endpoint को असली पहचान प्रदाता पर सेट करता है। उपयोगकर्ता को असली URL पर, असली TLS सर्टिफ़िकेट के साथ, असली Google / Okta / Azure AD लॉगिन पेज पर भेजा जाता है। कोई फ़िशिंग पेज नहीं है और ध्यान देने जैसी कोई बात नहीं। मंज़ूरी के बाद रीडायरेक्ट ऑथराइजेशन कोड क्लाइंट को लौटा देता है; फिर SDK हमलावर के मेटाडेटा से मिले token_endpoint पर code + client_secret + code_verifier POST करता है। हमलावर वही बंडल असली प्रोवाइडर के टोकन एंडपॉइंट पर दोबारा चलाता है और वैध एक्सेस टोकन पा लेता है।

INDEPENDENT EVIDENCE — Cycode का तीन-कॉन्फ़िगरेशन प्रमाण। Cycode ने तीन परीक्षण कॉन्फ़िगरेशन बनाए ताकि अलग किया जा सके कि कौन-सा नियंत्रण मायने रखता है:

नियंत्रण (Control) वाला केस निर्णायक है: वही हमला, बस अंतर यह कि सर्वर ने डिस्कवरी अनुरोध का जवाब भी दिया। यही एक अंतर issuer जांच को चलवाता है, असंगति पकड़ी जाती है, और कोई भी क्रेडेंशियल भेजे जाने से पहले फ़्लो रुक जाता है। एस्केप (Escape) केस में हमलावर अपना नाम देकर issuer जांच पास कर लेता है, लेकिन तब डिस्कवर किया गया URL हमलावर के अपने ओरिजिन की ओर इंगित करता है, जो पीड़ित के संग्रहीत क्रेडेंशियल पर लगे issuer लेबल से मेल नहीं खाता — इसलिए बाइंडिंग जांच उन क्रेडेंशियल को रद्द कर देती है और नया रजिस्ट्रेशन ज़रूरी कर देती है, जिससे हमलावर के पास एक फेंकने योग्य पहचान बचती है जिसका पीड़ित के असली प्रोवाइडर पर कोई दर्जा नहीं।

FACT. Cycode कहता है कि प्रूफ़ ऑफ़ कॉन्सेप्ट (proof of concept) "does this against a real authorization server with PKCE enforcement" और पूरी चेन शुरू से अंत तक प्रदर्शित की गई, जिसमें takeover की पुष्टि के लिए userinfo एंडपॉइंट कॉल करना भी शामिल है।

FACT. MCP वह इंटीग्रेशन परत (integration layer) है जिससे होकर एआई एप्लिकेशन बाहरी टूल और डेटा तक पहुँचते हैं। यह खामी उस परत के क्लाइंट आधे हिस्से में है — वह आधा जिसे एंटरप्राइज़ अपनी ही ट्रस्ट बाउंड्री (trust boundary) के भीतर तैनात करते हैं, अपने ही कॉर्पोरेट क्रेडेंशियल रखते हुए।

INTERPRETATION. संरचनात्मक समस्या यह है कि एजेंट स्टैक में "मुझे किस सर्वर से बात करने की अनुमति है" और "मेरे क्रेडेंशियल किस पहचान प्रदाता के हैं" — दोनों को एक ही अविश्वसनीय इनपुट में मिला दिया जाता है। ऐसा प्रोटोकॉल जो किसी अविश्वसनीय पक्षकार को आपका ही पहचान प्रदाता नामित करने देता है, और साथ ही उस झूठ को पकड़ने वाली वैलिडेशन छोड़ देता है, एक पूरा क्रेडेंशियल-इंटरसेप्शन प्रिमिटिव (credential-interception primitive) है, महज़ एक बग श्रेणी नहीं। असली लॉगिन पेज पर एक मंज़ूर क्लिक वैध एक्सेस टोकन और दोबारा इस्तेमाल होने योग्य क्लाइंट सीक्रेट दे देता है।

FACT. बिना-निगरानी वाले (unattended) प्रोवाइडर गंभीर मामला हैं। ClientCredentialsOAuthProvider और PrivateKeyJWTOAuthProvider बिना लॉगिन पेज, बिना किसी व्यक्ति की मौजूदगी के मशीन-टू-मशीन चलते हैं — इसीलिए UI:N के साथ 7.5. इनमें उपयोगकर्ता-इंटरैक्शन वाला शमन (mitigation) बिल्कुल मौजूद नहीं है।

INTERPRETATION — ट्रस्ट-बाउंड्री का उलटाव। पारंपरिक सप्लाई-चेन जोखिम है जो कोड आप इंस्टॉल करते हैं वह आपके विशेषाधिकारों से चले। यहाँ जोखिम है जिस सर्वर से आप रनटाइम पर जुड़ते हैं वह कनेक्ट करने वाले क्लाइंट से क्रेडेंशियल निकाल ले। हमले की सतह नेटवर्क और एजेंट का अपना टूल-चयन है, बिल्ड पाइपलाइन नहीं।

FACT — पीड़ित और मॉनिटरिंग, दोनों के लिए चुपचाप। Cycode और Forkast दोनों नोट करते हैं कि कोई लॉगिन-प्रॉम्प्ट विसंगति नहीं, कोई विफल लॉगिन नहीं, कोई MFA चुनौती नहीं, कोई संदिग्ध-IP अलर्ट नहीं। ऑथराइजेशन सर्वर की नज़र में यह अदला-बदली वैध है: सही क्लाइंट सीक्रेट, वैध कोड, वैध PKCE वेरिफ़ायर।

FACT — प्रिमिटिव के सीधे नतीजे:

• उस पहचान का पूरा OAuth अकाउंट टेकओवर (account takeover) जिसके लिए MCP क्लाइंट काम कर रहा था, Cycode द्वारा शुरू से अंत तक प्रदर्शित।
• लंबी उम्र के क्लाइंट सीक्रेट की चोरी, जिससे पीड़ित से स्वतंत्र रहकर मनचाहे नए टोकन बनाए जा सकते हैं।
• हस्ताक्षरित क्लाइंट एसर्शन (private_key_jwt) की चोरी, यानी खुद ऑथेंटिकेशन सामग्री, PrivateKeyJWTOAuthProvider के मामले में।
• रीफ़्रेश टोकन (refresh tokens) के ज़रिए अनिश्चितकालीन टिकाऊपन, अगर ऑथराइजेशन सर्वर वे जारी करता है।
• हर उस डाउनस्ट्रीम सेवा तक लेटरल मूवमेंट (lateral movement) जहाँ तक चोरी हुआ OAuth क्लाइंट पहुँचने के लिए अधिकृत है।

INTERPRETATION — वे हमला-मार्ग जो उपयोगकर्ता-इंटरैक्शन वाली शर्त को पूरी तरह हटा देते हैं। Cycode तर्क देता है कि 6.5 का "requires user interaction" स्कोर जोखिम को कम आँकता है, क्योंकि वह इंटरैक्शन असली लॉगिन पेज को मंज़ूर करना है — वही एक काम जो उपयोगकर्ता बिना झिझक करना सीखे हुए हैं। फिर Cycode तीन मार्ग बताता है जहाँ वह चुनाव भी असल में उपयोगकर्ता का नहीं होता:

• रजिस्ट्री / कैटलॉग ज़हरीला करना (poisoning). कोई टाइपोस्क्वॉटेड (typosquatted) या समझौता-ग्रस्त MCP सर्वर डायरेक्टरी प्रविष्टि हमलावर के सर्वर की ओर इंगित करती है। उपयोगकर्ता उसे ऐसी सूची से चुनता है जो क्यूरेटेड लगती है।
• एजेंटिक वर्कफ़्लो (Agentic Workflow) में प्रॉम्प्ट इंजेक्शन (Prompt Injection). जहाँ एजेंट उपयोगकर्ता की ओर से MCP सर्वर चुनता और कनेक्ट करता है, वहाँ चेन के किसी भी टूल से आया प्रॉम्प्ट इंजेक्शन उसे हमलावर के सर्वर की ओर मोड़ सकता है। उपयोगकर्ता ने सर्वर कभी चुना ही नहीं, और अगर फ़्रेमवर्क लॉगिन फ़्लो अपने-आप दिखाता या अपने-आप मंज़ूर करता है, तो मानवीय बाधा घुल जाती है।
• DNS हाईजैक या आंतरिक समझौता। अगर हमलावर नियंत्रित करता है कि कोई वैध सर्वर नाम कहाँ रिज़ॉल्व होता है, तो क्लाइंट यह मानकर जुड़ता है कि वह किसी भरोसेमंद सर्वर से बात कर रहा है, और लॉगिन फ़्लो अपने-आप शुरू हो जाता है।

INTERPRETATION. प्रॉम्प्ट-इंजेक्शन मार्ग ही एआई-एजेंट युग का ख़ास मार्ग है। यह एक नेटवर्क-सुरक्षा बग को मॉडल-व्यवहार की कमज़ोरी में बदल देता है, जिसमें लूप में कोई उपयोगकर्ता ही नहीं होता — जोखिम की वही श्रेणी जो टूल-पॉइज़निंग और कन्फ़्यूज़्ड-डेपुटी (confused-deputy) हमलों की है, लेकिन पेलोड के रूप में डेटा एक्सफ़िल्ट्रेशन के बजाय क्रेडेंशियल चोरी।

INTERPRETATION — एस्केलेशन का रास्ता। अकाउंट टेकओवर पैर जमाने की जगह है। इसे बदतर वह सब बनाता है जो बाद में पहुँच में आता है, और एंटरप्राइज़ में एक ही OAuth क्लाइंट अक्सर कई डाउनस्ट्रीम सेवाओं के लिए अधिकृत होता है — क्लाउड API, आंतरिक टूल, डेटा स्टोर। एक चोरी हुआ सीक्रेट पूरे संगठन में दरवाज़े खोल देता है।

FACT — पाँच-परत बचाव, जिनमें से तीन परतें बायपास हुईं। एडवाइज़री और Cycode मिलकर चार अलग-अलग नियंत्रण पहचानते हैं, सब कोड में मौजूद, सबको वही असत्यापित इनपुट मिला:

FACT — सामान्य बग पैटर्न है: हमलावर-नियंत्रित अनुपस्थिति पर fail-open। Cycode की व्याख्या: "a safety check that only runs when certain data is present, where the attacker controls whether that data is present. Skip the check, and the unchecked value doesn't just go unverified — it flows into the next safety check as trusted input and actively satisfies it." यह डिज़ाइन-स्तर का सबक है, कार्यान्वयन की चूक नहीं: सभी नियंत्रण मौजूद थे, और उनमें से हर एक ने कहा "looks good".

FACT — CWE मैपिंग। CWE-345 (Insufficient Verification of Data Authenticity) असत्यापित issuer को पकड़ता है। CWE-522 (Insufficiently Protected Credentials) क्रेडेंशियल हैंडलिंग के नतीजे को पकड़ता है।

FACT — CVSS वेक्टर में I:N स्कोपिंग की उपज है, read-only प्रभाव का दावा नहीं। वेक्टर कमज़ोर घटक पर प्रभाव आँकता है, उन तीसरे-पक्ष की सेवाओं पर नहीं जहाँ चोरी हुआ टोकन बाद में पहुँचता है। Cycode का अपना विश्लेषण — चोरी हुआ टोकन "whatever scopes the client was originally granted" ले जाता है, संभवतः "read and write access to user data, access to internal APIs, admin operations" — गंतव्य सेवा पर integrity प्रभाव बताता है।

FACT — नीचे MCP स्पेसिफ़िकेशन (specification) का काम। src/mcp/client/auth/oauth2.py का कमिट इतिहास आसपास की सुरक्षा संरचना दिखाता है: SEP-2352 (क्लाइंट क्रेडेंशियल बाइंडिंग, PR #2933, 2026-06-20), SEP-2468 / RFC 9207 (iss ऑथराइजेशन-प्रतिक्रिया वैलिडेशन, PR #2921, 2026-06-20), SEP-2350 (स्टेप-अप पुनः-ऑथराइजेशन, PR #2931), साथ में "restore same-origin issuer binding" फ़िक्स PR #2946 में और रीडायरेक्ट सीमित करने के लिए PR #3397. यह कमज़ोरी इन अलग-अलग लगाए गए हार्डनिंग प्रयासों के बीच की सीवन (seam) पर रहती थी।

FACT — एक संबंधित हार्डनिंग PR अब भी खुला है। PR #3263 — "fix(client/auth): discover AS metadata before cold-start token refresh, with issuer-binding check" — 2026-08-07 को खोला गया था और शोध के समय तक खुला था। यह संकेत है कि OAuth क्लाइंट में टोकन-रीफ़्रेश पाथ पर सितंबर के फ़िक्स के बाद भी हार्डनिंग होती रही।

FACT — कौन प्रभावित है। आप प्रभावित हैं अगर दोनों सही हों:

1. आपका एप्लिकेशन SDK को MCP क्लाइंट के रूप में HTTP पर OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, या डेप्रिकेटेड 1.x RFC7523OAuthClientProvider को ट्रांसपोर्ट के auth हैंडलर के रूप में इस्तेमाल करता है; और
2. वह ऐसे MCP सर्वर से जुड़ सकता है जिस पर आप पूरा भरोसा नहीं करते, जबकि उसके पास किसी वैध ऑथराइजेशन सर्वर के क्रेडेंशियल हैं।

FACT — कौन प्रभावित नहीं है: SDK से बने MCP सर्वर; stdio (लोकल) क्लाइंट; वे क्लाइंट जो अपने टोकन या हेडर खुद जोड़ते हैं।

FACT — अपग्रेड-और-पिन का सटीक क्रम:

1. अपग्रेड करें mcp 1.30.0 पर (1.x लाइन) या 2.2.0 पर (2.x लाइन) या उससे आगे।
2. अगर आप ClientCredentialsOAuthProvider या PrivateKeyJWTOAuthProvider इस्तेमाल करते हैं, तो issuer= पास करें। एडवाइज़री का शब्द स्पष्ट है: "upgrading changes nothing until you also pass issuer=" (उदाहरण issuer="https://auth.example.com"). इसके बिना "they still follow whichever authorization server the MCP server advertises."
3. चेतावनी पर भरोसा मत कीजिए कि वह आपको बता देगी। 1.30.0 पर गुम-issuer सूचना एक DeprecationWarning है, और Python __main__ के बाहर DeprecationWarning डिफ़ॉल्ट रूप से छिपाता है। जो CI चेतावनियों को त्रुटि मानता है वह इसे पकड़ लेगा; सामान्य प्रोडक्शन रन नहीं पकड़ेगा।
4. RFC7523OAuthClientProvider छोड़ दें। इसमें issuer= विकल्प बिल्कुल नहीं है। issuer= सेट करके ClientCredentialsOAuthProvider या PrivateKeyJWTOAuthProvider पर जाएँ।
5. संग्रहीत OAuth क्लाइंट जानकारी एक बार साफ़ करें। issuer के बिना सहेजा गया रजिस्ट्रेशन अनबाउंड रहता है — इसमें "includes everything 1.x stored before 1.30.0" शामिल है। अगर आपने खुद कोई पहले से रजिस्टर्ड क्लाइंट स्टोरेज में रखा था, तो उस रिकॉर्ड पर issuer सेट करें।
6. अगर आप पहले ही उजागर हो चुके हो सकते हैं: ऑथराइजेशन सर्वर पर क्लाइंट सीक्रेट रोटेट करें और टोकन रद्द (revoke) करें। अकेले टोकन रद्द करना अपर्याप्त है अगर सीक्रेट खुद रोटेट न हो, क्योंकि सीक्रेट ही नए टोकन बनाता है।

FACT — अपग्रेड-पूर्व स्थिति। प्रभावित संस्करणों पर "there is no workaround other than connecting OAuth-enabled clients only to MCP servers you trust."

INTERPRETATION — डेवलपर के लिए व्यावहारिक सार। यहाँ SDK अपग्रेड कोई सुरक्षा नियंत्रण नहीं है। नियंत्रण issuer= पिन है, और वह opt-in है, ऐसी डिफ़ॉल्ट-बंद चेतावनी के साथ जिसे Python दबा देता है। जिन टीमों ने "Behaviour changes" के नीचे रिलीज़ नोट पढ़ा, अपग्रेड किया, और issuer= सेट नहीं किया, वे दोनों मशीन-टू-मशीन प्रोवाइडरों पर अब भी कमज़ोर हैं, और उन्हें बताने वाला कोई रनटाइम संकेत नहीं है।

FACT — एक्सपोज़र मानक टूलिंग के लिए अदृश्य है। मैंने यह सीधे खंड 1 की रजिस्ट्रियों के सामने सत्यापित किया:

• कोई CVE नहीं। कोई NVD रिकॉर्ड नहीं (कीवर्ड खोज ने 0 परिणाम लौटाए)।
• वैश्विक GitHub Advisory Database में नहीं। github.com/advisories/GHSA-qx49-fqc8-xw99 404 लौटाता है, जबकि उसी URL पैटर्न पर एक नियंत्रण GHSA 200 लौटाता है।
• OSV.dev में नहीं। 404, कोई alias नहीं।
• CISA KEV में नहीं। 2026-10-02 के 1,733 कमज़ोरियों वाले कैटलॉग में कोई प्रविष्टि नहीं — और CVE ID के बिना कोई संभव भी नहीं।
• फ़िक्स एडवाइज़री से 21 दिन पहले शिप हुआ, "Behaviour changes" पढ़ने वाली चेंजलॉग शीर्षक-पंक्ति के नीचे, और फ़िक्स PR 2026-09-02 को मर्ज हुए।

INTERPRETATION. यही इस स्टोरी का एंटरप्राइज़ सबक है। CVE फ़ीड, SCA/SBOM टूलिंग या कमज़ोरी-चालित SLA से चलने वाली कोई भी पैच-मैनेजमेंट प्रक्रिया इसे सामने नहीं लाती। mcp फ़्लैग नहीं हुआ; mcp 1.30.0 और 2.2.0 फ़्लैग नहीं हुए; चेंजलॉग प्रविष्टि एक compatibility नोट की तरह पढ़ी गई। सही एंटरप्राइज़ रुख यह है कि एआई/एजेंट SDK में GHSA ID और अपस्ट्रीम सुरक्षा एडवाइज़री को प्रथम-श्रेणी की ट्रैकिंग फ़ीड माना जाए, CVE डेटा का व्युत्पन्न नहीं।

INTERPRETATION — CVSS का स्कोप उलटाव। "High, कोई कोड एग्ज़िक्यूशन नहीं, केवल गोपनीयता" वाला स्कोर किसी बड़े सुरक्षा संगठन के भीतर टिकट को एस्केलेट करने की संभावना कम रखता है। यह उसे कम आँकता है, क्योंकि CVSS का स्कोप SDK है। नतीजा पहचान प्रदाता और हर उस डाउनस्ट्रीम सेवा पर पड़ता है जहाँ चोरी हुआ टोकन पहुँच सकता है — क्लाउड अकाउंट, आंतरिक API, CI/CD, डेटा स्टोर।

FACT — पहचान का ब्लास्ट रेडियस (blast radius). Cycode: हमलावर जो एक्सेस टोकन बनाता है वह "carries whatever scopes the client was originally granted" ले जाता है; एंटरप्राइज़ वातावरण में "a single OAuth client often has access to multiple downstream services, so one stolen secret opens doors across the organization"; और "an attacker with a valid access token can reach any service the victim's client was authorized to talk to… storage buckets, databases, deployment pipelines, or other MCP servers the victim is trusted by."

FACT — पहचान (detection) ही कठिन समस्या है। कोई विफल लॉगिन नहीं, कोई संदिग्ध IP नहीं, कोई MFA चुनौती नहीं। ऑथराइजेशन सर्वर पर हमलावर की अदला-बदली वैध से अलग पहचानी नहीं जा सकती।

INTERPRETATION — गवर्नेंस का सवाल। अगर एजेंट उपयोगकर्ता की ओर से MCP सर्वर चुन और जोड़ सकते हैं, तो एजेंट का टूल-चयन निर्णय एक सुरक्षा निर्णय बन जाता है, और प्रॉम्प्ट इंजेक्शन क्रेडेंशियल-चोरी का वाहन बन जाता है। इसलिए एंटरप्राइज़ MCP गवर्नेंस "कौन-से सर्वर allowlist में हैं" पर रुक नहीं सकती — उसे यह भी कवर करना होगा कि हर सर्वर किस पहचान के साथ ऑथेंटिकेट कर सकता है, जो ठीक वही issuer= पिन है जो SDK अब देता है और 3.0 तक वैकल्पिक छोड़ता है।

INTERPRETATION — MCP एक प्रोटोकॉल-परत हमला-सतह बन गया है, मॉडल-परत वाली नहीं। Forkast यह बात तीखेपन से कहता है: इस क्षेत्र की पिछली घटनाएँ (Azure AI Foundry का authentication bypass, एआई एजेंट को C2 बनाने वाला CARBONATO बॉटनेट, Salesforce Agentforce का SalesBleed) मॉडल और एजेंट व्यवहार को निशाना बनाती थीं। यह घटना "the plumbing between them" को निशाना बनाती है। जैसे-जैसे प्रोटोकॉल एजेंट सीमा के आर-पार क्रेडेंशियल ले जाते हैं, वे पहचान-सुरक्षा का पूरा भार विरासत में ले लेते हैं — और वह भार तब ले लेते हैं जब गवर्नेंस, मानक निकाय और CVE प्रक्रियाएँ अभी पकड़ में नहीं आईं।

FACT — प्रोटोकॉल की गवर्नेंस हकीकत। MCP एक खुला मानक है जिसे Anthropic ने पेश किया और Linux Foundation के Agentic AI Foundation को दान किया, जो इसे मेंटेन करता है (Cycode). SDK रिपॉज़िटरी modelcontextprotocol GitHub संगठन के अंतर्गत है और उसका PyPI होमपेज modelcontextprotocol.io है।

INTERPRETATION — जवाबदेही का तीन-परत अंतराल। CVE न होने का मतलब है न राष्ट्रीय CERT रिकॉर्ड, न KELV/KEV मार्ग, न विक्रेता एडवाइज़री का फैलाव। एडवाइज़री एक ही रिपॉज़िटरी टैब में रहती है। Linux Foundation के घर वाले कंसोर्टियम-चालित प्रोटोकॉल के पास न CVE असाइनमेंट प्रक्रिया है, न npm या PyPI एडवाइज़री जैसा सुरक्षा-एडवाइज़री वितरण चैनल। ऐसे प्रोटोकॉल के लिए जो डिफ़ॉल्ट इंटीग्रेशन परत बन रहा है, यह संरचनात्मक अंतराल है, एकबारगी चूक नहीं।

INTERPRETATION — MCP से आगे सामान्यीकरण योग्य पैटर्न। Cycode की समापन टिप्पणी ही रणनीतिक निष्कर्ष है: "All the controls were there. The issuer validation function existed. The credential binding existed. The audience restriction existed. They were all fed the same unverified input, and they all said 'looks good.'" यह हमलावर-नियंत्रित अनुपस्थिति पर fail-open नामक विरोधी-पैटर्न (anti-pattern) है, और यह हर वहाँ आम है जहाँ सुरक्षा जांच validate(resolve_expected()) के बजाय if trusted_input_is_present: validate(trusted_input) के रूप में लिखी जाती है। इसी आकार वाले किसी भी एजेंट फ़्रेमवर्क, प्लगइन लोडर या टूल ब्रोकर में वही बग है।

INTERPRETATION — हार्डनिंग "behaviour changes" के रूप में शिप हो रही है। दोनों फ़िक्स रिलीज़ों ने असली सुरक्षा नियंत्रण — issuer वैलिडेशन, रीडायरेक्ट सीमित करना, 5xx/429 पर लेगेसी फ़ॉलबैक अस्वीकार करना — "Behaviour changes" शीर्षक के नीचे बंडल किए, साथ में session-timeout डिफ़ॉल्ट भी। यह रिलीज़-इंजीनियरिंग का वह मानक है जो सुरक्षा को चुपचाप कम प्राथमिकता देता है। जब तक एआई SDK सुरक्षा-विशेष चेंजलॉग खंड और समन्वित CVE असाइनमेंट नहीं अपनाते, बचावकर्ताओं को रिलीज़ नोट्स को गद्य की तरह पढ़ना होगा, स्कैनरों पर भरोसा नहीं करना होगा।

PREDICTION. GHSA-qx49-fqc8-xw99 के लिए CVE अंततः मिलने की संभावना है — एडवाइज़री का फ़ॉर्मैट पहले से एक को स्थान देता है, और CNA द्वारा असाइन होने पर GHSA रिकॉर्ड आमतौर पर CVE में बैकफ़िल होते हैं। लेकिन यह कम-विश्वास वाली भविष्यवाणी है, और जब तक ऐसा नहीं होता, हर ऑटोमेटेड डिपेंडेंसी-नियंत्रण सतह इस पैकेज को साफ़ ही दिखाएगी।

PREDICTION. issuer= mcp 3.0 में अनिवार्य हो जाएगा, जैसा एडवाइज़री कहती है। उस समय अपग्रेड की दूसरी लहर में घर्षण अपेक्षित है, और यह भी अपेक्षित है कि मापने योग्य संख्या में टीमें पहली बार यह खोजेंगी कि उनके मशीन-टू-मशीन OAuth प्रोवाइडर वही अपना रहे थे जो MCP सर्वर विज्ञापित करता था।

FACT — पूरी एडवाइज़री का पालन करने के बाद बचा जोखिम:

FACT — "स्टोरेज साफ़ कर दिया" छोटी मांग नहीं है। एडवाइज़री कहती है कि संग्रहीत रजिस्ट्रेशन "include everything 1.x stored before 1.30.0". कोई भी क्लाइंट जिसने अपग्रेड से पहले डायनामिक क्लाइंट रजिस्ट्रेशन सहेजा था, अब भी एक अनबाउंड रिकॉर्ड रखे हुए है, और हमलावर-चुने सर्वर पर दोबारा रजिस्ट्रेशन क्लाइंट की ओर से पकड़ा नहीं जा सकता।

INTERPRETATION — सबसे बड़ा जोखिम चुपचाप-विफलता (silent failure) है। रिकवरी के चार में से तीन कदम सफल होने पर चुप रहते हैं। ऐसा अपग्रेड जो issuer= सेट नहीं छोड़ता, एक DeprecationWarning निकालता है जिसे Python डिफ़ॉल्ट रूप से छिपाता है। छूटी स्टोरेज सफ़ाई कोई त्रुटि नहीं देती। छूटा सीक्रेट रोटेशन कोई अलर्ट नहीं देता। कोई टीम चेकलिस्ट का हर दिखने वाला आइटम पूरा करके भी उजागर बनी रह सकती है।

INTERPRETATION — हमला-सतह का अर्थशास्त्र। गंभीरता उच्च है, लेकिन हमलावर के लिए लागत है एक कनेक्शन प्रयास और एक ऐसे पेज पर एक क्लिक जो असल में असली ही है। न फ़िशिंग ढाँचा, न मिलता-जुलता डोमेन, न मैलवेयर। यह कम-लागत, उच्च-रूपांतरण वाला हमला है, और यही प्रोफ़ाइल बात फैलने पर असली अभियानों में दिखती है — भले ही अभी कुछ भी शोषित न हुआ हो।

• कोई शोषण डेटा नहीं। न एडवाइज़री और न Cycode इस खामी का उपयोग करके किसी हमले की रिपोर्ट करते हैं, और मुझे कोई स्वतंत्र शोषण रिपोर्ट नहीं मिली। असली दुनिया के प्रभाव के बारे में सब कुछ क्षमता का आकलन है, मापा गया नतीजा नहीं।
• CVE न होने का मतलब है डाउनस्ट्रीम पारिस्थितिकी से कोई पुष्टि नहीं। चूँकि रिकॉर्ड वैश्विक GitHub Advisory Database, OSV.dev या NVD में मौजूद नहीं है, मेरे पास न विक्रेता-पक्ष टेलीमेट्री है, न EPSS स्कोर, न प्रभावित पैकेज के डाउनलोड आँकड़े, और न किसी तीसरे-पक्ष स्कैनर विक्रेता से स्वतंत्र पुष्टि।
• कोई KEV स्थिति नहीं, और कोई मिल भी नहीं सकती। मैंने 2026-10-02 के कैटलॉग में अनुपस्थिति की पुष्टि की, लेकिन CVE ID के बिना KEV लिस्टिंग संरचनात्मक रूप से असंभव है। "KEV में नहीं" को "लागू नहीं" मानें, "शोषित नहीं" नहीं।
• प्रभावित आबादी का आकार अज्ञात है। मेरे पास कोई आँकड़ा नहीं है कि कितने Python एप्लिकेशन mcp.client.auth को HTTP पर अविश्वसनीय सर्वरों के सामने इस्तेमाल करते हैं। 73 PyPI रिलीज़ और 24.5k GitHub स्टार एक सक्रिय रूप से मेंटेन किए जाने वाले, व्यापक रूप से अपनाए गए पैकेज की ओर संकेत करते हैं, लेकिन वे अपनाव (adoption) डेटा नहीं हैं।
• Cycode के दावे विक्रेता के दावे हैं। पूरी-चेन अकाउंट-टेकओवर प्रदर्शन, कोड स्निपेट और तीन-कॉन्फ़िगरेशन तालिका — सब रिपोर्टिंग विक्रेता के अपने राइट-अप और PoC से आते हैं। मैंने सत्यापित किया कि एडवाइज़री संस्करण रेंज, issuer= उपचार, गंभीरता और CWE वर्गीकरण की पुष्टि करती है; मैंने PoC को स्वतंत्र रूप से दोबारा नहीं चलाया। Forkast और The Hacker News तंत्र तथा संस्करण तालिका की पुष्टि रिपोर्टिंग के स्तर पर करते हैं, पुनरुत्पादन के स्तर पर नहीं।
• CVSS वेक्टर में I:N/A:N डाउनस्ट्रीम प्रभाव को कम आँक सकते हैं, लेकिन मेरे पास सुधारा हुआ स्कोर प्रकाशित करने का कोई आधार नहीं है।
• रिलीज़-नोट सामग्री v1.30.0 और v2.2.0 के लिए GitHub रिलीज़ API का मेरा सीधा पाठ है; मैंने PR #3398 और #3431 का पूरा diff ऑडिट नहीं किया, न PR #3263 का, जो अब भी खुला है।
• गवर्नेंस वाले कथन उद्धृत हैं, निर्णीत नहीं। Cycode का यह दावा कि MCP को Linux Foundation के Agentic AI Foundation को दान किया गया, एक कंपनी कथन है; मैंने रिपॉज़िटरी और PyPI प्रोजेक्ट URL सत्यापित किए, लेकिन फ़ाउंडेशन के अपने रिकॉर्ड स्वतंत्र रूप से सत्यापित नहीं किए।

1. CVE असाइन होगा या नहीं, और कौन करेगा? इसके बिना फ़िक्स हर CVE-चालित नियंत्रण के लिए अदृश्य है। Linux Foundation के घर वाले प्रोटोकॉल SDK का CNA कौन है?
2. फ़िक्स एडवाइज़री से तीन हफ़्ते पहले, "Behaviour changes" के नीचे क्यों शिप हुआ? क्या यह जानबूझकर लिया गया समन्वित-डिस्क्लोज़र निर्णय था, या अनजाने में हुई पूर्व-घोषणा, जिसके इर्द-गिर्द डिस्क्लोज़र टाइमलाइन को बाद में घूमना पड़ा?
3. असल में कितने प्रोडक्शन क्लाइंट प्रभावित हैं? mcp.client.auth के HTTP उपयोग के लिए किसी ने अपनाव का आँकड़ा प्रकाशित नहीं किया।
4. क्या issuer= 3.0 से पहले डिफ़ॉल्ट रूप से लागू होगा, या केवल चेतावनी रहेगी? DeprecationWarning जिसे Python छिपा देता है, कमज़ोर नियंत्रण है; FutureWarning या कोई कठोर डिफ़ॉल्ट ज़्यादा मज़बूत होगा। यह मेंटेनरों के लिए खुला सवाल है।
5. दूसरे SDK और दूसरी प्रोटोकॉल परतों का क्या? एडवाइज़री Python में mcp.client.auth को कवर करती है। TypeScript/JS SDK में और दूसरे एजेंट-प्रोटोकॉल कार्यान्वयनों में समतुल्य OAuth क्लाइंट इस डिस्क्लोज़र का हिस्सा नहीं थे और यहाँ जांचे नहीं गए।
6. क्या अब भी खुला PR #3263 (कोल्ड-स्टार्ट टोकन रीफ़्रेश से पहले AS मेटाडेटा डिस्कवरी, issuer-बाइंडिंग जांच के साथ) कोई बचा अंतराल बंद करता है? शोध के समय वह खुला था।
7. एजेंट फ़्रेमवर्क को अब MCP OAuth कैसे संभालना चाहिए? अगर मॉडल सर्वर चुनता है, तो issuer= पिन ही एकमात्र चीज़ है जो क्रेडेंशियल चोरी रोकती है — क्या उसे सीमित करने के लिए कोई उभरती सर्वोत्तम प्रथा (best practice) है?
8. क्या MCP को खुद स्पेसिफ़िकेशन स्तर पर क्रेडेंशियल-से-issuer बाइंडिंग अनिवार्य करनी चाहिए, बजाय उसे ऐसे SDK विकल्प के रूप में छोड़ने के जो केवल 3.0 में अनिवार्य होता है?
9. क्या डिस्क्लोज़र से पहले के किसी शोषण का कोई साक्ष्य है? Cycode की बताई प्रभाव-विंडो पूरी प्रभावित संस्करण रेंज है, जो लंबी है। ऑथराइजेशन सर्वरों पर पीछे की ओर लॉग समीक्षा (retrospective log review) ही इसे जानने का एकमात्र रास्ता होगा।
10. जंगल में क्लाइंट रजिस्ट्रेशनों का असली वितरण क्या है — डायनामिक (सहेजे गए और अनबाउंड) बनाम issuer सेट के साथ पहले से प्रोविज़न किए गए? यह तय करता है कि पिन के बिना अपग्रेड करने के बाद कितनी टीमें उजागर रहती हैं।

Circle 1 — तत्काल, व्यक्तिगत, कम श्रम।

प्रभाव: कोई नहीं, जब तक आप खुद HTTP पर Python MCP क्लाइंट मेंटेन नहीं करते। अगर आपने कभी mcp.client.auth के सामने कोड नहीं लिखा, तो यह आपको नहीं छूता। सर्वर लेखक, stdio उपयोगकर्ता, और हर वह व्यक्ति जो अपना बियरर टोकन (bearer token) खुद जोड़ता है, स्पष्ट रूप से प्रभावित नहीं हैं।

अनुशंसित कार्रवाई (अगर यह आप हैं — 15 मिनट से कम):

1. अपना पिन किया संस्करण जांचें: pip show mcp / pip index versions mcp. अगर आप 1.9.1–1.29.1 या 2.0.0–2.1.1 पर हैं, तो आप प्रभावित रेंज में हैं।
2. जांचें कि आपके कोड में से कोई OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, या RFC7523OAuthClientProvider को HTTP ट्रांसपोर्ट के auth= हैंडलर के रूप में पास करता है या नहीं। अगर आपके कोड में इनमें से कोई स्ट्रिंग नहीं दिखती, यहीं रुक जाएँ — आप प्रभावित नहीं हैं।
3. अगर दिखती हैं, तो 1.30.0+ या 2.2.0+ पर अपग्रेड करें।
4. अगर आप दो मशीन-टू-मशीन प्रोवाइडर इस्तेमाल करते हैं, तो issuer="https://your-real-idp.example.com" जोड़ें — इनके लिए अपग्रेड इसके बिना कुछ नहीं करता।
5. अगर आप RFC7523OAuthClientProvider इस्तेमाल करते हैं, तो माइग्रेशन की योजना बनाएँ; इसमें issuer= विकल्प नहीं है।

अनुशंसित कार्रवाई (सेल्फ़-होस्टेड / व्यक्तिगत एजेंट स्टैक): केवल उन MCP सर्वरों से जुड़ना जिन पर आप पूरा भरोसा करते हैं, अनपैच्ड संस्करणों पर एकमात्र शमन है। चूँकि फ़िक्स 2026-09-28 से सार्वजनिक है, आज किसी प्रभावित संस्करण पर बने रहना बिना किसी लाभ वाला चुनाव है।

Circle 2 — टीम, प्रक्रिया, एक से दो तिमाही आगे।

प्रभाव: प्रोडक्शन में OAuth-सक्षम MCP क्लाइंट चलाने वाली हर टीम के लिए उच्च। यह खोज आपके स्कैनरों को नहीं दिखती, इसलिए आपको इसे जानबूझकर स्रोत से लाना होगा।

अनुशंसित कार्रवाई (इस तिमाही):

1. CVE का इंतज़ार मत कीजिए। मैंने सत्यापित किया कि यह एडवाइज़री वैश्विक GitHub Advisory Database, OSV.dev, NVD और CISA KEV में मौजूद नहीं है, और फ़िक्स 2026-09-07 को "Behaviour changes" शीर्षक के नीचे शिप हुआ। GHSA-qx49-fqc8-xw99 और दोनों रिलीज़ टैग को हाथ से अपनी ट्रैकिंग में जोड़ें।
2. इन्वेंटरी संस्करण से नहीं, कॉन्फ़िगरेशन से बनाइए। अकेला संस्करण दो दिशाओं में अपर्याप्त है: 2.0.0–2.1.1 केवल फ़ॉलबैक और 403-स्टेप-अप पाथ पर कमज़ोर थे, और अपग्रेड किए गए 2.2.0/1.30.0 क्लाइंट जो दो मशीन-टू-मशीन प्रोवाइडर issuer= के बिना इस्तेमाल करते हैं, अब भी कमज़ोर हैं। चारों प्रोवाइडर क्लास नामों के लिए grep करें, किसी संस्करण स्ट्रिंग के लिए नहीं।
3. पिन को नीति बनाइए। ClientCredentialsOAuthProvider और PrivateKeyJWTOAuthProvider के लिए कोड रिव्यू में issuer= अनिवार्य करें और लिंट/टेस्ट नियम जोड़ें। mcp 3.0 में इसके अनिवार्य होने की योजना रखें।
4. क्रेडेंशियल स्वच्छता का एकबारगी दौर। संग्रहीत OAuth क्लाइंट रजिस्ट्रेशन साफ़ करें ताकि क्लाइंट issuer लेबल के साथ दोबारा रजिस्टर करें। फिर, हर उस क्लाइंट के लिए जो 1.9.1 से अब तक किसी ऐसे सर्वर से जुड़ा हो सकता है जिसे आप पूरी तरह नियंत्रित नहीं करते थे, क्लाइंट सीक्रेट रोटेट करें और ऑथराइजेशन सर्वर पर टोकन रद्द करें। सीक्रेट रोटेट किए बिना टोकन रद्द करना इसे बंद नहीं करता।
5. अपने MCP क्लाइंट कोड के लिए CI में DeprecationWarning सक्षम करें — जैसे आपके टेस्ट सूट में python -W error::DeprecationWarning — वरना सामान्य संचालन में गुम-issuer चेतावनी आपको नहीं दिखेगी, क्योंकि Python उसे डिफ़ॉल्ट रूप से दबा देता है।
6. संग्रहीत रजिस्ट्रेशनों में भरोसे का फिर से आधार बनाइए। अपग्रेड से पहले सहेजा गया कोई भी क्लाइंट रजिस्ट्रेशन अनबाउंड है और उसे संदिग्ध मानना चाहिए, कैश नहीं।
7. MCP को अपनी एजेंट-गवर्नेंस समीक्षा में जोड़ें। अगर एजेंट रनटाइम पर MCP सर्वर चुनता है, तो कनेक्शन का निर्णय अब सुरक्षा का निर्णय है। यह सीमित कीजिए कि हर अनुमत सर्वर किस पहचान के साथ ऑथेंटिकेट कर सकता है, केवल यह नहीं कि कौन-से सर्वर अनुमत हैं।

Circle 3 — रणनीतिक, 6–18 महीने, बोर्ड/पोर्टफ़ोलियो स्तर।

प्रभाव: यह एजेंट-प्रोटोकॉल पारिस्थितिकी की परिपक्वता के बारे में साक्ष्य है, एकबारगी SDK बग नहीं। यह ऐसी खोज है जो बदल देती है कि एआई इंफ़्रास्ट्रक्चर जोखिम को कैसे गवर्न किया जाता है।

अनुशंसित कार्रवाई (रणनीतिक):

1. जो आप ट्रैक करते हैं, उसे बदलिए। एआई और एजेंट SDK सुरक्षा फ़िक्स "behaviour changes" के रूप में और CVE ID के बिना शिप कर रहे हैं। एआई/एजेंट इंफ़्रास्ट्रक्चर में GHSA-स्तर की एडवाइज़री के लिए एक समर्पित फ़ीड बनाइए — modelcontextprotocol/python-sdk, मॉडल रनटाइम, एजेंट फ़्रेमवर्क, MCP रजिस्ट्रियाँ — प्रथम-श्रेणी की वॉचलिस्ट के रूप में, CVE स्कैनिंग का उपोत्पाद नहीं।
2. एआई-प्रोटोकॉल क्रेडेंशियल को सामान्य पहचान गवर्नेंस के अंतर्गत लाइए। आज MCP क्लाइंट का OAuth सीक्रेट एक ऐप क्रेडेंशियल है जो अक्सर सीक्रेट्स-मैनेजमेंट और रोटेशन प्रक्रिया से पूरी तरह बच निकलता है। उन OAuth क्लाइंटों की इन्वेंटरी बनाइए जिनका स्कोप उस सर्वर से व्यापक है जिनके लिए वे बने थे; यही असंगति एक चोरी हुए सीक्रेट को संगठन-व्यापी समस्या बना देती है।
3. "कोई CVE नहीं" को संकेत की अनुपस्थिति मानिए, जोखिम की अनुपस्थिति नहीं। भीतर तर्क अभी बनाइए, जब यह केस ठोस है: पूरी एक्सपोज़र विंडो में रिकॉर्ड केवल एक रिपॉज़िटरी टैब में था, जबकि पैच किया गया रिलीज़ आपकी रजिस्ट्री में व्यवहार-परिवर्तन का लेबल लगाए बैठा था।
4. प्रोटोकॉल-स्तर की गारंटी मांगिए, SDK-स्तर के विकल्प नहीं। 3.0 तक वैकल्पिक issuer= पिन उपचार का सबसे कमज़ोर हिस्सा है। ऐसी पारिस्थितिकी के लिए जहाँ हर क्लाइंट OAuth डिस्कवरी अलग से फिर से लागू करता है, क्रेडेंशियल-से-issuer बाइंडिंग MCP स्पेसिफ़िकेशन में एक मानकीय अपेक्षा (normative requirement) के रूप में होनी चाहिए, प्रति-SDK पैरामीटर के रूप में नहीं।
5. अपने ही कोडबेसों को fail-open पैटर्न के लिए ऑडिट कीजिए। सामान्यीकरण योग्य सबक वह सुरक्षा जांच है जो if trusted_input: validate(trusted_input) के रूप में लिखी गई हो, जहाँ हमलावर नियंत्रित करता है कि इनपुट मौजूद है या नहीं — और जहाँ असत्यापित मान फिर अगली जांच में भरोसेमंद इनपुट के रूप में जाता है। इसी आकार वाले किसी भी प्लगइन लोडर, टूल ब्रोकर या एजेंट फ़्रेमवर्क में वही दोष है, और उनमें से किसी को CVE नहीं मिलेगा।
6. पहचान (detection) अनुसंधान को धन दीजिए, क्योंकि पहचान ही अनसुलझा हिस्सा है। डिज़ाइन से ही हमला चुपचाप है: कोई विफल लॉगिन नहीं, कोई असामान्य IP नहीं, कोई MFA चुनौती नहीं, पीड़ित को दिखने वाला कोई लक्षण नहीं। आउटबाउंड टोकन-एंडपॉइंट अनुरोधों पर प्रॉक्सी-स्तर या क्लाइंट-पक्ष टेलीमेट्री — क्या टोकन एंडपॉइंट उसी ऑथराइजेशन बेस URL पर है जो SDK ने रिज़ॉल्व किया था? — वह संकेत है जो इस श्रेणी को सामान्य रूप से पकड़ लेगा। आज यह मानक नियंत्रण के रूप में मौजूद नहीं है।
7. समन्वित डिस्क्लोज़र मानकों के लिए दबाव डालिए। Linux Foundation के घर वाले, एक के बजाय मेंटेनर-आधारित प्रोटोकॉल को एक परिभाषित सुरक्षा-एडवाइज़री वितरण चैनल और CVE असाइनमेंट मार्ग चाहिए। दोनों की अनुपस्थिति ही प्रणालीगत निष्कर्ष है।

INTERPRETATION — वास्तविक, अनुमानित नहीं। इनमें से हर एक सीधे उस अंतराल से निकलता है जो यह स्टोरी दिखाती है।

1. पहचान-सीमित एजेंट गवर्नेंस (identity-scoped agent governance). एंटरप्राइज़ मंज़ूर करते हैं कि कौन-से MCP सर्वर तक एजेंट पहुँच सकता है, लेकिन शायद ही कभी यह कि कौन-सी पहचान के रूप में हर एक ऑथेंटिकेट कर सकता है। issuer= इसे लागू-न-करने योग्य नीति-कथन से लागू तकनीकी नियंत्रण बना देता है। विक्रेता "एजेंट कनेक्टरों के लिए प्रति-सर्वर पहचान पिनिंग" को MCP गेटवे में नीति-प्रवर्तन सुविधा के रूप में उत्पादित कर सकते हैं।
2. SBOM और डिपेंडेंसी-दृश्यता अंतराल विश्लेषण। यह खामी किसी एडवाइज़री के अस्तित्व में आने से 21 दिन पहले तक प्रोडक्शन रजिस्ट्रियों में थी, और CVE-आधारित टूलिंग में यह दिखेगी नहीं। यह बेचने योग्य खोज है: "आपका SCA टूल mcp को साफ़ बताता है; यह वह है जो वह आपको नहीं बता रहा।" एजेंट-SDK और प्रोटोकॉल-पैकेज कवरेज पारंपरिक पैकेज पारिस्थितिकियों के मुक़ाबले असली विभेदक है।
3. MCP सर्वर सप्लाई-चेन आश्वासन (assurance). जब रजिस्ट्री/कैटलॉग ज़हरीला करना एक नामित हमला-मार्ग है, तो MCP सर्वर प्रविष्टियों का सत्यापन और हस्ताक्षर — और यह निगरानी कि हर प्रविष्टि किस पहचान का अनुरोध करती है — एक असली बाज़ार है, जो उसके निकट है जो Sigstore ने पैकेजों के लिए किया।
4. एजेंट-रनटाइम पहचान (detection). चुपचाप, क्रेडेंशियल-पूर्ण OAuth अदला-बदली एक पकड़ने योग्य पैटर्न है अगर आप उसे इंस्ट्रुमेंट करें। एक हल्का SDK या प्रॉक्सी एजेंट जो "टोकन एंडपॉइंट होस्ट, रिज़ॉल्व किए गए ऑथराइजेशन बेस URL से अलग है" को फ़्लैग करे, वह अंतराल बंद करता है जिसे आज कोई मानक नियंत्रण कवर नहीं करता।
5. प्रोटोकॉल सुरक्षा एडवाइज़री सेवाएँ। CVE असाइनमेंट या समन्वित डिस्क्लोज़र चैनल के बिना प्रोटोकॉल पारिस्थितिकियों को CNA कार्य, एडवाइज़री ट्रायाज और GitHub Advisory DB, OSV तथा NVD पर प्रतिबिंबित प्रकाशन चाहिए। यहाँ असली संस्थागत अंतराल है, और यह दोहराएगा।
6. क्रेडेंशियल ब्लास्ट-रेडियस में कमी। Cycode का मूल एंटरप्राइज़ बिंदु — एक OAuth क्लाइंट कई डाउनस्ट्रीम सेवाओं के लिए अधिकृत — एक ठोस, मापने योग्य खोज है जिसे कोई भी CISO फ़ंड करेगा: हर OAuth क्लाइंट के दिए गए स्कोप की इन्वेंटरी बनाइए, उन्हें बाँटिए, और हर एक को एक सर्वर से बाँधिए।

अनुशंसित अभ्यास: INSPECT — एडवाइज़री के सामने अपने MCP OAuth कॉन्फ़िगरेशन का ऑडिट करें।

यह स्टोरी हाथों-हाथ अभ्यास के लिए असामान्य रूप से उपयुक्त है क्योंकि एक्सपोज़र की जांच सस्ती, नियतात्मक (deterministic) है, और उसमें किसी एक्सप्लॉइट की ज़रूरत नहीं।

1. संस्करण जांच। pip index versions mcp (या uv.lock / requirements.txt / अपनी लॉकफ़ाइल पढ़ें)। >=1.9.1,<1.30.0 या >=2.0.0a1,<2.2.0 में किसी भी रिज़ॉल्यूशन को फ़्लैग करें।
2. प्रोवाइडर grep। कोडबेस में OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWT, RFC7523, और auth= खोजें। शून्य हिट → प्रभावित नहीं, रुक जाएँ।
3. पिन जांच। दो मशीन-टू-मशीन प्रोवाइडरों पर हर हिट के लिए issuer= grep करें। गुम → अपग्रेड के बाद भी कमज़ोर। यही वह खोज है जो ज़्यादातर टीमें चूकेगी, क्योंकि चेतावनी एक DeprecationWarning है जिसे Python डिफ़ॉल्ट रूप से छिपाता है।
4. ट्रांसपोर्ट जांच। पुष्टि करें कि प्रोवाइडर HTTP ट्रांसपोर्ट (streamable_http_client, sse_client, या Client("https://...")) से जुड़ा है, stdio से नहीं। stdio प्रभावित नहीं है।
5. ट्रस्ट-बाउंड्री जांच। कॉन्फ़िग में हर एंडपॉइंट URL को वर्गीकृत करें: पूरी तरह भरोसेमंद / आंशिक भरोसेमंद / अविश्वसनीय। कोई भी क्लाइंट जो किसी असली ऑथराइजेशन सर्वर के क्रेडेंशियल रखता है और किसी आंशिक- या अविश्वसनीय सर्वर तक पहुँच सकता है, फ़िक्स-पूर्व उजागर है।
6. संग्रहीत-रजिस्ट्रेशन जांच। OAuth क्लाइंट-जानकारी स्टोर खोजें। अपग्रेड से पहले लिखा गया कुछ भी अनबाउंड है। एक बार साफ़ करें; अगर आपने क्लाइंट खुद पहले से रजिस्टर किए थे, तो रिकॉर्ड पर issuer सेट करें।
7. CI चेतावनी जांच। पुष्टि करें कि आपका टेस्ट रन DeprecationWarning सामने लाता है। अगर नहीं, तो स्टेप 3 के लिए आपके पास कोई संकेत नहीं है।
8. रोटेशन योजना। स्टेप 5 के क्लाइंटों से पहुँच-योग्य हर क्लाइंट सीक्रेट और टोकन सेट की सूची बनाएँ, और रोटेशन तथा टोकन रद्दीकरण का शेड्यूल बनाएँ।

स्टेप 1–4 किसी असली सेवा पर एक घंटे की झाड़ू के रूप में चलाइए; जो भी बचे उसके लिए 5–8 चलाइए।

FACT — एडवाइज़री और रिलीज़ नोट्स में कहा गया:

• issuer= mcp 3.0 में अनिवार्य हो जाता है।
• प्रभावित संस्करणों पर अपने MCP सर्वरों पर भरोसा करने के अलावा कोई उपाय नहीं है।

PREDICTION — निकट अवधि (हफ़्तों से महीनों):

• जो टीमें 7–28 सितंबर के बीच रिलीज़ नोट्स पढ़कर, एडवाइज़री पढ़े बिना अपग्रेड कर चुकी हैं, वे फिर से अपग्रेड करेंगी जब कोई issuer= आवश्यकता पर ध्यान देगा, या जब 3.0 उसे थोप देगा। दूसरी, बड़ी माइग्रेशन लहर अपेक्षित है।
• CVE असाइनमेंट संभावित है लेकिन निश्चित नहीं; GHSA रिकॉर्ड पहले से उस फ़ॉर्मैट में है जो CVE में बैकफ़िल होता है।
• PR #3263 (कोल्ड-स्टार्ट टोकन रीफ़्रेश से पहले ऑथराइजेशन-सर्वर मेटाडेटा डिस्कवरी, issuer-बाइंडिंग जांच के साथ) शोध के समय भी खुला था, इसलिए mcp.client.auth में और OAuth-क्लाइंट हार्डनिंग की संभावना है।

PREDICTION — मध्यम अवधि (6–18 महीने):

• पहला असली शोषण अभियान, अगर होता है, तो नई तकनीक के बजाय Cycode के नामित मार्गों में से किसी एक से आने की संभावना है — ज़हरीली MCP रजिस्ट्री प्रविष्टियाँ, या प्रॉम्प्ट इंजेक्शन जो एजेंट को हमलावर-नियंत्रित सर्वर की ओर मोड़े। अपेक्षा रखिए कि यह OAuth एक्सप्लॉइट के बजाय सप्लाई-चेन समझौते जैसा दिखेगा।
• MCP के लिए दूसरी भाषाओं के SDK को समतुल्य डिस्कवरी-हार्डनिंग काम का सामना करना पड़ेगा, और यहाँ CVE का न होना इस बात का संकेत हो सकता है कि कहीं और समतुल्य मुद्दे सामने ही नहीं आए।
• issuer=-शैली की क्रेडेंशियल-से-issuer बाइंडिंग के MCP स्पेसिफ़िकेशन में SDK-स्तर की सुविधा के बजाय मानकीय अपेक्षा बनने की संभावना है, और इसका चालक ठीक यही केस होगा।
• पहचान (detection) अनसुलझा हिस्सा बना हुआ है: हमला डिज़ाइन से चुपचाप है, और आज कोई मानक नियंत्रण चोरी हुई-पर-वैध OAuth अदला-बदली को वैध से अलग नहीं करता।

इस आकलन को क्या बदलेगा: शोषण का साक्ष्य; कोई CVE असाइनमेंट जो तीसरे-पक्ष की टेलीमेट्री ले आए; TypeScript SDK या खुद MCP में कोई उत्तरवर्ती खोज; या mcp 3.0 का issuer= को चेतावनी के बजाय कठोर आवश्यकता के रूप में शिप करना।

MCP की OAuth खामी इसलिए दिलचस्प नहीं है कि किसी लोकप्रिय लाइब्रेरी में बग था। यह इसलिए दिलचस्प है कि यह दिखाती है क्या होता है जब कोई एजेंट प्रोटोकॉल एंटरप्राइज़ क्रेडेंशियल ढोने लगता है, उससे पहले कि आसपास की मशीनरी पकड़ सके — और मशीनरी पकड़ ही नहीं पाई।

तीन तथ्य इस स्टोरी को परिभाषित करते हैं। सभी नियंत्रण मौजूद थे: issuer वैलिडेशन था, क्रेडेंशियल बाइंडिंग थी, audience प्रतिबंध था। सबको वही असत्यापित इनपुट मिला, इसलिए सबने कहा "looks good". फ़िक्स 7 सितंबर को "Behaviour changes" नामक शीर्षक के नीचे शिप हुआ, और एडवाइज़री 28 सितंबर तक सामने नहीं आई — और तब भी वह केवल एक रिपॉज़िटरी टैब में है, बिना CVE, बिना NVD रिकॉर्ड, बिना OSV रिकॉर्ड, और संरचनात्मक रूप से CISA KEV लिस्टिंग की कोई संभावना नहीं। तीन हफ़्ते तक पैकेज का सुरक्षित संस्करण हर रजिस्ट्री में बैठा था और हर डिपेंडेंसी स्कैनर उसे सामान्य बता रहा था।

गहरा संरचनात्मक बिंदु ट्रस्ट-बाउंड्री का उलटाव है। पारंपरिक सप्लाई-चेन जोखिम है जो कोड आप इंस्टॉल करते हैं वह आपके विशेषाधिकारों से चले। यहाँ वह सर्वर है जिससे आप रनटाइम पर जुड़ते हैं, और वह कनेक्ट करने वाले क्लाइंट से क्रेडेंशियल निकाल लेता है — पीड़ित ठीक असली पहचान प्रदाता पर एक पूरी तरह असली लॉगिन पेज मंज़ूर करता है, इसलिए ध्यान देने जैसी कुछ नहीं और मॉनिटरिंग के फ़्लैग करने जैसा कुछ नहीं। और जो पहचान मिलती है वह उपयोगकर्ता की नहीं: वह एप्लिकेशन का OAuth क्लाइंट है, जो एंटरप्राइज़ में अक्सर उस एक सर्वर से कहीं ज़्यादा के लिए अधिकृत होता है जिससे वह बात कर रहा था।

इसीलिए ईमानदार फ़्रेमिंग यह है: "उस MCP का संदर्भ SDK जिसे Anthropic ने बनाया और Linux Foundation के Agentic AI Foundation को दान किया", जिसे modelcontextprotocol संगठन में मेंटेन किया जाता है और MCP सुरक्षा प्रक्रिया से डिस्क्लोज़ किया गया — "Anthropic का SDK" नहीं। लोकप्रिय हेडलाइन स्वामित्व के बारे में ग़लत है, और यहाँ मायने स्वामित्व का सवाल ही रखता है, क्योंकि जिस प्रोटोकॉल के पास CVE-असाइनमेंट मार्ग या समन्वित एडवाइज़री चैनल नहीं, उसके पास किसी डिस्क्लोज़र को भेजने की जगह ही नहीं।

करने योग्य बचा काम बिना चमक-दमक वाला और तत्काल है: 1.30.0 या 2.2.0 पर अपग्रेड करें, फिर — दो मशीन-टू-मशीन प्रोवाइडरों के लिए — issuer= सेट करें, क्योंकि अकेला अपग्रेड वहाँ कुछ नहीं करता और जो चेतावनी आपको बताती वह एक DeprecationWarning है जिसे Python डिफ़ॉल्ट रूप से छिपाता है। संग्रहीत रजिस्ट्रेशन साफ़ करें। सीक्रेट रोटेट करें और टोकन रद्द करें अगर कोई प्रभावित क्लाइंट कभी ऐसे सर्वर से मिला हो जिसे आप पूरी तरह नियंत्रित नहीं करते थे। और इस पारिस्थितिकी पर कुछ बनाने वाले हर किसी के लिए: एजेंट SDK की GHSA-स्तर की एडवाइज़री सीधे ट्रैक कीजिए, क्योंकि स्कैनर आपको नहीं बताएँगे, और यहाँ "कोई CVE नहीं" का मतलब पूरे उस समय कोई संकेत ही नहीं था जब खामी ज़िंदा थी।

मुख्य आँकड़े, एक साथ