Entra ID Sicherheitslücke CVE-2026-69836: Der Exploit-Alarm war falsch

Eine Entra ID Sicherheitslücke mit dem höchstmöglichen CVSS-Wert von 10.0 machte am 21. August 2026 die Runde: CVE-2026-69836 erlaube unauthentifizierte Codeausführung in Microsofts Cloud-Identitätsdienst, und sie werde bereits ausgenutzt. Der erste Teil stimmt. Der zweite nicht. Microsoft hat das Exploitation-Kennzeichen im eigenen Advisory binnen eines Tages zurückgezogen – und genau daraus lässt sich mehr lernen als aus der Lücke selbst.

Was in CVE-2026-69836 technisch steckt

Die Beschreibung ist knapp: „Deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network.” Dahinter steht CWE-502, also unsichere Deserialisierung: Der Dienst baut aus übergebenen Daten wieder Objekte, und dabei wird Code ausgeführt, der dort nie hätte landen dürfen.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

• CVSS 3.1: 10.0 (kritisch), Vektor AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
• Schwachstellentyp: CWE-502, Deserialisierung nicht vertrauenswürdiger Daten
• Betroffenes Produkt: Microsoft Entra, in der NVD als „exclusively-hosted-service” gekennzeichnet
• NVD-Veröffentlichung: 20. August 2026, MSRC-Release am selben Tag
• Gemeldet von Robert Fitzpatrick – laut Help Net Security und BleepingComputer Principal Security Engineer bei Microsoft; im MSRC-Advisory selbst steht dazu nichts.

Der Wert „Changed” beim Scope im CVSS-Vektor ist der Grund für die glatte 10.0. Mit „Unchanged” käme dieselbe Lücke auf 9.8. Übersetzt heißt das: Die Auswirkung bleibt nicht auf die verwundbare Komponente beschränkt. Bei Entra ID – dem Nachfolger von Azure Active Directory, der über den Zugang zu Microsoft 365, Azure und angebundenen Drittanwendungen entscheidet – ist das plausibel.

Für Administratoren gibt es nichts zu installieren. Microsoft schreibt im Advisory: „This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take. The purpose of this CVE is to provide further transparency.” Das Feld customerActionRequired steht entsprechend auf false.

Der Exploit-Alarm und seine Korrektur

Am 21. August meldeten mehrere Fachmedien eine aktive Ausnutzung – teils mit Einschränkung wie bei Help Net Security („reportedly exploited in the wild”), teils ohne. The Hacker News hat den eigenen Artikel nachträglich korrigiert und dem Text den Hinweis vorangestellt, die Lücke sei nicht ausgenutzt worden.

Nachprüfbar ist die Sache über die MSRC-API. Sie führt zu CVE-2026-69836 eine Revisionshistorie, und dort steht als Version 1.1 mit Datum 21. August 2026 wörtlich: „Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only.” Das Feld exploited steht seither auf No, die Temporal-Bewertung auf E:U – Exploit Unproven.

Zwei unabhängige Prüfungen bestätigen das Bild: Die NVD enthält eine SSVC-Bewertung des CISA Coordinators vom 21. August mit „exploitation: none” (bei „automatable: yes” und „technicalImpact: total”). Und im KEV-Katalog der CISA – abgerufen am 23. August 2026 in der Fassung 2026.08.21 mit 1.674 Einträgen – taucht der CVE nicht auf.

Der Ablauf ist also: Eine fehlerhafte Kennzeichnung im Erst-Advisory, eine Welle von Schlagzeilen, eine stille Korrektur einen Tag später. Wer nur die Schlagzeile gelesen hat, trägt bis heute eine falsche Angriffslage mit sich herum.

Was das für dich bedeutet

Aus CISO-Sicht sind hier zwei Dinge interessant, und die Lücke ist keines davon.

Erstens: Cloud-CVEs kann man nicht aus Schlagzeilen bewerten. Bei einem klassischen On-Premises-Patch ist die Meldung ziemlich stabil – die Version, die den Fehler behebt, ändert sich nicht mehr. Bei einem rein gehosteten Dienst veröffentlicht Microsoft die CVE erst, nachdem selbst gepatcht wurde, und Metadaten wie das Exploitation-Flag werden danach nachgezogen. In diesem Fall lagen zwischen Erstveröffentlichung und Korrektur genau ein Tag. Wer Advisories in einen Prozess einspeist, sollte deshalb nicht nur die CVE-Nummer erfassen, sondern die Revisionsnummer – und bei Microsoft-CVEs die MSRC-Revisionshistorie prüfen, bevor eine Meldung ins Risikoregister wandert.

