Azure MCP Servers SSRF kan läcka dess token för hanterad identitet till en URL

Microsoft publicerade CVE-2026-26118 den 10 mars 2026: en server-side request forgery-sårbarhet i Azure MCP Server Tools, paketet som låter AI-agenter och MCP-klienter utföra åtgärder på Azure-resurser i naturligt språk. En angripare som kan interagera med en MCP-baserad agent skulle kunna skicka en skadlig URL i stället för en normal Azure-resursidentifierare; servern skulle då skicka en utgående begäran till den adressen och, enligt Microsofts ord, ”kan inkludera sin hanterade identitetstoken” – vilket ger anroparen en autentiseringsuppgift som den aldrig var avsedd att se. Microsoft gav sårbarheten CVSS 8.8 och klassade den som viktig, och paketen som innehåller korrigeringen är 1.0.2 och 2.0.0-beta.17. Säkerhetsrådgivningen registrerar ingen exploatering och inget offentliggörande före patchen, och ingen faktisk skada har registrerats för den. Den här incidenten är en post i Orca AI Incident Archive, som innehåller den fullständiga dokumentationen med dess citerade källor, allvarlighetsgrad och bedömning av tillförlitlighet.

Vad rådgivningen faktiskt säger

Posten från Microsoft Security Response Center är kortfattad, och nästan varje publicerad detalj om denna sårbarhet härstammar från den eller från Microsofts svar på en handfull uppföljningsfrågor. Beskrivningen i sin helhet: ”Server-side request forgery (SSRF) i Azure MCP Server gör det möjligt för en behörig angripare att höja privilegier över ett nätverk.” CVE-posten reserverade identifieraren den 11 februari 2026 och offentliggjorde den den 10 mars kl. 14.00 UTC; både Microsofts utgivningsmeddelande och NVD:s post anger det datumet. NVD analyserade posten och publicerade den kl. 18.18 UTC samma eftermiddag. Det enda tillsynsmeddelande som hittades för den här artikeln kom från Marocko: DGSSI:s enhet maCERT tog upp CVE-2026-26118 i en bulletin daterad den 11 mars 2026, där Azure MCP Server Tools listades bland berörda produkter med sin egen risknivå Important, utan separat poäng och med en hänvisning tillbaka till Microsofts utgivningsmeddelande.

Svagheten mappas till CWE-918, förfalskning av serversidesförfrågan, och påverkansklassificeringen är utökning av privilegier. Microsofts baspoäng är 8,8 på vektorn CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, med en temporal poäng på 7,7 på E:U/RL:O/RC:C — komponenten E:U innebär att ingen exploateringskod var känd för Microsoft när poängen fastställdes, och RL:O innebär att en officiell korrigering fanns tillgänglig. NVD har samma baspoäng och klassar den som Hög; Microsofts egen trestegsskala betecknar den som Viktig.

Två fält är lika viktiga som poängen. Microsofts register anger Utnyttjad: Nej och Offentligt avslöjad: Nej. CISA:s SSVC-beslutsprotokoll för NVD-posten, tidsstämplat 5 mars 2026, instämmer om utnyttjande — inget — samtidigt som den bedömer teknisk påverkan som total och automatiserbarheten som nej. FIRST EPSS-modellen satte sannolikheten för utnyttjande under de kommande 30 dagarna till ungefär 1,0 %, vid 62,8:e percentilen, i en hämtning daterad 3 november 2026. Detta är en brist som hittades och åtgärdades, inte en som är känd för att ha använts.

Hur en resursidentifierare blir en utgående förfrågan

Azure MCP Server är Microsofts implementering av Model Context Protocol, det gränssnitt som AI-agenter använder för att anropa verktyg. Dess verktyg tar de parametrar som en agent tillhandahåller — ett lagringskontonamn, en prenumerationsidentifierare, ett databasnamn — och omvandlar dem till anrop mot Azures hanterings- och dataplan. Microsofts dokumentation beskriver servern som autentiserande via Entra ID med "dina Azure-användaruppgifter eller hanterad identitet", med åtkomst begränsad av Azures rollbaserade åtkomstkontroll.

Felet ligger vid den punkt där en parameter som borde ange en Azure-resurs i stället accepteras som en URL. Microsofts egen förklaring: en angripare ”skulle kunna utnyttja problemet genom att skicka specialutformat indata till ett Azure Model Context Protocol (MCP) Server-verktyg som accepterar användartillhandahållna parametrar. Om angriparen kan interagera med den MCP-backade agenten kan de skicka en skadlig URL i stället för en normal Azure-resursidentifierare.” Servern skickar då begäran dit den instruerades att skicka den, i stället för dit verktyget avsåg.

