CVE 10.0 in Azure AI Foundry: Risiko für KI-Agenten im Unternehmen

Der Fall: Höchstwertung für eine Agenten-Plattform

CVE-2026-85889 erreicht einen CVSS-Score von 10.0, das obere Ende der Skala. Microsoft hat den Fix für Azure AI Foundry ausgeliefert, die Enterprise-Plattform, auf der Unternehmen generative Anwendungen und Agenten bauen, ausrollen und betreiben.

Das Advisory, veröffentlicht am Donnerstag, 17. September 2026, spricht von «missing authentication for critical function»: Eine kritische Funktion der Plattform blieb über das Netzwerk für einen Angreifer ohne Autorisierung erreichbar, mit Rechteausweitung als Ergebnis. The Hacker News hat den Vorgang am 18. September 2026 berichtet^[1] und schreibt die Entdeckung dem Forscher Rémy Marot zu.

Das Unternehmen meldet null Hinweise auf eine Ausnutzung in the wild. Dieselbe Mitteilung stellt klar, dass der Fehler auf Cloud-Seite bereits behoben ist.

Der für den Entwurf agentischer Systeme entscheidende Punkt liegt in der Kombination der Bedingungen: Höchstwertung, Netzwerkvektor, fehlende Authentifizierung, erhöhte Rechte als Resultat.

Der Mechanismus: fehlende Authentifizierung vor einer kritischen Funktion

Ein CVSS 10.0 entsteht aus einer genauen Summe. Netzwerkvektor, niedrige Angriffskomplexität, erforderliche Rechte gleich null, Benutzerinteraktion gleich null, vollständige Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit.

Die Fehlerklasse ist das Fehlen einer Identitätsprüfung vor einer Funktion, die sie zwingend verlangt. Der Anwendungscode kann korrekt sein, das Modell ausgerichtet, der Prompt gefiltert: Der Zugriff setzt oberhalb von alledem an, vor der Geschäftslogik.

Cybersecurity News^[2] greift dieselbe technische Beschreibung und dieselbe Zuschreibung auf und bestätigt, dass für Kunden keine Aktionen erforderlich sind. Die öffentlichen Details enden bei der Klassifizierung, wie es bei Cloud-CVEs die Regel ist.

Die genaue Aufrufkette bleibt beim Anbieter intern. Wer das Risiko bewertet, arbeitet also mit einem Etikett, nie mit einer reproduzierbaren Spur.

Control Plane, eine andere Ebene als das Modell

Hier liegt der Punkt, der diesen Vorgang von den üblichen Debatten über Halluzinationen und Jailbreaks trennt. Der Fehler betrifft die Control Plane, also jene Schicht, die Agenten anlegt, Deployments aufsetzt, Schlüssel verwaltet und Modelle mit Unternehmensdaten verbindet.

Ein Angriff auf das Modell erzeugt falsche Ausgaben. Ein Angriff auf die Control Plane erzeugt Zugriff auf Ressourcen, auf Konfigurationen und auf andere Agenten.

In einem agentischen Kontext fällt die Angriffsfläche mit der Orchestrierungsplattform zusammen. Ein Agent erbt die Anmeldedaten seiner Ausführungsumgebung: Wer die Rechte auf dieser Umgebung ausweitet, erreicht seinerseits alles, was auch der Agent erreicht.

Die Security Posture von KI-Systemen liegt zwei bis drei Jahre hinter der Reife der Infrastruktur, die sie beherbergt. Das Muster wiederholt sich bei Frameworks, Runtimes und Managed Platforms: erst die Produktion, dann das Hardening.

«No customer action required»: der unbequeme Teil

Die cloudseitige Behebung ist zugleich eine operative gute Nachricht und ein Governance-Problem. Gute Nachricht: Das Risiko ist vorgelagert geschlossen, und Kunden haben null Patches einzuspielen, null Wartungsfenster auszuhandeln.

Die Kehrseite betrifft die Überprüfbarkeit. Es fehlt ein KB-Eintrag zum Nachverfolgen, es fehlt eine Version zum Vergleichen, es fehlt ein Artefakt für das eigene Schwachstelleninventar.

Ein Prüfer, der fragt «wie lange waren wir exponiert», erhält als Antwort das Datum des Advisorys. Das tatsächliche Fenster, jenes zwischen Einführung des Fehlers und Korrektur, bleibt Information des Anbieters.

Diese Asymmetrie hat konkrete vertragliche Folgen. Ein reguliertes Unternehmen muss Kontrolle über das nachweisen, was sensible Daten beherbergt, und der Nachweis stützt sich vollständig auf die Erklärung des Providers.

Wer die Cloud als reine Kapazitätslieferung behandelt, akzeptiert dieses Modell. Wer sie als Teil des eigenen Compliance-Perimeters betrachtet, muss das im Vertrag schwarz auf weiss festhalten.

Das gesamte Zeitfenster: Copilot, PostgreSQL, Cosmos DB

Die Foundry-Lücke kommt begleitet von weiteren kritischen Korrekturen desselben Zeitfensters. Es lohnt sich, sie als Ganzes zu lesen, denn sie betreffen den kompletten Stack, auf dem eine agentische Anwendung aufsetzt.

