Am 17. September 2026 hat Microsoft außerplanmäßig eine Schwachstelle in Azure AI Foundry geschlossen, der Unternehmensplattform, auf der Tausende Unternehmen generative KI-Anwendungen und Agenten bauen, betreiben und steuern. Die Schwere liegt bei CVSS 10.0, dem Höchstwert. Die Beschreibung ist ein Satz, und man sollte ihn langsam lesen: fehlende Authentifizierung an einer kritischen Funktion.
Aus der Anbietersprache übersetzt: Ein nicht authentifizierter Angreifer aus dem Netz konnte eine kritische Funktion der Plattform ganz ohne Anmeldung erreichen und darüber Privilegien erhöhen. Keine Zugangsdaten. Kein Phishing. Keine Nutzerinteraktion. Nur ein erreichbarer Endpunkt und eine fehlende Prüfung.
Microsoft erklärt, es gebe keine Hinweise auf eine Ausnutzung von CVE-2026-85889 in freier Wildbahn, die Lücke sei serverseitig bereits vollständig behoben, und es sei keine Kundenaktion nötig. Beides ist mit hoher Wahrscheinlichkeit zutreffend. Interessant ist keines von beidem.
Was Microsoft tatsächlich veröffentlicht hat
CVE-2026-85889 kam nicht allein. Im selben Zeitraum schloss Microsoft eine Gruppe kritischer Lücken in seiner Cloud-Landschaft:
- CVE-2026-85885 (CVSS 9.9): Command Injection in Microsoft 365 Copilot mit Rechteerhöhung über das Netz.
- CVE-2026-85878 (CVSS 9.9): fehlerhafte Autorisierung in Azure Database for PostgreSQL mit demselben Ergebnis.
- CVE-2026-87701 (CVSS 9.6): fehlerhafte Neutralisierung in Azure Cosmos DB, ebenfalls mit Rechteerhöhung.
- CVE-2026-69843 und CVE-2026-62874: Lücken mit Höchstnote in Microsoft Fabric und Azure Billing, beide mit 10.0 bei unabhängigen Trackern.
In derselben Woche schloss Microsoft mit dem September-Patchday einen Rekord von 974 Schwachstellen im eigenen Portfolio, zwei davon werden bereits aktiv ausgenutzt. Forscher haben eine davon, eine ALPC-Lücke in Windows, mit zwei Chrome-Zero-Days zu einem Exploit-Kit namens BlueMoon verkettet, das mehrere espionage-nahe Gruppen einsetzen.
Lesen Sie diese Liste als Form, nicht als Einzelfälle. Die 10.0 und 9.9 verteilen sich nicht über Desktop-Software. Sie ballen sich in Clouds, Datenplattformen und KI-Diensten. Dorthin ist die Angriffsfläche der Unternehmen gewandert, und dort folgen die kritischen Funde.
"Keine Kundenaktion nötig" heißt nicht "keine Arbeit für Kunden"
Der Satz bedeutet, dass der Anbieter den Server gepatcht hat, den Sie mieten. Über die Folgen auf Ihrer Seite sagt er nichts, und genau hier hören die meisten Teams auf zu lesen.
Eine nicht authentifizierte Rechteerhöhung in einer KI-Plattform ist ein Problem der Kontrollschicht. Azure AI Foundry ist kein Chatbot in einem Browser-Tab. Es ist der Ort, an dem Modelle bereitgestellt werden, an dem Prompts und Evaluationsdaten liegen, an dem Datenquellen angebunden werden, an dem Agenten-Identitäten und Tool-Berechtigungen definiert sind. Je nach Konfiguration Ihres Tenants kann der Zugriff auf diese Schicht den Zugriff auf Ihre Storage Accounts, Ihren Key Vault, Ihre Azure-OpenAI-Bereitstellungen oder die Service Principals bedeuten, die den Rest Ihrer Umgebung tragen.
"Bereits behoben" beantwortet die Frage des Anbieters. Es beantwortet nicht Ihre Frage: Was hätte ein kurzes Fenster unauthentifizierten Zugriffs auf diese Schicht in Ihrer Umgebung offengelegt?
Ihre KI-Plattform ist eine Kontrollschicht. Behandeln Sie sie so.
Ein Jahrzehnt lang haben wir IAM-, CI/CD- und Kubernetes-Kontrollschichten als Tier-0-Systeme behandelt: Prüfung privilegierter Zugriffe, Änderungsprotokollierung, Netzwerkbeschränkungen, Notfallverfahren. KI-Plattformen sind in genau diese Kategorie hineingewachsen, werden aber überwiegend wie ein Projektarbeitsbereich verwaltet.
Genau diese Lücke sollte die Meldung schließen. Drei praktische Konsequenzen:
- Zuerst Inventar. Über den Wirkungsradius lässt sich nicht sinnvoll reden, wenn unklar ist, welche Tenants, Subscriptions und KI-Dienste Sie betreiben. In den meisten Organisationen entstehen KI-Dienste schneller, als das Asset-Register nachkommt.
- Zeichnen Sie die Identitätslandkarte. Listen Sie für jede KI-Plattform jede Managed Identity, jeden Service Principal und jede Verbindung auf, die sie annehmen kann, sowie jeden Datenspeicher, den sie lesen kann. Der Wirkungsradius ist diese Karte, nicht die Plattform selbst.
- Heben Sie KI-Kontrollschichten in die privilegierte Stufe. Benannte Administratoren, MFA und Conditional Access, Sitzungsprotokollierung, eingeschränkte Netzwerkexposition und Alarmierung bei administrativen Änderungen, genau wie bei einem Domain Controller.
Warum sich eine 10.0 auf einer KI-Plattform anders anfühlt
Eine fehlende Authentifizierungsprüfung ist eine klassische, fast alltägliche Fehlerklasse. Sie steht seit Jahren im OWASP-Verzeichnis. Geändert hat sich der Wert dessen, was hinter der Prüfung liegt.
Vor drei Jahren war eine nicht authentifizierte Lücke in einem Analysedienst ein ernstes Problem einer Abteilung. Heute sitzt dieselbe Fehlerklasse vor dem System, das entscheidet, welche Tools Ihre Agenten aufrufen, welche Daten sie lesen und welche Zugangsdaten sie nutzen dürfen. Der Schweregrad hat sich nicht geändert. Das Asset schon.
Dazu kommt ein zweiter Effekt. KI-Workloads bündeln sensible Daten by Design: Prompts mit Kundendaten, Evaluationssets aus internen Dokumenten, Retrieval-Indizes über allem, was das Unternehmen weiß. Die Kompromittierung der Kontrollschicht ist keine Seitentür in eine Anwendung. Sie ist Karte und Schlüssel zu dem Material, das alle Anwendungen speist.
Was wir Kunden diese Woche raten
- Prüfen Sie Exposition und Versionsstand. Cloud-Dienste patcht der Anbieter, aber selbst betriebene Komponenten derselben Architektur, einschließlich PostgreSQL- und Cosmos-DB-Konfigurationen, verdienen eine bewusste Überprüfung.
- Überarbeiten Sie Identitäts- und Zugriffsdesign rund um KI-Workloads. Least Privilege zwischen KI- und Datenschicht ist die wertvollste Kontrolle in Ihrem Besitz, und sie übersteht Plattformfehler, die kein Patchzyklus erreicht.
- Halten Sie Geheimnisse aus Agenten-Laufzeitumgebungen heraus. Langlebige Schlüssel machen aus einer Plattformlücke einen unternehmensweiten Vorfall.
- Protokollieren und alarmieren Sie Änderungen an der Kontrollschicht. Merkt niemand einen neuen Service Principal, misst jemand anderes die Reaktionszeit.
- Geben Sie jedem KI-Dienst einen benannten Verantwortlichen. Nicht erfasste KI-Dienste sind die, die im Vorfall entdeckt werden. Finden Sie sie jetzt.
Das größere Bild
Microsoft hat hier richtig gehandelt: schneller Fix, klare Meldung, verantwortungsvolle Offenlegung. Unangenehm ist nicht der Vorfall, sondern das Muster. KI-Plattformen sind heute Produktionsinfrastruktur für Finanzen, Gesundheit, Logistik und Verwaltung in dieser Region und darüber hinaus, und sie sammeln Höchstnoten-Funde so wie Cloud-Infrastruktur in ihren Anfangsjahren.
Gut durch dieses Jahrzehnt kommen nicht die Teams, die am schnellsten patchen, sondern die, die davon ausgehen, dass die Plattform irgendwann kompromittiert wird, und entsprechend entwerfen: enge Identitätsgrenzen, keine ambienten Zugangsdaten, klare Verantwortlichkeit und eine Kontrollschicht, die jemand tatsächlich beobachtet.
Wenn Sie nicht sicher sind, was ein nicht authentifizierter Angreifer über Ihre KI-Plattformschicht hätte erreichen können, ist das ein Gespräch, das sich diese Woche lohnt.
Quellen
- Microsoft Security Response Center: Hinweise zu CVE-2026-85889, CVE-2026-85885, CVE-2026-85878 und CVE-2026-87701, September 2026
- The Hacker News: Microsoft Patches CVSS 10.0 Azure AI Foundry Flaw Enabling Unauthorized Privilege Escalation, 18. September 2026
- CVE-Brief-Archiv, 18. September 2026
- Microsoft: Servicing-Hinweise zum September-Patchday 2026