SSRF im Azure MCP Server könnte dessen Managed Identity-Token an eine URL preisgeben

Microsoft hat am 10. März 2026 CVE-2026-26118 veröffentlicht: eine Server-Side-Request-Forgery-Schwachstelle in Azure MCP Server Tools, dem Paket, mit dem KI-Agenten und MCP-Clients in natürlicher Sprache auf Azure-Ressourcen zugreifen können. Ein Angreifer, der mit einem MCP-gestützten Agenten interagieren kann, könnte anstelle einer normalen Azure-Ressourcenkennung eine schädliche URL übermitteln; der Server würde dann eine ausgehende Anfrage an diese Adresse senden und, mit Microsofts Worten, „möglicherweise sein Managed-Identity-Token einschließen“ – und dem Aufrufer damit ein Credential aushändigen, das er nie hätte sehen sollen. Microsoft bewertete die Schwachstelle mit CVSS 8.8 und stufte sie als Important ein; die Pakete, die den Fix enthalten, sind 1.0.2 und 2.0.0-beta.17. Die Advisory verzeichnet keine Ausnutzung und keine öffentliche Offenlegung vor dem Patch, und es ist kein tatsächlicher Schaden dokumentiert. Dieser Vorfall ist ein Eintrag in dem Orca AI Incident Archive, das den vollständigen Datensatz mit den zitierten Quellen, der Schweregrad-Einstufung und der Konfidenzbewertung enthält.

Was die Warnung tatsächlich aussagt

Der Eintrag des Microsoft Security Response Center ist knapp, und nahezu jedes veröffentlichte Detail zu dieser Schwachstelle stammt daraus oder aus Microsofts Antworten auf eine Handvoll Nachfragen. Die Beschreibung vollständig: „Server-Side Request Forgery (SSRF) in Azure MCP Server ermöglicht es einem autorisierten Angreifer, über ein Netzwerk Rechte zu erweitern.“ Der CVE-Eintrag reservierte die Kennung am 11. Februar 2026 und machte sie am 10. März um 14:00 UTC öffentlich; Microsofts Versionshinweis und der NVD-Eintrag tragen beide dieses Datum. NVD analysierte den Eintrag und veröffentlichte ihn am selben Nachmittag um 18:18 UTC. Der einzige für diesen Artikel gefundene Regulierungsbescheid kam aus Marokko: Die maCERT-Einheit der DGSSI führte CVE-2026-26118 in einem Bulletin vom 11. März 2026 auf, listete Azure MCP Server Tools unter den betroffenen Produkten mit ihrer eigenen Risikostufe „Important“, ohne separate Bewertung und mit einem Verweis zurück auf Microsofts Veröffentlichung.

Die Schwachstelle ist CWE-918 zugeordnet, Server-Side Request Forgery, und die Auswirkungsklassifikation ist Erhöhung von Berechtigungen. Microsofts Basisscore beträgt 8,8 auf dem Vektor CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, mit einem temporalen Score von 7,7 auf E:U/RL:O/RC:C — die Komponente E:U bedeutet, dass Microsoft zum Zeitpunkt der Bewertung kein Exploit-Code bekannt war, und RL:O bedeutet, dass eine offizielle Korrektur verfügbar war. NVD führt denselben Basisscore und stuft ihn als High ein; Microsofts eigene dreistufige Skala nennt ihn Important.

Zwei Felder sind ebenso wichtig wie der Score. Microsofts Eintrag besagt Ausgenutzt: Nein und Öffentlich offengelegt: Nein. CISAs SSVC-Entscheidungsdatensatz zum NVD-Eintrag, mit Zeitstempel 5. März 2026, stimmt bei der Ausnutzung zu — keine — während sie die technische Auswirkung als vollständig und die Automatisierbarkeit als nein einstuft. Das FIRST EPSS-Modell bezifferte die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen auf rund 1,0 %, auf dem 62,8. Perzentil, in einem Abruf vom 3. November 2026. Dies ist eine Schwachstelle, die gefunden und behoben wurde, nicht eine, die bekanntermaßen ausgenutzt wurde.

Wie aus einer Ressourcenkennung eine ausgehende Anfrage wird

Azure MCP Server ist Microsofts Implementierung des Model Context Protocol, der Schnittstelle, über die KI-Agenten Tools aufrufen. Seine Tools nehmen die von einem Agenten bereitgestellten Parameter – einen Speicherkontonamen, eine Abonnement-ID, einen Datenbanknamen – und wandeln sie in Aufrufe an Azures Verwaltungs- und Datenebenen um. Microsofts Dokumentation beschreibt, dass sich der Server über Entra ID mit „Ihren Azure-Benutzeranmeldeinformationen oder einer verwalteten Identität“ authentifiziert, wobei der Zugriff durch Azure role-based access control beschränkt wird.

