SSRF in Azure MCP Server kan het managed identity-token naar een URL lekken

Microsoft heeft CVE-2026-26118 op 10 maart 2026 gepubliceerd: een server-side request forgery-kwetsbaarheid in Azure MCP Server Tools, het pakket waarmee AI-agenten en MCP-clients in natuurlijke taal op Azure-resources kunnen handelen. Een aanvaller die met een door MCP ondersteunde agent kan communiceren, zou een kwaadaardige URL kunnen indienen in plaats van een normale Azure-resource-identificatie; de server zou dan een uitgaand verzoek naar dat adres sturen en, in de woorden van Microsoft, “mogelijk zijn managed identity-token meesturen” — waardoor de aanroeper een referentie krijgt die hij nooit had mogen zien. Microsoft kende de kwetsbaarheid CVSS 8.8 toe en beoordeelde deze als Important; de pakketten met de oplossing zijn 1.0.2 en 2.0.0-beta.17. Het advies vermeldt geen misbruik en geen openbare bekendmaking vóór de patch, en er is geen echte schade voor geregistreerd. Dit incident is één vermelding in het Orca AI Incident Archive, dat het volledige dossier bevat met de aangehaalde bronnen, de ernstgraad en de betrouwbaarheidsbeoordeling.

Wat het advies eigenlijk zegt

De registratie van het Microsoft Security Response Center is beknopt, en bijna elk gepubliceerd detail over deze kwetsbaarheid is daarvan afkomstig of van Microsofts antwoorden op een handvol vervolgvragen. De volledige beschrijving: “Server-side request forgery (ssrf) in Azure MCP Server stelt een geautoriseerde aanvaller in staat privileges te verhogen via een netwerk.” De CVE-registratie reserveerde de identificatie op 11 februari 2026 en maakte die openbaar op 10 maart om 14:00 UTC; Microsofts releaseopmerking en NVD's vermelding dragen beide die dag. NVD analyseerde de registratie en publiceerde die om 18:18 UTC dezelfde middag. De enige kennisgeving van een toezichthouder die voor dit artikel werd gevonden, kwam uit Marokko: de maCERT-eenheid van de DGSSI nam CVE-2026-26118 op in een bulletin gedateerd 11 maart 2026, met vermelding van Azure MCP Server Tools onder de getroffen producten op zijn eigen risiconiveau Important, zonder afzonderlijke score en met een verwijzing terug naar Microsofts release.

De zwakheid is toegewezen aan CWE-918, server-side request forgery, en de impactclassificatie is verhoging van privileges. Microsofts basisscore is 8,8 op de vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, met een temporele score van 7,7 op E:U/RL:O/RC:C — de E:U-component betekent dat er bij Microsoft geen exploitcode bekend was toen de score werd vastgesteld, en RL:O betekent dat er een officiële oplossing beschikbaar was. NVD hanteert dezelfde basisscore en classificeert deze als Hoog; Microsofts eigen drietrapsschaal noemt het Belangrijk.

Twee velden zijn net zo belangrijk als de score. In de registratie van Microsoft staat Uitgebuit: Nee en Openbaar gemaakt: Nee. Het SSVC-beslissingsrecord van CISA bij de NVD-vermelding, met tijdstempel 5 maart 2026, is het eens over de exploitatie — geen — maar beoordeelt de technische impact als totaal en automatiseerbaar als nee. Het FIRST EPSS-model schatte de kans op exploitatie in de komende 30 dagen op ongeveer 1,0%, op het 62,8e percentiel, in een pull van 3 november 2026. Dit is een fout die is gevonden en verholpen, niet een waarvan bekend is dat die is gebruikt.

Hoe een resource-identificatie een uitgaand verzoek wordt

Azure MCP Server is Microsofts implementatie van het Model Context Protocol, de interface die AI-agents gebruiken om tools aan te roepen. De tools ervan nemen de parameters die een agent opgeeft — een opslagaccountnaam, een abonnement-id, een databasenaam — en zetten die om in aanroepen naar de beheer- en gegevensvlakken van Azure. In de documentatie van Microsoft staat dat de server zich via Entra ID verifieert met “uw Azure-gebruikersreferenties of beheerde identiteit”, waarbij toegang wordt begrensd door op rollen gebaseerd toegangsbeheer van Azure.

