MCP Python SDK OAuth issuer सत्यापन दोष

GHSA-qx49-fqc8-xw99 में HTTP MCP सर्वर उस गंतव्य को प्रभावित कर सकता था जहाँ प्रभावित Python SDK OAuth क्लाइंट क्रेडेंशियल भेज सकते थे। mcp 1.30.0 या 2.2.0 पर अपग्रेड करें; मशीन-टू-मशीन प्रदाताओं में issuer= सेट करना आवश्यक है। कोई CVE नहीं दिया गया है।^{[1], [3], [8]}

CVSS वेक्टर

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N^[1]

💡 आसान भाषा में (ELI5)

मान लें कि कोई कंपनी मुहरबंद चाबी उस बैंक को भेजती है जिसका पता स्वीकृत निर्देशिका कार्ड पर है। MCP सर्वर वह कार्ड दे सकता था, और एक वैकल्पिक रास्ता यह नहीं जाँचता था कि कार्ड पर दिया नाम अपेक्षित बैंक का ही है। Issuer सत्यापन चाबी भेजने से पहले कार्ड की पहचान को कॉन्फ़िगरेशन में भरोसेमंद बैंक से मिलाता है।^{[1], [2]}

इस पेज के मुख्य शब्द

MCP क्लाइंट: Model Context Protocol से MCP सर्वर के टूल या डेटा तक जुड़ने वाला अनुप्रयोग। यह दोष तब लागू होता है जब Python SDK को OAuth प्रदाताओं सहित HTTP क्लाइंट की तरह उपयोग किया जाए।^[1]
Authorization server issuer: टोकन जारी करने वाली OAuth सेवा का स्थिर पहचानकर्ता। क्लाइंट को मिले मेटाडेटा की तुलना स्वतंत्र रूप से अपेक्षित issuer से करनी चाहिए।^{[1], [2]}
Protected Resource Metadata (PRM): सुरक्षित संसाधन के authorization server की पहचान बताने वाला मेटाडेटा। PRM उपलब्ध न होने पर SDK में पुराना खोज-पथ भी है।^{[1], [2]}
PKCE code verifier: क्लाइंट द्वारा बनाया गया गुप्त मान जो OAuth authorization-code विनिमय को शुरू करने वाले क्लाइंट से बाँधता है। इसे अविश्वसनीय endpoint को नहीं देना चाहिए।^{[1], [2]}
CWE-345 / CWE-522: डेटा की प्रामाणिकता का अपर्याप्त सत्यापन: अपेक्षित स्रोत की पुष्टि किए बिना डेटा स्वीकार करना। CWE-522 क्रेडेंशियल की अपर्याप्त सुरक्षा दर्शाता है।^{[1], [4], [7]}

फ्रेमवर्क मैपिंग

इस गाइड में बताई गई कमजोरी के लिए CWE संदर्भ: CWE-345 CWE-522

हमले का चरण-दर-चरण प्रवाह

चरण 1

HTTP MCP क्लाइंट के पास OAuth क्रेडेंशियल हैं

अनुप्रयोग प्रभावित mcp संस्करण और SDK के OAuth प्रदाताओं में से एक उपयोग करता है। उसके पास क्लाइंट सीक्रेट, हस्ताक्षर कुंजी या सहेजा गया क्लाइंट पंजीकरण हो सकता है और वह पूरी तरह भरोसेमंद न होने वाले MCP सर्वर से जुड़ सकता है।^[1]

चरण 2

सर्वर authorization खोज को प्रभावित करता है

mcp 1.9.1–1.29.1 में खोज के हर रास्ते पर issuer सत्यापन और क्रेडेंशियल बाइंडिंग नहीं थी। mcp 2.0.0–2.1.1 तब प्रभावित था जब PRM अनुपस्थित होने पर पुराना fallback चलता था, या 403 insufficient_scope के बाद step-up खोज होती थी। दोनों संस्करण-श्रृंखलाओं के मशीन-टू-मशीन प्रदाताओं में पहले से दिए क्रेडेंशियल बाँधने के लिए issuer= नहीं था। Advisory की पैकेज सीमा प्री-रिलीज़ 2.0.0a1 से शुरू होकर <2.2.0 है; इसलिए प्रभावित 2.0.0 प्री-रिलीज़ भी दायरे में हैं।^{[1], [3], [8]}