Der Fehler liegt an der Stelle, an der ein Parameter, der eine Azure-Ressource benennen sollte, stattdessen als URL akzeptiert wird. Microsofts eigene Erklärung: Ein Angreifer „könnte dieses Problem ausnutzen, indem er speziell gestaltete Eingaben an ein Azure Model Context Protocol (MCP) Server-Tool sendet, das benutzerbereitgestellte Parameter akzeptiert. Wenn der Angreifer mit dem MCP-gestützten Agenten interagieren kann, kann er eine bösartige URL anstelle einer normalen Azure-Ressourcenkennung übermitteln.“ Der Server sendet die Anfrage dann dorthin, wohin er angewiesen wurde, statt dorthin, wohin das Tool sie senden wollte.

Der Teil, der aus einem Ärgernis eine Rechteausweitung macht, ist das, was mitgeschickt wird. Microsoft zufolge „kann die ausgehende Anforderung ihr Token für die verwaltete Identität enthalten“, wodurch der Angreifer dieses Token „ohne administrativen Zugriff zu benötigen“ abgreifen kann. Ein Token für eine verwaltete Identität ist ein Bearer-Credential: Wer es besitzt, kann es den Azure-Diensten vorlegen, für die diese Identität autorisiert ist, bis es abläuft. Die entschärfende Hälfte desselben Absatzes ist ebenso wichtig – der Angreifer erlangt „die Berechtigungen, die der verwalteten Identität des MCP Servers zugeordnet sind“, und erhält, mit Microsofts Worten, „keine umfassenderen Berechtigungen auf Mandantenebene oder Administratorberechtigungen; nur diejenigen, die an die kompromittierte verwaltete Identität gebunden sind“. Die Tragweite ist alles, was jemand dieser Identität gewährt hat, was in der Praxis oft mehr ist, als ein einzelnes Tool benötigt hat.

Microsoft nennt das betroffene Tool oder den betroffenen Parameter nicht, und keine für diesen Artikel geprüfte Quelle tut dies. Diese Auslassung ist selbst ein Detail: Die Sicherheitsmeldung beschreibt eine Klasse von Tools – eines, das vom Benutzer bereitgestellte Parameter akzeptiert und dazu gebracht werden kann, eine URL abzurufen – statt eines einzelnen Endpunkts.

Die Fehlerbehebung und die Pakete, die sie enthielten

Dies war kein Windows-Update. Azure MCP Server Tools werden als NuGet-Paket für .NET, als npm-Paket und als Python-Paket auf PyPI ausgeliefert, und die Behebung besteht in einer Versionserhöhung in demjenigen Paket, das eine Bereitstellung verwendet. Microsofts Sicherheitshinweis führt die betroffenen Bereiche mit 1.0.0 bis ausschließlich 1.0.2 sowie 2.0.0-beta.1 bis ausschließlich 2.0.0-beta.17 über die NuGet-, npm- und PyPI-Distributionen hinweg auf.

Die Datumsangaben der npm-Registry zeigen, dass die korrigierten Builds vor dem Advisory in der Registry vorhanden waren. Version 1.0.2 von @azure/mcp wurde am 6. März 2026 veröffentlicht, vier Tage bevor die CVE öffentlich wurde; 2.0.0-beta.17 wurde am 6. Februar 2026 veröffentlicht, fünf Tage bevor Microsoft die CVE-Kennung reservierte und einen Monat bevor das Advisory erschien. Wie auch immer die Abfolge innerhalb von Microsoft aussah, der gepatchte Code wurde nicht als Reaktion auf den Veröffentlichungstag geschrieben. NVD und die Advisory-Datenbank von GitHub stimmen bei diesen oberen Grenzen überein. Sie unterscheiden sich geringfügig am unteren Ende des PyPI-Bereichs – NVD nennt 2.0.0-beta.1, das GitHub-Advisory nennt 2.0.0b14 – eine Diskrepanz, die beide Datensätze seit der Veröffentlichung aufweisen und die nur beeinflusst, wie weit zurück eine Python-Bereitstellung blicken muss.

Der Sicherheitshinweis selbst wurde am 20. März 2026, zehn Tage nach der Veröffentlichung, überarbeitet, mit dem Hinweis, dass Microsoft „Produkte zur Tabelle der Sicherheitsupdates hinzugefügt habe, in der die verschiedenen Paketierungsmethoden dokumentiert sind, mit denen Azure MCP Server Tools bereitgestellt werden“. Mit anderen Worten: Die erste Version des Hinweises nannte das Produkt, aber nicht jeden Vertriebskanal, was dann relevant ist, wenn die Behebung „das Paket aktualisieren“ statt „dieses KB installieren“ lautet.