Det som förvandlar en olägenhet till en privilegieeskalering är det som följer med. Microsoft säger att den utgående begäran ”kan innehålla dess token för hanterad identitet”, vilket gör att angriparen kan fånga den token ”utan att kräva administrativ åtkomst”. En token för hanterad identitet är ett bearer-intyg: den som innehar den kan visa upp den för de Azure-tjänster som identiteten är auktoriserad för, tills den går ut. Den mildrande andra halvan av samma stycke är minst lika viktig – angriparen får ”de behörigheter som är kopplade till MCP-serverns hanterade identitet” och, med Microsofts ord, ”får inte bredare behörigheter på klientorganisationsnivå eller administratörsbehörigheter; endast de som är knutna till den komprometterade hanterade identiteten”. Skadeomfånget är allt som någon har beviljat den identiteten, vilket i praktiken ofta är mer än vad ett enda verktyg behövde.

Microsoft anger inte namnet på det berörda verktyget eller parametern, och ingen källa som granskats för den här artikeln gör det. Att det utelämnas är i sig en detalj: rådgivningen beskriver en typ av verktyg – ett som tar emot parametrar som tillhandahålls av användaren och kan förmås att hämta en URL – snarare än en enda slutpunkt.

Rättningen, och paketen som innehöll den

Detta var inte en Windows-uppdatering. Azure MCP Server Tools levereras som ett NuGet-paket för .NET, ett npm-paket och ett Python-paket på PyPI, och åtgärden är att höja versionen i det paket som en driftsättning använder. Microsofts säkerhetsbulletin listar de påverkade intervallen som 1.0.0 upp till men exklusive 1.0.2, och 2.0.0-beta.1 upp till men exklusive 2.0.0-beta.17, i NuGet-, npm- och PyPI-distributionerna.

Datumuppgifterna i npm-registret visar att de korrigerade byggena fanns i registret före säkerhetsmeddelandet. Version 1.0.2 av @azure/mcp publicerades den 6 mars 2026, fyra dagar innan CVE:n blev offentlig; 2.0.0-beta.17 publicerades den 6 februari 2026, fem dagar innan Microsoft reserverade CVE-identifieraren och en månad innan säkerhetsmeddelandet dök upp. Hur sekvensen än såg ut inne på Microsoft skrevs den patchade koden inte som svar på publiceringsdagen. NVD och GitHubs rådgivningsdatabas är överens om dessa övre gränser. De skiljer sig något åt i den nedre änden av PyPI-intervallet – NVD anger 2.0.0-beta.1, GitHubs säkerhetsmeddelande anger 2.0.0b14 – en avvikelse som de två posterna har haft sedan publiceringen och som bara påverkar hur långt bakåt en Python-driftsättning behöver titta.

Själva säkerhetsmeddelandet reviderades den 20 mars 2026, tio dagar efter publiceringen, med en notering om att Microsoft hade ”lagt till produkter i tabellen över säkerhetsuppdateringar som dokumenterar de olika paketeringsmetoder som används för att leverera Azure MCP Server Tools.” Med andra ord namngav den första versionen av säkerhetsmeddelandet produkten men inte alla kanaler den levererades via, vilket spelar roll när åtgärden är att ”uppgradera paketet” i stället för att ”installera den här KB:n.”

Vad som inte är fastställt

Vem hittade det.Varken Microsofts rådgivning eller CVE.org-posten namnger en rapportör; fältet för erkännanden i CVE-posten är tomt. Det är inte bevis för att ingen har fått erkännande privat, bara att det inte finns något offentligt erkännande.

Någon exploatering.Microsoft registrerar inga fall, CISA:s SSVC-bedömning instämmer, och ingen källa som granskats för den här artikeln beskriver en komprometterad identitet i verkligheten. Postens fält för faktisk skada är false, vilket stämmer med det. Lågt EPSS är en prognos, inte ett fynd, och avsaknaden av en rapporterad incident är inte bevis för att ingen har inträffat.

Huruvida en offentlig exploit existerar. Det är här de sekundära källorna går isär. Ett inlägg från mars 2026 på Blueinfys blogg uppger att det finns ”offentliga proof-of-concept-exploater, som de på GitHub” och varnar för ”snabb vapenisering”, men ger ingen länk, ingen payload och ingen genomgång, och demonstrerar inte sårbarheten. Microsofts dokumentation säger att sårbarheten inte var offentligt avslöjad före patchen. En sökning i GitHub-förråd efter CVE-identifieraren den 4 november 2026 gav ett enda förråd – ett Microsoft Sentinel-detekteringslabb publicerat den 17 mars 2026, inte en exploit – och Mallorys sårbarhetssida anger att två kandidat-exploater granskades och avvisades. Påståendet om fungerande offentlig exploitkod är, utifrån tillgängliga bevis, obestyrkt; påståendet att ingen har försökt är lika obevisat.

Vinklingen. En sida på PolicyLayer, en leverantörssajt för incidentsammanfattningar, framställer CVE-2026-26118 som en oautentiserad kedja för fjärrkodkörning som slutar i fullständigt övertagande av tenanten, och tillskriver en namngiven forskare och en demonstration vid RSAC 2026. Sidans egna citerade källor är betitlade som SSRF, dess datum stämmer inte överens med CVE-tidslinjen, och varken Microsofts rådgivning eller SecurityWeeks rapportering från 10 mars beskriver kodkörning. Den här artikeln behandlar SSRF- och tokenredogörelsen som den etablerade och upprepar inte RCE-inramningen.