De fout zit op het punt waar een parameter die een Azure-resource zou moeten benoemen, in plaats daarvan als URL wordt geaccepteerd. Microsofts eigen uitleg: een aanvaller "zou dit probleem kunnen misbruiken door speciaal vervaardigde invoer te sturen naar een Azure Model Context Protocol (MCP) Server-tool die door de gebruiker verstrekte parameters accepteert. Als de aanvaller kan communiceren met de MCP-ondersteunde agent, kan hij een kwaadaardige URL indienen in plaats van een normale Azure-resource-identificatie." De server stuurt het verzoek vervolgens naar waar hem dat is opgedragen, in plaats van naar waar de tool het bedoelde.

Wat van een hinderlijk probleem een privilege-escalatie maakt, is wat er meelift. Microsoft zegt dat de uitgaande aanvraag “het token van zijn beheerde identiteit kan bevatten”, waardoor de aanvaller dat token kan bemachtigen “zonder administratieve toegang te vereisen.” Een token voor een beheerde identiteit is een bearer-credential: iedereen die het heeft, kan het aanbieden aan de Azure-services waarvoor die identiteit is geautoriseerd, totdat het verloopt. De mitigerende helft van dezelfde alinea is net zo belangrijk — de aanvaller verkrijgt “de machtigingen die aan de beheerde identiteit van de MCP-server zijn gekoppeld” en “krijgt”, in de woorden van Microsoft, “geen bredere machtigingen op tenantniveau of beheerdersmachtigingen; alleen die welke aan de gecompromitteerde beheerde identiteit zijn gekoppeld.” Het schadebereik is alles wat iemand aan die identiteit heeft toegekend, wat in de praktijk vaak meer is dan één enkele tool nodig had.

Microsoft noemt het getroffen hulpprogramma of de parameter niet, en geen enkele bron die voor dit artikel is bekeken, doet dat wel. Die weglating is zelf een detail: de waarschuwing beschrijft een klasse van hulpprogramma's — een dat door de gebruiker opgegeven parameters accepteert en ertoe kan worden gebracht een URL op te halen — in plaats van één enkel endpoint.

De fix, en de pakketten die hem meebrachten

Dit was geen Windows-update. Azure MCP Server Tools worden geleverd als een NuGet-pakket voor .NET, een npm-pakket en een Python-pakket op PyPI, en de oplossing is een versieverhoging in het pakket dat een implementatie gebruikt. In het advies van Microsoft worden de getroffen bereiken vermeld als 1.0.0 tot maar niet inclusief 1.0.2, en 2.0.0-beta.1 tot maar niet inclusief 2.0.0-beta.17, binnen de NuGet-, npm- en PyPI-distributies.

Uit de datums in het npm-register blijkt dat de gecorrigeerde builds al in het register stonden vóór het advies. Versie 1.0.2 van @azure/mcp werd gepubliceerd op 6 maart 2026, vier dagen voordat de CVE openbaar werd; 2.0.0-beta.17 werd gepubliceerd op 6 februari 2026, vijf dagen voordat Microsoft de CVE-identificatie reserveerde en een maand voordat het advies verscheen. Wat de volgorde binnen Microsoft ook was, de gepatchte code is niet geschreven als reactie op de publicatiedag. NVD en de adviesdatabase van GitHub zijn het eens over die bovengrenzen. Ze verschillen licht aan de onderkant van het PyPI-bereik — NVD zegt 2.0.0-beta.1, het GitHub-advies zegt 2.0.0b14 — een discrepantie die beide records sinds publicatie bevatten en die alleen van invloed is op hoe ver terug een Python-implementatie moet kijken.