चरण 3

टोकन endpoint को क्रेडेंशियल भेजे जाते हैं

क्लाइंट इन मेटाडेटा से चुने गए endpoint को क्लाइंट सीक्रेट, authorization code और PKCE verifier, या हस्ताक्षरित assertion भेज सकता है। कौन-सा क्रेडेंशियल शामिल है, यह प्रदाता पर निर्भर है; हर क्लाइंट प्रभावित नहीं है।^{[1], [2]}

चरण 4

प्रभाव प्रदाता और अनुमतियों पर निर्भर है

प्राप्तकर्ता उजागर क्रेडेंशियल या टोकन का उपयोग दी गई अनुमतियों की सीमा में कर सकता है। सलाह में बिना मानवीय हस्तक्षेप वाले प्रदाताओं के लिए CVSS 7.5 और इंटरैक्टिव प्रदाता के लिए 6.5 है, क्योंकि व्यक्ति को लॉगिन शुरू करना पड़ता है। सलाह के अनुसार अभी कोई CVE आवंटित नहीं किया गया है।^[1]

चरण 5

Issuer पिनिंग भरोसे की कमी दूर करती है

ठीक किए गए संस्करण खोज से पहले अपेक्षित issuer तय करते हैं, बेमेल मेटाडेटा अस्वीकार करते हैं और सहेजे गए पंजीकरण को उसी issuer से बाँधते हैं। मशीन-टू-मशीन प्रदाताओं में issuer= स्पष्ट रूप से देना भी आवश्यक है।^{[1], [2], [3], [8]}

MCP Python SDK OAuth: संस्करण और कार्रवाई मैट्रिक्स

क्लाइंट कॉन्फ़िगरेशन	दस्तावेज़ित प्रभावित स्थिति	आवश्यक कार्रवाई
`mcp` 1.9.1–1.29.1 वाला HTTP OAuth क्लाइंट	खोज के सभी रास्तों में issuer सत्यापन और क्रेडेंशियल को issuer से लगातार बाँधना अनुपस्थित था।	`mcp` 1.30.0 या बाद के संस्करण पर अपग्रेड करें और तैनात संस्करण की पुष्टि करें।
`mcp` 2.0.0–2.1.1 वाला HTTP OAuth क्लाइंट	PRM न होने पर पुराना fallback चलने की स्थिति में, या `403 insufficient_scope` के बाद step-up खोज में प्रभावित। Advisory की पैकेज सीमा प्री-रिलीज़ `2.0.0a1` से शुरू होकर `<2.2.0` है; इसलिए प्रभावित 2.0.0 प्री-रिलीज़ भी दायरे में हैं।	`mcp` 2.2.0 या बाद के संस्करण पर अपग्रेड करें और तैनात संस्करण की पुष्टि करें।
पहले से दिए गए क्रेडेंशियल वाले `ClientCredentialsOAuthProvider` या `PrivateKeyJWTOAuthProvider`	प्रभावित संस्करणों में इन क्रेडेंशियल को अपेक्षित authorization server से बाँधने के लिए `issuer=` विकल्प नहीं था।	अपग्रेड के बाद `issuer=` स्पष्ट रूप से सेट करें। 1.x के deprecated `RFC7523OAuthClientProvider` से माइग्रेट करें।
SDK से बना server, stdio client, या अपना token/header देने वाला client	इस advisory के अनुसार प्रभावित नहीं।	इस खास दोष के लिए कार्रवाई आवश्यक नहीं; यदि ऐप प्रभावित HTTP OAuth client भी उपयोग करता है तो फिर से आकलन करें।

मूल कारण विश्लेषण (Root Cause)