Varför token, och inte förfrågan, är fyndet

Server-side request forgery är en av de äldsta buggklasserna i webbprogramvara, och i sig själv är det vanligtvis ett sätt att nå system som angriparen inte kan adressera direkt. Det som gör den här posten värd att behålla är autentiseringsuppgiften som är kopplad till begäran. MCP-servern är en confused deputy redan i sin konstruktion: den har en identitet så att en agent kan agera på en användares vägnar, och varje parameter som en agent skickar är, ur serverns perspektiv, text som angriparen kan påverka. När en av dessa parametrar blir en destination i stället för ett namn, bär ställföreträdaren med sig sin egen auktorisering till destinationen.

Microsofts dokumentation förtydligar var den risken koncentreras. Den beskriver den lokala servern som ”avsedd strikt för utvecklaranvändning inom din organisation”, samtidigt som den separat publicerar distributionsguider för självhostade fjärrservrar i Microsoft Foundry och Copilot Studio – de konfigurationer där en hanterad identitet, snarare än utvecklarens egen inloggning, vanligtvis är den autentiseringsuppgift som används. Rådgivningens väg för tokenstöld handlar specifikt om den hanterade identiteten. Den säger inte att varje installation var exponerad, och den säger inte hur många som var det.

Den generella lärdomen är den som OWASP:s AI Security Verification Standard nu använder fallet för att lära ut. AISVS-kapitlet om orkestrering nämner CVE-2026-26118 bland sina genomarbetade exempel och drar slutsatsen att ”MCP-verktygsparametrar måste behandlas som angriparkontrollerade, och utgående förfrågningar från MCP-servrar måste gå genom samma egress- och originprinciper som förväntas för alla andra agentdrivna I/O.” Det är en rekommendation om kontrollåtgärd, inte ett fynd om den här incidenten, men det är det mest konkreta svar som någon har publicerat på frågan om vad som bör ändras.

Vad förändrades efter

Tre saker, och ingen av dem är dramatisk. Microsoft levererade åtgärdade paket i alla tre ekosystemen och reviderade rådgivningen för att namnge dem. Ekosystemet för sårbarhetsunderrättelser tog emot det tyst: ett lågt EPSS-värde och en NVD-post som senast ändrades den 17 juni 2026. Och standardiseringsgemenskapen antog det som ett undervisningsexempel, vilket är en långsammare och mer hållbar form av respons än en patch.

För alla som fortfarande kör en påverkad build är åtgärden oförändrad och oglamorös: gå över till 1.0.2 eller senare på stable-linjen, eller 2.0.0-beta.17 eller senare på preview-linjen, i varje pakethanterare som driftsättningen berör. Utöver det antyder rådets egen logik tre kontroller – begränsa vad servern kan nå utåt, ge den hanterade identiteten endast de roller som dess verktyg faktiskt behöver, och behandla varje verktygsparameter som kan bli en URL som fientlig indata. Ingen av dem krävdes för att klara sig igenom CVE-2026-26118. Var och en skulle minska vad nästa är värd för en angripare.

Hur arkivet klassificerar den här

Posten är registrerad som en sårbarhet – något som har upptäckts, inte något som är känt för att ha utnyttjats – med konfidensgrad A, vilket innebär väl dokumenterad med primärkällor som stämmer överens, och den är inte markerad som omtvistad. Fältet för faktisk skada är falskt och dess AI-inblandning är bekräftad, eftersom den drabbade produkten är bryggan mellan en AI-agent och ett molnkontrollplan snarare än en allmän tjänst som råkar ligga i närheten. Datumet är registrerat med dagsnoggrannhet, 10 mars 2026, utan slutdatum, eftersom detta är en enskild tidpunkt snarare än en kampanj. Regionen är global och landmärkesflaggan är falsk.

Ett fält anger något annat än den publicerade poängsättningen. Arkivets allvarlighetsgrad registreras som medium enligt dess egen skala; siffran som både Microsoft och NVD publicerar är 8.8, vilken Microsoft kallar Important och NVD klassar som High. Sammanfattningen för posten inleds med den siffran 8.8, och avvikelsen är en skillnad i kategorisering snarare än i fakta.

Det som registret inte kan förmedla är hur mycket av den här historien som är en frånvaro. Det finns en brist som överlämnar en molnidentitet till vem som helst som ber om den i fel form. Det finns en rättning som släpptes före tillkännagivandet. Det finns ingen krediterad upptäckare, inget namngivet verktyg, ingen bekräftad exploatering och inget sätt för en utomstående att avgöra huruvida någon hostad driftsättning någonsin körde en sårbar byggversion medan den hade en kraftfull identitet. Säkerhetsmeddelandet är exakt om vad bristen gör och tyst om nästan allt annat, och den tystnaden är det mest användbara att lägga märke till hos det.