Was ist nicht etabliert?

Wer es gefunden hat. Weder die Microsoft-Sicherheitsempfehlung noch der CVE.org-Eintrag nennen eine meldende Person; das Feld für Danksagungen in der CVE ist leer. Das ist kein Beleg dafür, dass niemand privat genannt wurde, sondern nur dafür, dass es keine öffentliche Nennung gibt.

Jegliche Ausnutzung. Microsoft verzeichnet keine, die SSVC-Bewertung von CISA kommt zum selben Schluss, und keine für diesen Artikel geprüfte Quelle beschreibt eine kompromittierte Identität in freier Wildbahn. Das Feld „real-harm“ des Datensatzes ist falsch, was damit im Einklang steht. Ein niedriger EPSS-Wert ist eine Prognose, kein Befund, und das Fehlen eines gemeldeten Vorfalls ist kein Beweis dafür, dass keiner eingetreten ist.

Ob ein öffentlicher Exploit existiert. Hier teilt sich die Sekundärberichterstattung. Ein Beitrag vom März 2026 in Blueinfys Blog behauptet, es gebe „öffentliche Proof-of-Concept-Exploits, wie die auf GitHub“, und warnt vor einer „schnellen Weaponisierung“, nennt aber weder einen Link noch einen Payload oder eine Schritt-für-Schritt-Anleitung und führt die Schwachstelle nicht vor. Microsofts Aufzeichnungen zufolge wurde die Schwachstelle vor dem Patch nicht öffentlich offengelegt. Eine GitHub-Repository-Suche nach der CVE-Kennung am 4. November 2026 ergab ein Repository – ein am 17. März 2026 veröffentlichtes Microsoft-Sentinel-Detection-Lab, kein Exploit –, und auf Mallorys Schwachstellenseite heißt es, dass zwei mögliche Exploits geprüft und verworfen wurden. Die Behauptung, es gebe funktionsfähigen öffentlichen Exploit-Code, ist nach der verfügbaren Beweislage nicht belegt; die Behauptung, niemand habe es versucht, ist ebenso unbewiesen.

Das Framing. Eine Seite auf PolicyLayer, einer Anbieterseite für Incident-Zusammenfassungen, stellt CVE-2026-26118 als eine nicht authentifizierte Remote-Code-Execution-Kette dar, die in der Übernahme des gesamten Tenants endet, und verweist dabei auf einen namentlich genannten Forscher sowie eine Demonstration auf der RSAC 2026. Die von dieser Seite selbst zitierten Quellen tragen SSRF im Titel, ihre Datumsangaben stimmen nicht mit der CVE-Zeitleiste überein, und weder Microsofts Advisory noch die Berichterstattung von SecurityWeek vom 10. März beschreiben eine Codeausführung. Dieser Artikel behandelt die SSRF-und-Token-Darstellung als etabliert und wiederholt nicht das RCE-Framing.

Warum das Token und nicht die Anfrage der Befund ist

Server-Side Request Forgery ist eine der ältesten Fehlerklassen in Web-Software, und für sich genommen ist sie meist ein Mittel, um Systeme zu erreichen, die der Angreifer nicht direkt adressieren kann. Was diesen Fall festhaltenswert macht, ist die Anmeldeinformation, die an die Anfrage geknüpft ist. Der MCP-Server ist von seiner Konstruktion her ein Confused Deputy: Er besitzt eine Identität, damit ein Agent im Namen eines Nutzers handeln kann, und jeder Parameter, den ein Agent übergibt, ist aus Sicht des Servers vom Angreifer beeinflussbarer Text. Wird einer dieser Parameter zu einem Ziel statt zu einem Namen, trägt der Stellvertreter seine eigene Berechtigung bis zum Ziel.

Microsofts Dokumentation schärft den Blick dafür, wo sich dieses Risiko konzentriert. Sie beschreibt den lokalen Server als „ausschließlich für die Verwendung durch Entwickler innerhalb Ihrer Organisation vorgesehen“, während sie separat Bereitstellungsleitfäden für selbst gehostete Remote-Server in Microsoft Foundry und Copilot Studio veröffentlicht – die Konfigurationen, in denen typischerweise eine verwaltete Identität und nicht die eigene Anmeldung eines Entwicklers die relevante Anmeldeinformation ist. Der Token-Diebstahlpfad des Sicherheitshinweises betrifft speziell die verwaltete Identität. Er besagt nicht, dass jede Installation exponiert war, und er sagt auch nicht, wie viele es waren.