इस trust-boundary दोष के दो जुड़े हुए हिस्से थे: प्रभावित discovery paths authorization-server metadata के issuer की तुलना MCP server से स्वतंत्र रूप से अपेक्षित issuer से हमेशा नहीं करते थे, और सहेजे गए या पहले से उपलब्ध credentials अपने निर्धारित issuer से बंधे नहीं थे। इसलिए दुर्भावनापूर्ण या compromised MCP server token exchange को अपने नियंत्रण वाले endpoint की ओर मोड़कर client के OAuth material तक पहुँच सकता था। सुधार discovery से पहले अपेक्षित issuer तय करते हैं, mismatch को अस्वीकार करते हैं और stored registrations को उसी issuer से बाँधते हैं; unattended machine-to-machine providers में स्पष्ट issuer= भी आवश्यक है।^{[1], [2]}

सोर्स कोड: कमज़ोर बनाम सुरक्षित कार्यान्वयन

ठीक किए गए SDK में issuer तर्क उपलब्ध है। यह मशीन-टू-मशीन क्रेडेंशियल को सही authorization server से बाँधता है; यह अपग्रेड, पुराने बिना-बँधे पंजीकरण हटाने या संभावित रूप से उजागर क्रेडेंशियल बदलने का विकल्प नहीं है।^{[2], [3], [8]}

सोर्स अंश: mcp.client.auth

कमज़ोर कार्यान्वयन

import os
from mcp.client.auth import ClientCredentialsOAuthProvider

auth = ClientCredentialsOAuthProvider(
    client_id=os.environ["MCP_CLIENT_ID"],
    client_secret=os.environ["MCP_CLIENT_SECRET"],
)

सुरक्षित और सुदृढ़ फ़िक्स

import os
from mcp.client.auth import ClientCredentialsOAuthProvider

auth = ClientCredentialsOAuthProvider(
    client_id=os.environ["MCP_CLIENT_ID"],
    client_secret=os.environ["MCP_CLIENT_SECRET"],
    issuer=os.environ["MCP_AUTH_ISSUER"],
)
# mcp >= 1.30.0 (1.x) या >= 2.2.0 (2.x) संस्करण का उपयोग करें।

इंजीनियरिंग और सिस्टम सुरक्षा चेकलिस्ट

✓HTTP MCP क्लाइंट की सूची बनाएँ और ट्रांज़िटिव निर्भरताओं तथा कंटेनर इमेज सहित स्थापित mcp संस्करण जाँचें।^[1]
✓1.x क्लाइंट को mcp 1.30.0 या नए संस्करण पर और 2.x क्लाइंट को 2.2.0 या नए संस्करण पर अपग्रेड करें; लॉकफ़ाइल और तैनात वातावरण सत्यापित करें।^{[1], [3], [8]}
✓ClientCredentialsOAuthProvider और PrivateKeyJWTOAuthProvider में issuer= स्पष्ट रूप से दें; पुराने 1.x RFC7523OAuthClientProvider से माइग्रेट करें, क्योंकि वह विकल्प समर्थित नहीं करता।^{[1], [2]}
✓Issuer बाइंडिंग से पहले के सहेजे गए OAuth पंजीकरण मिटाकर फिर से पंजीकृत करें। स्वयं पहले से पंजीकृत रिकॉर्ड में issuer स्पष्ट सेट करें।^{[1], [2]}
✓FlawOpen का कार्यान्वयन सुझाव: अविश्वसनीय MCP सर्वर को ऐसा भरोसा-सीमा मानें जहाँ क्रेडेंशियल जा सकते हैं। नीति की अनुमति के बिना उत्पादन OAuth सीक्रेट या हस्ताक्षर कुंजियों वाले क्लाइंट उनसे न जोड़ें।^[1]
✓यदि प्रभावित क्लाइंट संभवतः अविश्वसनीय सर्वर से जुड़ा था, तो क्लाइंट सीक्रेट बदलें और authorization server पर टोकन रद्द करें।^[1]
✓1.x और 2.x खोज-पथ, issuer mismatch, PRM की अनुपस्थिति, 403 insufficient_scope, issuer-बँधे पंजीकरण और issuer= के बिना मशीन प्रदाताओं के लिए regression परीक्षण जोड़ें।^[2]
✓अन्य क्लाइंट को प्रभावित घोषित करने से पहले advisory का दायरा जाँचें: SDK से बने सर्वर, stdio क्लाइंट और अपने token या header देने वाले क्लाइंट प्रभावित नहीं हैं।^[1]

स्रोत

← AI Security Directory →