Microsoft schließt eine CVSS-10.0-Lücke ohne Authentifizierung in Azure AI Foundry

Am 17. September 2026 veröffentlichte Microsoft CVE-2026-85889, die „Azure AI Foundry Elevation of Privilege Vulnerability“, mit einem CVSS-v3.1-Basisscore von 10.0. Das Advisory ordnet sie CWE-306 zu, fehlende Authentifizierung einer kritischen Funktion: Eine kritische Funktion in Azure AI Foundry wurde ohne Authentifizierungsprüfung ausgeliefert, sodass ein Angreifer im Netzwerk sie ohne jede Zugangsdaten zur Rechteausweitung nutzen konnte.

Zum Weiterlesen: Microsoft will seine Rechenzentren bis 2032 auf 38 Gigawatt verdreifachen · SK Hyper beziffert die ersten 5 Gigawatt seines KI-Ausbaus auf 350 Milliarden Dollar.

Der Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H liegt bei jeder relevanten Metrik am schlechtesten Wert. Der Angriff ist über das Netzwerk erreichbar und wenig komplex, verlangt keine Privilegien und keine Nutzerinteraktion und hat hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Für die Einschätzung des Schadensradius zählt die Scope-Komponente am meisten. Ein geänderter Scope bedeutet, dass die Wirkung eine Sicherheitsgrenze überschreitet, statt im eigenen Konto des Angreifers zu bleiben, was in einer Multi-Tenant-Cloud auf die Grenze zwischen Mandanten und der Plattform selbst deutet.

Microsoft zufolge ist die Lücke bereits behoben. Das Advisory erklärt, sie sei serverseitig „vollständig behoben“, es gebe keine Aktion für Nutzer des Dienstes, und die CVE diene der Transparenz. Einen Patch zum Herunterladen gibt es nicht. Microsoft würdigte den Sicherheitsforscher Rémy Marot (@R_Marot) für den Bericht, und die Berichterstattung von The Hacker News hält fest, dass es keine Hinweise auf eine Ausnutzung in freier Wildbahn gibt. Da Azure AI Foundry ein ausschließlich gehosteter Dienst ist, lebte und starb der Fix in Microsofts Infrastruktur, für Kunden unsichtbar.

Die Lücke in einfachen Worten

CWE-306 beschreibt einen konkreten, unspektakulären Fehler: Eine Funktion, die einen authentifizierten Aufrufer verlangen sollte, akzeptiert einen nicht authentifizierten. Der Bug ist kein Trick zur Speicherbeschädigung und keine Kette von Fehlkonfigurationen. Es ist das Fehlen einer Anmeldung dort, wo eine Anmeldung hingehört.

Die Folge ergibt sich direkt aus dem, was die ungeschützte Funktion tun konnte. Bei einer Rechteausweitungs-Lücke kann ein Aufrufer durch die fehlende Prüfung so handeln, als hätte er nie gewährte Berechtigungen. Zusammen mit Netzwerk-Angriffsvektor und fehlenden Privilegien bedeutet das praktisch: Wer eine Anfrage an den betroffenen Endpunkt leiten konnte, erreichte privilegierte Operationen innerhalb der Plattform. Die geänderte CVSS-Scope zeigt an, dass diese Operationen nicht auf die Autorisierungsgrenze des Angreifers beschränkt waren.

Deshalb ist eine 10.0 hier keine Überhöhung. Ein Wert von 10.0 ist Lücken vorbehalten, die aus der Ferne erreichbar, trivial ausnutzbar und für Vertraulichkeit, Integrität und Verfügbarkeit des Ziels vollständig zerstörerisch sind. Fehlende Authentifizierung in einer erreichbaren Steuerungsfunktion trifft alles davon zugleich.

Warum eine KI-Steuerungsebene eine Identitätsoberfläche der höchsten Kategorie ist

Azure AI Foundry ist Microsofts Unternehmensplattform zum Bauen, Bereitstellen und Verwalten von KI-Agenten und Modellen. Diese Beschreibung unterschätzt, was sie sicherheitstechnisch ist. Foundry ist eine Steuerungsebene. Sie orchestriert anderen Code, hält Modellbereitstellungen und Trainingsdaten und verbindet sich über Zugangsdaten, die Kunden konfigurieren, mit Unternehmensdatenquellen und nachgelagerten Systemen. Wer darin handeln kann, kann auf vieles einwirken, was für das Geschäft zählt.

Eine Lücke, die unauthentifizierten Zugriff auf eine privilegierte Foundry-Funktion gewährt, ist daher vergleichbar damit, einem Angreifer die Schlüssel eines privilegierten Plattformnutzers zu übergeben. Die Analyse von Mallory beschreibt die mögliche Reichweite unverblümt: Ein Angreifer könnte Fähigkeiten erlangen, die einem privilegierten Foundry-Nutzer entsprechen, und damit möglicherweise KI-Modelle, Trainingsdaten, verbundene Unternehmensressourcen und mit Foundry-Anwendungen integrierte nachgelagerte Systeme offenlegen oder verändern.