• CVE-2026-85885 (CVSS 9.9): Command Injection in Microsoft 365 Copilot, mit Rechteausweitung über das Netzwerk durch einen autorisierten Angreifer
• CVE-2026-85878 (CVSS 9.9): fehlerhafte Autorisierung in Azure Database for PostgreSQL
• CVE-2026-87701 (CVSS 9.6): fehlerhafte Neutralisierung in Azure Cosmos DB
• CVE-2026-62721 (CVSS 7.8) und CVE-2026-85921 (CVSS 8.2): lokale Rechteausweitung unter Windows 11 Version 26H1, geschlossen mit dem ausserplanmässigen Update KB5129194

Der Anwendungs-Layer, der Daten-Layer und der Plattform-Layer tauchen in derselben Woche auf. Ein Agent in Produktion durchquert üblicherweise alle drei, und ein Fehler in einem beliebigen davon erreicht ihn.

In der Vorwoche hatte Microsoft 974 Schwachstellen im eigenen Softwareportfolio korrigiert, ein Rekord laut der Rekonstruktion derselben Publikation. Das Volumen sagt etwas darüber aus, wie schnell sich die Angriffsfläche ausdehnt.

Die drei Cloud-Lücken teilen ein Merkmal: Sie sind bereits behoben, mit null erforderlichen Eingriffen. Die Klasse der Abhilfe ist identisch, und identisch ist die Grenze der Transparenz.

Drei Fragen für ein KI-Team im Unternehmen

Der nützliche Teil der Arbeit beginnt nach dem Advisory. Drei Punkte verdienen eine schriftliche Antwort vor dem nächsten Release-Zyklus.

1. Welche Agenten in Produktion laufen auf Azure AI Foundry, und welche Identität und welchen Berechtigungsumfang bringt jeder einzelne davon mit?
2. Welches Log belegt das Verhalten dieser Agenten zwischen dem Erstellungsdatum des Deployments und dem Datum des Advisorys?
3. Welches Verfahren widerruft in weniger als einer Stunde die Anmeldedaten eines kompromittierten Agenten, und wer führt es ausserhalb der Geschäftszeiten aus?

Die dritte Frage entlarvt fragile Architekturen. Die Identität des Agenten ist die Control Plane dieser Saison: Was keine eigenen Anmeldedaten und keine namentlichen Logs hat, bleibt von jedem Widerruf ausgenommen, und was dem Widerruf entgeht, entgeht der Steuerung.

Ein Multi-Agenten-System ohne explizite Circuit Breaker fällt kaskadenartig aus. Die Ausgabe eines Agenten wird zur Eingabe des nächsten, und die unabhängige Validierung zwischen den beiden Schritten fehlt fast immer.

Entscheidungen für den nächsten Planning Cycle

Für einen CTO ist die unmittelbare Konsequenz eine Inventurübung. Es braucht die Liste der aktiven Agenten, der Control Plane, die sie beherbergt, und der Ressourcen, die jeder mit den eigenen Anmeldedaten berührt.

Für einen Head of Engineering betrifft die Entscheidung die Ausführungsgrenzen. Ein Agent verdient eine dedizierte Identität, einen eng gefassten Berechtigungsumfang und einen Validierungspunkt zwischen einem Aufruf und dem nächsten.

Für einen CFO ändert sich die Rechnung wenig bei der Investition und einiges beim Restrisiko. Die Managed Platform verschiebt die Kosten des Hardenings auf den Anbieter und verschiebt zugleich die Fähigkeit, diese Kontrolle vor einem Auditor nachzuweisen.

Für ein Procurement-Komitee existiert der Hebel und gehört bei der Verlängerung genutzt. Drei Klauseln lohnen die Verhandlung: Benachrichtigung innerhalb einer definierten Frist bei CVEs, die die Control Plane betreffen, Zugang zu den Audit-Logs des Tenants mit vereinbarter Aufbewahrungsdauer, Anspruch auf einen Post-Incident-Bericht mit dem zeitlichen Expositionsfenster.

Architekturfalle oder Wettbewerbsvorteil

Die Antwort bleibt differenziert. Azure AI Foundry bleibt eine Production-Grade-Plattform, und der Umgang mit dieser Lücke bestätigt das: Höchstwertung, vorgelagert angewandte Abhilfe, null Unterbrechungen für die Kunden, externer Forscher mit Credit.

Das architektonische Lock-in dagegen bezahlt man in Sichtbarkeit. Wer Agenten innerhalb einer Managed Control Plane baut, delegiert die Security Posture an einen Dritten und die Überprüfung auf den Dokumentenweg.

Für die Mehrheit der Unternehmen ist dieser Tausch vernünftig. Er wird zu Technical Debt, wenn die Architektur bei Modell, Orchestrierung, Identität und Daten auf einem einzigen Anbieter ruht, denn in dieser Konfiguration durchquert ein Fehler der Control Plane die gesamte Kette auf einen Schlag.

Die konkrete Entscheidung für den nächsten Planning Cycle liegt in der Trennung der Ebenen. Identität der Agenten verwaltet ausserhalb der Plattform, die sie ausführt, Logs repliziert in ein unabhängiges System, ein zweiter Deployment-Pfad warm gehalten. Fault Tolerance bedeutet genau das: Die Plattform fällt aus, die Kontrolle bleibt.