Entra-ID-Lücke erreicht maximalen Schweregrad
Microsoft hat eine kritische Sicherheitslücke in Entra ID geschlossen, die bereits aktiv ausgenutzt wurde. Die unter CVE-2026-69836 geführte Schwachstelle erreicht mit CVSS 10.0 den höchstmöglichen Schweregrad.
Entra ID, früher Azure Active Directory, steuert Identitäten und Zugriffsrechte für Cloud-Anwendungen und Unternehmensressourcen. Der Dienst bildet damit für viele Microsoft-365-Umgebungen die zentrale Kontrollinstanz.
| Merkmal | Angabe |
|---|---|
| CVE-Kennung | CVE-2026-69836 |
| CVSS-Bewertung | 10.0 von 10.0 |
| Angriffsweg | Über das Netzwerk |
| Anmeldung erforderlich | Nein |
| Nutzerinteraktion erforderlich | Nein |
| Status | Serverseitig behoben |
| Aktive Ausnutzung | Von Microsoft bestätigt |
Unsichere Deserialisierung ermöglicht Schadcode
Die Ursache liegt in einer unsicheren Deserialisierung. Dabei rekonstruiert eine Software strukturierte Daten aus einer nicht vertrauenswürdigen Quelle, ohne deren Inhalt ausreichend zu prüfen.
Ein Angreifer konnte den Fehler über das Netzwerk ausnutzen, ohne ein Benutzerkonto zu besitzen oder eine Interaktion auszulösen. Die mögliche Folge war Remote Code Execution, also die Ausführung beliebigen Codes auf einem entfernten System.
„Die Deserialisierung nicht vertrauenswürdiger Daten in Microsoft Entra ID ermöglicht einem unbefugten Angreifer die Ausführung von Code über ein Netzwerk“, erklärte Microsoft in seinem Sicherheitshinweis, sinngemäß aus dem Englischen übersetzt.
Die CVSS-Höchstwertung ergibt sich aus dieser Kombination. Der Angriff war aus der Ferne möglich, erforderte nur geringe Komplexität und setzte weder Rechte noch eine Handlung betroffener Nutzer voraus. Microsoft schreibt die Entdeckung seinem Principal Security Engineer Robert Fitzpatrick zu.
Kein Patch für Kunden, aber viele offene Fragen
Da Entra ID vollständig als Microsoft-Cloud-Dienst betrieben wird, musste kein Update an Kunden verteilt werden. Microsoft hat die betroffene Infrastruktur selbst abgesichert.
„Die Schwachstelle wurde von Microsoft bereits vollständig behoben. Für Nutzer dieses Dienstes besteht kein Handlungsbedarf“, teilte das Unternehmen mit, sinngemäß aus dem Englischen übersetzt.
Diese Aussage bezieht sich allerdings nur auf die technische Behebung. Microsoft nennt bislang weder die Angreifer noch den Beginn oder den Umfang der Angriffe. Ebenso bleibt offen, welche Aktionen nach einer erfolgreichen Ausnutzung möglich waren und ob konkrete Mandanten betroffen sind.
Öffentliche technische Details zur Angriffskette fehlen ebenfalls. Damit lässt sich von außen nicht nachvollziehen, wie Microsoft die aktive Ausnutzung festgestellt hat. Ähnliche Transparenzprobleme zeigten sich bereits bei einer Sicherheitslücke in Microsoft Copilot, über die Daten aus verbundenen Diensten abfließen konnten.
Compliance-Prüfung wird für DACH-Unternehmen schwierig
Entra ID ist in Deutschland, Österreich und der Schweiz bei zahlreichen Unternehmen und Behörden das zentrale Identitätssystem für Microsoft 365. Eine Schwachstelle in dieser Schicht betrifft nicht nur einen einzelnen Dienst, sondern potenziell die Zugänge zu vielen angebundenen Anwendungen.
Für IT- und Compliance-Verantwortliche entsteht deshalb ein Informationsproblem. Ohne Angaben zu betroffenen Mandanten und tatsächlich ausgeführten Aktionen lassen sich mögliche Datenschutzverletzungen und daraus folgende DSGVO-Meldepflichten nicht sicher bewerten.
Kein Kunden-Patch bedeutet außerdem nicht automatisch, dass keine interne Prüfung erforderlich ist. Technische Behebung und forensische Aufarbeitung sind getrennte Aufgaben. Entscheidend sind belastbare Informationen darüber, ob verdächtige Zugriffe in der eigenen Umgebung stattgefunden haben.
Cloud-Komfort schafft zentrale Abhängigkeit
Der Vorfall zeigt den grundlegenden Zielkonflikt proprietärer Identitätsdienste. Der Cloud-Betreiber übernimmt Wartung und Patches, wodurch der administrative Aufwand sinkt. Gleichzeitig wird der zentrale Identitätsdienst zu einem gemeinsamen Angriffs- und Ausfallpunkt für zahlreiche angebundene Systeme.
Kunden besitzen zudem nur eingeschränkte Kontrolle über die zugrunde liegende Plattform und deren forensische Daten. Sie müssen sich darauf verlassen, dass der Anbieter Vorfälle vollständig erkennt, eingrenzt und transparent kommuniziert. Auch die aktiv ausgenutzte Langflow-Schwachstelle bei IBM zeigt, wie wichtig eigene Protokolle und nachvollziehbare Angriffsdaten für die Bewertung eines Vorfalls sind.
Self-Hosting mit Open-Source-Lösungen wie Keycloak kann mehr Kontrolle über Protokolle, Konfiguration und Untersuchungen bieten. Dafür trägt der Betreiber selbst die Verantwortung für Updates, Absicherung und Verfügbarkeit. Der relevante Unterschied liegt deshalb nicht in einer pauschal höheren Sicherheit, sondern in der Frage, wer Kontrolle, Aufwand und Risiko übernimmt.