Das ist der Kern des Arguments, KI-Verwaltungs-APIs als Identitätsoberfläche der höchsten Kategorie zu behandeln. Identitätsteams haben jahrelang menschliche Anmeldungen gehärtet und in jüngerer Zeit Dienstkonten und Workload-Identitäten. Die neueren Verwaltungsebenen für KI sind jünger, sie tragen oft weitreichende dauerhafte Berechtigungen über Daten und Rechenleistung, und sie sind häufig in Automatisierung eingebunden, die kaum jemand von Hand prüft. Wenn eine Plattform in Ihrem Namen andere Systeme aufrufen kann, ist ihre eigene Authentifizierung so sensibel wie die Zugangsdaten, die sie hält.

Die Angriffsfläche unterscheidet sich auch von einer klassischen Anwendung. Es gibt keinen Perimeter zu verteidigen und keine Firewall-Regel auf Kundenseite, die eine Anfrage an einen von Microsoft gehosteten Endpunkt aufgehalten hätte. Die verwundbare Funktion war konstruktionsbedingt über das Netzwerk erreichbar, was für eine Cloud-API normal ist, und die fehlende Prüfung war das Einzige zwischen einem Aufrufer und privilegierten Operationen.

Was „vollständig behoben, keine Kundenaktion“ klärt

Die Formulierung ist ehrlich und sollte als das gelesen werden, was sie ist. Microsoft fand das Problem, behob es auf den eigenen Servern und veröffentlichte die CVE, damit der Datensatz zu einer Lücke mit maximaler Schwere nicht schweigt. Das ist die Transparenz, für die das CVE-Programm gedacht ist, und es ist besser als die Alternative, still zu patchen und nichts zu sagen.

Für den durchschnittlichen Kunden ist die operative Konsequenz tatsächlich gering. Es gibt nichts bereitzustellen, keine Version gegen ein Inventar abzugleichen, kein Wartungsfenster. Ein Mandant, der nichts tut, läuft bereits gegen das behobene Backend.

Was die Formulierung nicht klärt, ist die Überprüfung. Wenn ein Hersteller Software patcht, kann ein Kunde die Version bestätigen, einen Scanner laufen lassen oder einen Build-Hash prüfen. Wird ein gehosteter Dienst serverseitig behoben, steht nichts davon zur Verfügung. Der einzige Beleg des Kunden ist das Wort des Herstellers und, wenn er die Telemetrie hat, eine Durchsicht dessen, was vor und während des Behebungsfensters im eigenen Konto geschah. Diese Lücke ist keine Kritik an Microsofts Reaktion. Sie ist eine strukturelle Eigenschaft des Konsums von Sicherheitsgarantien von einem Dienst, den man nicht kontrolliert.

Es gibt eine zweite Grenze. Microsoft hat wenige technische Details veröffentlicht, welche Funktion betroffen war oder wie die fehlende Prüfung erreichbar war. Das Advisory nennt Schwachstellenklasse und Score, aber nicht den Endpunkt. Eine Threat-Intelligence-Analyse bei threat.wiki und unabhängige Tracker ergänzen Vektor und die Multi-Tenant-Lesart, doch der öffentliche Stand erlaubt es einem externen Team weiterhin nicht, die Lücke zu rekonstruieren. Ohne dieses Detail ist der wahre Schadensradius aus dem öffentlichen Stand nicht vollständig erkennbar, und niemand kann genau sagen, was ein Angreifer, der die Lücke vor dem Fix nutzte, hätte erreichen können.

Den Fix liefert Microsoft. Den Nachweis, dass in Ihrem Konto nichts geschah, müssen Sie selbst erbringen.

Das größere Muster über KI-Plattformen hinweg

CVE-2026-85889 kam nicht allein. Sie landete in einem Bündel hochgradiger Microsoft-Fixes um den 16. und 17. September 2026, zu dem auch eine Command-Injection-Lücke in M365 Copilot, CVE-2026-85885, mit Bewertung 9.9 gehörte; eine Autorisierungslücke in Azure Database for PostgreSQL, CVE-2026-85878, mit 9.9; und eine Lücke in Azure Cosmos DB, CVE-2026-87701, mit 9.6. Microsofts Advisories zu jeder erklären, sie seien serverseitig ohne Kundenaktion behoben worden, und die Einträge zu Copilot und Cosmos DB wiederholen die Transparenz-Formulierung der Foundry-Lücke. Ein separater Microsoft-Eintrag im selben Zeitfenster, das Windows-26H1-Update KB5129194, adressierte einen Double-Free im Secure Kernel Mode, geführt als CVE-2026-85921. Der letzte Punkt ist ein konventionelles gepatchtes Update und kein versteckter Cloud-Fix; Leser sollten die Bündelung der gesamten Liste als Framing betrachten, nicht als eine einzige Microsoft-Aussage.