Het advies zelf werd op 20 maart 2026 herzien, tien dagen na publicatie, met een opmerking dat Microsoft “producten had toegevoegd aan de tabel Beveiligingsupdates die de verschillende verpakkingsmethoden documenteren die worden gebruikt om Azure MCP Server Tools te leveren.” Met andere woorden, de eerste versie van het advies noemde het product wel, maar niet elk kanaal waarlangs het werd verspreid, wat van belang is wanneer de remediëring “het pakket upgraden” is in plaats van “deze KB installeren.”

Wat is niet vastgesteld

Wie heeft het gevonden.Noch de advisory van Microsoft, noch het CVE.org-record vermeldt een melder; het veld credits op de CVE is leeg. Dat is geen bewijs dat niemand privé werd gecrediteerd, alleen dat er geen publieke vermelding bestaat.

Enige exploitatie.Microsoft registreert niets, de SSVC-beoordeling van CISA is het daarmee eens, en geen enkele voor dit artikel geraadpleegde bron beschrijft een gecompromitteerde identiteit in het wild. Het real-harm-veld van het record is false, in overeenstemming daarmee. Een lage EPSS is een voorspelling, geen bevinding, en het ontbreken van een gemeld incident is geen bewijs dat er geen heeft plaatsgevonden.

Of er een publieke exploit bestaat. Hier splitst de secundaire berichtgeving zich. Een bericht uit maart 2026 op de blog van Blueinfy stelt dat er “publieke proof-of-concept-exploits, zoals die op GitHub” bestaan en waarschuwt voor “snelle weaponisering”, maar geeft geen link, payload of walkthrough en toont de kwetsbaarheid niet aan. Uit Microsofts gegevens blijkt dat de kwetsbaarheid niet openbaar is gemaakt vóór de patch. Een zoekopdracht in GitHub-repositories naar de CVE-identificatie op 4 november 2026 leverde één repository op — een Microsoft Sentinel-detectielab gepubliceerd op 17 maart 2026, geen exploit — en Mallory's kwetsbaarheidspagina stelt dat twee kandidaat-exploits zijn gescreend en afgewezen. De bewering dat er werkende publieke exploitcode bestaat, is op basis van het beschikbare bewijs niet onderbouwd; de bewering dat niemand het heeft geprobeerd, is evenzeer onbewezen.

De framing. Een pagina op PolicyLayer, een site van een leverancier met incidentoverzichten, herkadert CVE-2026-26118 als een ongeauthenticeerde remote-code-execution-keten die eindigt in volledige overname van de tenant, met vermelding van een bij naam genoemde onderzoeker en een demonstratie op RSAC 2026. De eigen aangehaalde bronnen van die pagina hebben SSRF in de titel, de data ervan zijn niet te rijmen met de CVE-tijdlijn, en noch in Microsofts advies, noch in de berichtgeving van SecurityWeek van 10 maart wordt code-execution beschreven. Dit artikel beschouwt de SSRF-en-token-versie als de gevestigde en herhaalt de RCE-framing niet.

Waarom de token, en niet het verzoek, de bevinding is

Server-side request forgery is een van de oudste klassen van bugs in websoftware, en op zichzelf is het meestal een manier om systemen te bereiken die de aanvaller niet rechtstreeks kan aanspreken. Wat dit record de moeite waard maakt om te bewaren, is de referentie die aan het verzoek is gekoppeld. De MCP-server is ontworpen als een confused deputy: hij heeft een identiteit zodat een agent namens een gebruiker kan handelen, en elke parameter die een agent doorgeeft is vanuit het perspectief van de server door de aanvaller beïnvloede tekst. Wanneer een van die parameters een bestemming wordt in plaats van een naam, draagt de deputy zijn eigen autorisatie naar die bestemming.

De documentatie van Microsoft maakt preciezer waar dat risico zich concentreert. Ze beschrijft de lokale server als “uitsluitend bedoeld voor gebruik door ontwikkelaars binnen uw organisatie,” terwijl ze afzonderlijk implementatiehandleidingen publiceert voor zelfgehoste externe servers in Microsoft Foundry en Copilot Studio — de configuraties waarin doorgaans een managed identity, en niet de eigen aanmelding van een ontwikkelaar, de gebruikte referentie is. Het pad voor tokendiefstal in het beveiligingsadvies gaat specifiek over de managed identity. Er staat niet in dat elke installatie blootgesteld was, en ook niet hoeveel er dat waren.