Zweitens: „Nichts zu tun” ist keine Aussage über die Vergangenheit. Ein serverseitiger Fix schützt ab dem Zeitpunkt der Behebung. Auch wenn hier nach Herstellerangabe keine Ausnutzung stattfand, gilt der Grundsatz: Bei einem Dienst, dessen Innenleben du nicht siehst, kann dir nur deine eigene Protokollierung sagen, was in deinem Mandanten passiert ist. Bei einem Domänencontroller im eigenen Rechenzentrum kannst du die Build-Nummer prüfen. Bei Entra ID musst du dem Advisory glauben. Diese Asymmetrie gehört in die Risikobetrachtung – nicht in eine Fußnote.

Und die Konfiguration bleibt in jedem Fall deine Baustelle: Conditional Access, App-Registrierungen, Berechtigungen von Dienstprinzipalen, privilegierte Rollen. Der Identitätsdienst mag Microsoft gehören, dein Mandant nicht.

Konkret: Diese Schritte lohnen sich jetzt

• Log-Aufbewahrung prüfen – das ist der wichtigste Punkt. Audit- und Sign-in-Logs bleiben laut Microsoft-Dokumentation in Entra ID Free nur sieben Tage im Portal, mit P1 oder P2 sind es 30 Tage. Wer mehr braucht, muss sie über Azure Monitor in ein Storage-Konto, ein Log-Analytics-Arbeitsbereich oder ein SIEM ausleiten. Wichtig: Eine spätere Lizenzerhöhung wirkt nicht rückwirkend – nach einem Upgrade von Free auf Premium sind nur die letzten sieben Tage vorhanden, alles Ältere ist weg.
• Dienstprinzipale und App-Registrierungen inventarisieren. Dort sammeln sich stillschweigend erteilte Berechtigungen an, die niemand mehr überprüft. Suche gezielt nach Anwendungen mit weitreichenden Graph-Rechten und nach Zugangsdaten ohne Ablaufdatum.
• Notfallzugang testen. Zwei Break-Glass-Konten, von Conditional Access ausgenommen, mit Alarmierung bei Nutzung – und mindestens einmal jährlich tatsächlich ausprobiert, nicht nur dokumentiert.
• Phishing-resistente Anmeldung für privilegierte Rollen durchsetzen. Realistisch kommen Angreifer selten über eine CVSS-10.0-Lücke in deinen Mandanten, sondern über abgefangene Anmeldedaten. FIDO2-Hardwareschlüssel schließen genau diesen Weg; welche Modelle sich lohnen, steht im Ratgeber zu FIDO2-Sicherheitsschlüsseln.
• Cloud-Advisories dokumentieren, auch ohne Patch. Schon damit im nächsten Audit jemand belegen kann, dass sie bewertet wurden – inklusive Revisionsstand.

Ein Blick zurück lohnt sich ebenfalls: Bei den Microsoft-Sicherheitsupdates im August 2026 waren Azure, Entra und Active Directory bereits Schwerpunkt. Die Identitätsschicht bleibt das lohnendste Ziel – unabhängig davon, wer den Server betreibt.

Quellen

• Microsoft Security Response Center: CVE-2026-69836 (Revision 1.1 vom 21.08.2026, „Corrected Exploited to No”; über die MSRC-API abgerufen am 23.08.2026)
• NVD: CVE-2026-69836 (CVSS 10.0, CWE-502, SSVC-Bewertung des CISA Coordinators vom 21.08.2026)
• CISA: Known Exploited Vulnerabilities Catalog (Fassung 2026.08.21, 1.674 Einträge – CVE nicht enthalten)
• Microsoft Learn: Microsoft Entra data retention
• Help Net Security: Critical Microsoft Entra ID vulnerability (CVE-2026-69836), 21.08.2026
• The Hacker News: Microsoft Patches Severe Entra ID Flaw (CVSS 10.0)