Die Threat-Intelligence-Analyse ordnet CVE-2026-85889 in ein engeres Muster ein: Es ist die dritte Lücke mit nahezu maximaler oder maximaler Schwere in diesem Monat in einer Plattform, deren Aufgabe es ist, andere Software zu orchestrieren, nach einer 9.8 in Bifrost und einer 9.8 in Orkes. Diese Gruppierung ist das Framing der Analyse, keine Microsoft-Aussage, doch sie deutet auf etwas Reales hin. Die Werkzeuge, die mitten in einem Software-Stack sitzen und Modelle, Agenten, Workflows und verbundene Systeme orchestrieren, sind genau der Ort, an dem ein einzelner Authentifizierungsfehler einen überproportionalen Schadensradius erzeugt. Ist der Orchestrator kompromittiert, erbt alles Nachgelagerte das Problem.

Das ist eine junge Softwareklasse. Agent-Frameworks, Modell-Gateways und Orchestrierungsschichten sind schnell gewachsen, und viele wurden von Teams gebaut, deren Priorität Fähigkeit und Geschwindigkeit war, nicht die Härtung, die ältere Plattformen über ein Jahrzehnt der Prüfung angehäuft haben. Die Lehre aus klassischer Infrastruktur, dass Steuerungsebenen die stärksten Identitätsgarantien verdienen, weil sie die Schlüssel zu allem anderen halten, ist von der KI-Werkzeugwelle noch nicht vollständig verinnerlicht. Das Microsoft-Bündel erinnert daran, dass dieselben Fehlermuster wandern: fehlende Autorisierung, Command Injection, unsachgemäße Zugriffskontrolle, alle kehren in neuen Systemen wieder.

Was zu beobachten ist

Drei Dinge werden prägen, wie dieser Vorfall in Erinnerung bleibt.

Erstens, ob Microsoft mehr technische Details veröffentlicht. Schwachstellenklasse und Score genügen für einen CVSS-Eintrag, aber nicht, damit Verteidiger ihre Exposition modellieren können. Wird die betroffene Funktion später beschrieben, können Teams einschätzen, ob ihre Automatisierung sie im Fenster vor dem Fix berührt hat. Bis dahin ist die ehrliche Position, dass der öffentliche Stand unvollständig ist.

Zweitens, ob Telemetrie nach dem Fix ungewöhnliche Aktivitäten zeigt. Microsoft sagt, es gebe keine Hinweise auf eine Ausnutzung, und diese Aussage sollte man wörtlich nehmen. Dennoch ist eine unauthentifizierte Netzwerklücke, die über einen unbekannten Zeitraum vor der Offenlegung bestand, genau der Fall, für den eine rückblickende Log-Prüfung gedacht ist. Organisationen, die Foundry produktiv betreiben, sollten nach anomalen privilegierten API-Aufrufen, unerwarteten Rollenzuweisungen und neuen Verbindungen zu Datenspeichern oder externen Ressourcen suchen.

Drittens die Richtung der Plattform selbst. Je mehr Unternehmen Agenten mit realer Arbeit betrauen, desto mehr wird die Identitäts- und Autorisierungshaltung der Steuerungsebenen, die sie ausführen, zu einer Governance-Frage ebenso wie zu einer Sicherheitsfrage. Regulierer und Prüfer beginnen zu fragen, wer genehmigt hat, worauf ein KI-System zugreifen darf. Eine Authentifizierungslücke mit maximaler Schwere in einer Plattform, die diesen Zugriff orchestriert, ist die Art von Befund, die solche Gespräche beschleunigt.

Für Leser, die Cloud-Sicherheit verfolgen, ist die praktische Anweisung klein und dauerhaft. Behandeln Sie die KI-Verwaltungsebene als Identitätsebene. Das bedeutet Rollenzuweisungen nach dem Prinzip der geringsten Rechte, Prüfung dauerhafter Berechtigungen, Protokollierung privilegierter Operationen und die Gewohnheit, diese Logs anzusehen, wann immer ein Hersteller einen serverseitigen Fix ankündigt, den Sie nicht einsehen können. Den Fix muss Microsoft liefern. Die Gewissheit, dass in Ihrem Konto nichts geschah, müssen Sie selbst aufbauen, und sie hängt von Aufzeichnungen ab, die Sie führen, bevor die Offenlegung eintrifft.

Cover: „Microsoft Redmond Campus redevelopment aerial view, Sept. 2021“ von Atomic Taco, via Wikimedia Commons, lizenziert unter CC BY-SA 2.0 (auf 16:9 zugeschnitten).