De algemene les is wat OWASP's AI Security Verification Standard nu met deze casus wil overbrengen. Het orchestratiehoofdstuk van AISVS noemt CVE-2026-26118 bij zijn uitgewerkte voorbeelden en trekt de conclusie dat “MCP-toolparameters moeten worden behandeld als door aanvallers beheerst, en uitgaande verzoeken van MCP-servers moeten door hetzelfde egress- en origin-beleid gaan als verwacht voor elke andere door agents aangestuurde I/O.” Dat is een aanbeveling voor een beheersmaatregel, geen bevinding over dit incident, maar het is het meest concrete antwoord dat iemand heeft gepubliceerd op de vraag wat er moet veranderen.

Wat is er veranderd na

Drie dingen, en geen ervan is dramatisch. Microsoft heeft in alle drie ecosystemen gepatchte pakketten uitgebracht en het advies herzien om ze bij naam te noemen. Het ecosysteem voor kwetsbaarheidsinformatie absorbeerde het geruisloos: een lage EPSS-score en een NVD-record dat voor het laatst op 17 juni 2026 is gewijzigd. En de standaardencommunity adopteerde het als lesvoorbeeld, wat een langzamere en duurzamere vorm van respons is dan een patch.

Voor iedereen die nog steeds een getroffen build draait, is de remediatie onveranderd en weinig glamoureus: stap over op 1.0.2 of later op de stabiele lijn, of 2.0.0-beta.17 of later op de previewlijn, in elke pakketbeheerder die de deployment raakt. Daarnaast impliceren de eigen logica van het advies drie maatregelen: beperk waartoe de server uitgaand verbinding kan maken, geef de beheerde identiteit alleen de rollen die haar tools daadwerkelijk nodig hebben, en behandel elke toolparameter die een URL kan worden als vijandige invoer. Geen van deze maatregelen is nodig geweest om CVE-2026-26118 te overleven. Elk ervan zou de waarde van de volgende voor een aanvaller verkleinen.

Hoe het archief deze classificeert

Het record is geregistreerd als een kwetsbaarheid — iets dat is gevonden, niet iets waarvan bekend is dat het is misbruikt — met betrouwbaarheidsgraad A, wat betekent dat het goed gedocumenteerd is en primaire bronnen het eens zijn, en het is niet gemarkeerd als betwist. Het veld voor werkelijke schade staat op false en de AI-betrokkenheid is bevestigd, omdat het getroffen product de brug is tussen een AI-agent en een cloudcontrol-plane, en niet een algemene dienst die toevallig in de buurt zit. De datum is vastgelegd met dagprecisie, 10 maart 2026, zonder einddatum, omdat dit een enkel moment in de tijd is en geen campagne. De regio is wereldwijd en de landmark-vlag staat op false.

Eén veld wordt anders weergegeven dan de gepubliceerde scoring. De ernst in het archief staat geregistreerd als medium, op zijn eigen schaal; het getal dat zowel Microsoft als NVD publiceren is 8,8, dat Microsoft Important noemt en NVD als High classificeert. De samenvatting van het record begint met dat 8,8, en het verschil zit in de indeling in categorieën, niet in de feiten.

Wat het verslag niet kan overbrengen, is hoeveel van dit verhaal een afwezigheid is. Er is een fout die een cloudidentiteit geeft aan wie er ook maar in de verkeerde vorm om vraagt. Er is een oplossing, uitgebracht vóór de aankondiging. Er is geen erkende ontdekker, geen genoemd hulpmiddel, geen bevestigde exploitatie en geen manier voor een buitenstaander om te weten of een gehoste implementatie ooit een kwetsbare build heeft gedraaid terwijl die een machtige identiteit bezat. Het beveiligingsadvies is precies over wat de fout doet en zwijgt over bijna al het andere, en dat zwijgen is het nuttigste dat eraan op te merken valt.