అధికారిక 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 బగ్గా కాకుండా క్రెడెన్షియల్-బౌండరీ వైఫల్యంగా అర్థం చేసుకోవడం సరైనది.
Figure 1కి అందుబాటులో ఉండే టెక్స్ట్ ప్రత్యామ్నాయం
ఆశించిన ఫ్లో: 1. MCP క్లయింట్ ఒక ఆథరైజేషన్ సర్వర్ కోసం క్రెడెన్షియల్ కలిగి ఉంటుంది. 2. ఆశించిన ఇష్యూయర్, క్లయింట్కు తాను ఏ ఇష్యూయర్ను నమ్ముతుందో ముందే తెలుసు. 3. ఆథరైజేషన్ సర్వర్ వాలిడేట్ చేయబడింది, డిస్కవర్ చేసిన మెటాడేటాను దానికి వ్యతిరేకంగా చెక్ చేస్తారు. 4. నమ్మదగిన టోకెన్ ఎండ్పాయింట్, ఐడెంటిటీ సరిపోలినప్పుడే క్రెడెన్షియల్ పంపబడుతుంది. విఫలమైన ఫ్లో: 1. MCP క్లయింట్ ఒక ఆథరైజేషన్ సర్వర్ కోసం క్రెడెన్షియల్ కలిగి ఉంటుంది. 2. MCP సర్వర్ గమ్యస్థానాన్ని ప్రభావితం చేస్తుంది, ఆథరైజేషన్ ఎక్కడ జరగాలో ప్రకటిస్తూ. 3. క్లయింట్ ఆ గమ్యస్థానాన్ని అంగీకరిస్తుంది, ఇష్యూయర్ను ఎప్పుడూ స్వతంత్రంగా చెక్ చేయలేదు. 4. దాడి చేసేవాడు నియంత్రించే ఎండ్పాయింట్, క్రెడెన్షియల్ కేవలం దుర్వినియోగం కాకుండా బహిర్గతమవుతుంది.
issuer దేన్ని రక్షిస్తుంది?
OAuth పరిభాష దీన్ని అవసరమైన దానికంటే ఎక్కువ సంక్లిష్టంగా అనిపించేలా చేయగలదు.
ఈ చర్చ కోసం, issuer ఒక ప్రాక్టికల్ ప్రశ్నకు సమాధానం ఇస్తుంది:
ఈ సంబంధం కోసం మనం ఏ ఆథరైజేషన్ సర్వర్ను నమ్ముతాము?
ఒక క్లయింట్ సీక్రెట్ auth.example.comకు చెందినదని అనుకోండి.
ఆ తర్వాత క్లయింట్ ఒక MCP సర్వర్కు కనెక్ట్ అవుతుంది, ఇది ఆథెంటికేషన్ను వేరే ఆథరైజేషన్ సర్వర్ వైపు మళ్లించడానికి ప్రయత్నిస్తుంది.
చెల్లుబాటు అయ్యేలా కనిపించే OAuth మెటాడేటా ఉండటం మాత్రమే సరిపోకూడదు.
క్లయింట్కు ఒక స్వతంత్ర ఆశయం ఉండాలి, అదేమిటంటే ఈ క్రెడెన్షియల్ ఈ ఇష్యూయర్కు చెందినది.
ఫిక్స్ చేయబడిన SDK, ఆథరైజేషన్-సర్వర్ మెటాడేటాను ప్రాసెస్ చేసే ముందు ఆశించిన ఇష్యూయర్ను నిర్ధారిస్తుంది, వేరే ఇష్యూయర్ ఉన్న మెటాడేటాను తిరస్కరిస్తుంది, మరియు స్టోర్ చేయబడిన రిజిస్ట్రేషన్లను ఆ ఇష్యూయర్కు బైండ్ చేస్తుంది.
జూలై 2026 MCP స్పెసిఫికేషన్ కూడా అదే సూత్రాన్ని బలపరుస్తుంది. ఆథరైజేషన్ సర్వర్ మారినప్పుడు తిరిగి ఉపయోగించే బదులు, పర్సిస్ట్ చేయబడిన క్లయింట్ క్రెడెన్షియల్స్ అవి చెందిన ఆథరైజేషన్ సర్వర్తో అనుబంధించబడి ఉండాలి.
నిజంగా ఎవరు ప్రభావితమవుతారు?
ప్రతి MCP క్లయింట్ లేదా సర్వర్ వల్నరబుల్ అని ఈ సమస్య అర్థం కాదు.
ఈ రెండు షరతులు నిజమైనప్పుడు అడ్వైజరీ వర్తిస్తుంది.
- అప్లికేషన్ ప్రభావితమైన బిల్ట్-ఇన్ OAuth ప్రొవైడర్లలో ఒకదాన్ని ఉపయోగించి HTTP ద్వారా MCP క్లయింట్గా Python SDKని వాడుతుంది.
- క్లయింట్, ఒక చెల్లుబాటు అయ్యే ఆథరైజేషన్ సర్వర్ కోసం క్రెడెన్షియల్స్ కలిగి ఉండగానే, తాను పూర్తిగా నమ్మని ఒక MCP సర్వర్కు కనెక్ట్ కావచ్చు.
ప్రభావితమైన ప్రొవైడర్లలో OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, మరియు నిలిపివేయబడిన 1.x RFC7523OAuthClientProvider ఉన్నాయి.
SDKని ఉపయోగించి నిర్మించిన MCP సర్వర్లను, stdio క్లయింట్లను, లేదా ప్రభావితమైన OAuth హ్యాండ్లర్లను ఉపయోగించే బదులు తమ సొంత టోకెన్లను లేదా హెడర్లను జోడించే క్లయింట్లను ఈ సమస్య ప్రభావితం చేయదు అని అడ్వైజరీ నిర్దిష్టంగా చెబుతుంది.
| 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 సర్వీస్ కోసం ఉద్దేశించబడింది?
Figure 2కి అందుబాటులో ఉండే టెక్స్ట్ ప్రత్యామ్నాయం
ఆరు-దశల చైన్: 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 Security Advisory 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 సెక్యూరిటీ రిస్క్లను కవర్ చేసే అదనపు గైడెన్స్.