Die allgemeine Lehre ist diejenige, mit der das AI Security Verification Standard von OWASP den Fall inzwischen als Lehrbeispiel behandelt. Das AISVS-Kapitel zur Orchestrierung führt CVE-2026-26118 unter seinen ausgearbeiteten Beispielen auf und zieht die Schlussfolgerung: „MCP-Tool-Parameter müssen als vom Angreifer kontrolliert behandelt werden, und ausgehende Anfragen von MCP-Servern müssen durch dieselben Egress- und Origin-Richtlinien laufen, die für jede andere agentengesteuerte E/A erwartet werden.“ Das ist eine Kontrollempfehlung, keine Erkenntnis zu diesem Vorfall, aber es ist die konkreteste Antwort, die bisher jemand auf die Frage veröffentlicht hat, was sich ändern sollte.

Was hat sich danach geändert

Drei Dinge – und keines davon ist dramatisch. Microsoft hat in allen drei Ökosystemen korrigierte Pakete veröffentlicht und den Sicherheitshinweis überarbeitet, um sie zu benennen. Das Vulnerability-Intelligence-Ökosystem nahm es still auf: ein niedriger EPSS-Wert und ein NVD-Eintrag, zuletzt geändert am 17. Juni 2026. Und die Standards-Community nahm es als Lehrbeispiel auf – eine langsamere und dauerhaftere Form der Reaktion als ein Patch.

Für alle, die noch einen betroffenen Build ausführen, ist die Abhilfe unverändert und unspektakulär: Wechseln Sie in jedem Paketmanager, den das Deployment berührt, auf 1.0.2 oder höher im stabilen Zweig bzw. auf 2.0.0-beta.17 oder höher im Preview-Zweig. Darüber hinaus legt die Logik des Advisory selbst drei Kontrollen nahe – einschränken, was der Server ausgehend erreichen kann, der verwalteten Identität nur die Rollen geben, die ihre Tools tatsächlich benötigen, und jeden Tool-Parameter, der zu einer URL werden kann, als feindliche Eingabe behandeln. Keine dieser Maßnahmen ist Voraussetzung dafür, CVE-2026-26118 überstanden zu haben. Jede würde den Nutzen verringern, den die nächste für einen Angreifer hat.

Wie das Archiv dieses hier einordnet

Der Eintrag ist als Schwachstelle erfasst – etwas Gefundenes, nicht etwas, von dem bekannt ist, dass es ausgenutzt wurde –, mit Vertrauensstufe A, was gut dokumentiert mit übereinstimmenden Primärquellen bedeutet, und er ist nicht als umstritten markiert. Das Feld für tatsächlichen Schaden ist false und die KI-Beteiligung ist bestätigt, weil das betroffene Produkt die Brücke zwischen einem KI-Agenten und einer Cloud-Control-Plane ist und kein Allzweckdienst, der zufällig in der Nähe liegt. Das Datum ist mit Tagesgenauigkeit erfasst, 10. März 2026, ohne Enddatum, da es sich um einen einzelnen Zeitpunkt und nicht um eine Kampagne handelt. Die Region ist global und das Landmark-Flag ist false.

Ein Feld liest sich anders als die veröffentlichte Bewertung. Der Schweregrad des Archivs ist als medium auf seiner eigenen Skala erfasst; die Zahl, die sowohl Microsoft als auch NVD veröffentlichen, ist 8.8, die Microsoft als Important bezeichnet und NVD als High einstuft. Die Zusammenfassung des Datensatzes beginnt mit dieser 8.8, und die Diskrepanz ist ein Unterschied bei der Zuordnung zu Kategorien, nicht bei den Fakten.

Was der Bericht nicht vermitteln kann, ist, wie viel an dieser Geschichte eine Abwesenheit ist. Es gibt einen Fehler, der jedem, der in der falschen Form danach fragt, eine Cloud-Identität aushändigt. Es gibt eine Korrektur, die vor der Ankündigung ausgeliefert wurde. Es gibt keinen genannten Entdecker, kein genanntes Tool, keine bestätigte Ausnutzung und für Außenstehende keine Möglichkeit festzustellen, ob irgendeine gehostete Bereitstellung jemals einen verwundbaren Build ausgeführt hat, während sie eine mächtige Identität innehatte. Der Sicherheitshinweis ist präzise darin, was der Fehler bewirkt, und schweigt über fast alles andere, und dieses Schweigen ist das Nützlichste, was man daran bemerken kann.