18 kritische Lücken in Microsofts Cloud — und niemand musste etwas tun

Was tatsächlich passiert ist

Microsoft hat die Schwachstellen in der Nacht zum Freitag, dem 21. August 2026, veröffentlicht und nach eigenen Angaben bereits geschlossen (heise online, 24.08.2026). Weil es Cloud-Dienste betrifft, mussten IT-Verantwortliche nicht aktiv werden — gepatcht wurde auf den Servern des Herstellers.

Auf der Liste stehen Dienstnamen, die in vielen Betrieben das Rückgrat bilden. Sechs Einträge mit CVSS 10,0, unter anderem eine Remotecodeausführung in Microsoft Entra ID (CVE-2026-69836), eine in Azure Managed Instance for Apache Cassandra (CVE-2026-65770) und Rechteausweitungen in Azure Arc (CVE-2026-69555, CVE-2026-65816), Azure SQL Database (CVE-2026-69502) sowie in Microsoft Exchange Online (CVE-2026-65801). Danach folgen Einträge in den Bereichen 9,9 und 9,6, etwa in Entra ID, Azure SQL Database und Azure Logic Apps, sowie mehrere Lücken mit hohem Risiko unter anderem in Azure Virtual Machines und Microsoft Copilot in Azure.

Bemerkenswert ist ein Detail am Rand. Zur Entra-ID-Lücke CVE-2026-69836 schrieb Microsoft zunächst, sie sei bereits attackiert worden. Im Laufe desselben Tages korrigierte der Konzern den Eintrag auf „No" — die Lücke wurde doch nicht in freier Wildbahn angegriffen. Zu keiner der 18 Lücken steht inzwischen, dass sie aktiv ausgenutzt wurde. Die Menge kritischer Lücken mit Höchstwertung in Diensten wie Exchange Online bleibt trotzdem auffällig.

Meine Einordnung

Ich habe einen guten Teil meiner Berufsjahre damit verbracht, Patchstände zu takten, Wartungsfenster zu legen und Rollbacks vorzubereiten. Für einen Betrieb mit rund 300 Servern war das ein fester Kalender. In der Cloud fällt dieser Kalender weg — und mit ihm das Wissen. Kann jemand in Ihrem Haus sagen, wie lange die Exchange-Online-Lücke offen war und wer in diesem Fenster Zugriff auf Postfächer hatte? In den Betrieben, die ich kenne: nein. Das ist kein Vorwurf an die IT. Es ist die Konstruktion. Beim eigenen Server haben Sie Protokolle. In der Cloud haben Sie eine Statusseite und ein Änderungsprotokoll, das nachträglich korrigiert wird — genau das ist am 21. August passiert.

Meiner Erfahrung nach wird die Diskussion deshalb an der falschen Stelle geführt. Viele mittelständische Betriebe verhandeln über Firewall-Regeln, Endpoint-Agenten und Netztrennung — alles berechtigt. Der wirksamere Hebel liegt aber in der Identität. Wer ist Global Administrator? Gibt es ein eigenes Adminkonto ohne Postfach, ohne Lizenz für den Assistenten? Ist Mehrfaktor-Anmeldung wirklich überall aktiv, auch für Dienstkonten und Partnerzugänge? Wie viele Gastkonten haben Zugriff auf Teams und SharePoint, und wer hat sie eingeladen? In Entra ID reicht ein falsch berechtigtes Konto, und der Angreifer sitzt nicht mehr am Netzrand, sondern in der Verwaltungsoberfläche. Mein Standardtest bei Übernahmen ist unspektakulär: Ich frage, wie lange es dauert, bis ein neues globales Adminkonto existiert — und ob dabei jemand eine Benachrichtigung erhält.

„Die Cloud ist sicherer" stimmt deshalb, ist aber unvollständig. Sicherheit in der Cloud ist keine Eigenschaft, sondern eine Zurechnung. Der Anbieter patcht Ihre Dienste und haftet nicht für Ihre Berechtigungen. Und die Informationsbasis ist schmal: Ein Feld im Herstellerportal wechselt von „Yes" auf „No", und die Risikobewertung von gestern ist damit falsch. Wer Nachweise braucht — gegenüber Kunden, Banken, einer Zertifizierung nach ISO 27001 oder den Meldepflichten aus NIS2 — kann sich nicht auf Herstelleraussagen verlassen, sondern braucht eigene Protokolle, ein eigenes Berechtigungsverzeichnis und einen Prozess, der auch dann greift, wenn niemand Zeit hat.

Was Sie jetzt konkret tun können

1. Administratorinventar erstellen. Alle Konten mit globalen oder Exchange-Administratorrechten auflisten. Jedes Konto ohne konkrete Person dahinter begründen oder abschalten.

2. Mehrfaktor-Anmeldung ohne Ausnahme. Auch für Dienst-, Partner- und Notfallkonten. Ein einziges ausgenommenes Konto hebt den Schutz der anderen auf.

3. Getrennte Adminkonten einführen. Eigenes Konto, kein Postfach, keine Alltagsnutzung — die tägliche Arbeit läuft in einem normalen Konto.

4. Protokolle selbst behalten. Klären, was protokolliert wird, wie lange und wo. 90 Tage Aufbewahrung sind kein Konzept für ein Jahr.

5. Einmal von außen prüfen lassen. Conditional-Access-Regeln, Gastzugänge, privilegierte Rollen, Legacy-Authentifizierung. Der Blick von außen findet meist in einer Stunde, was intern seit Jahren offensteht.

Unterstützung ist sinnvoll, sobald Sie reguliert sind oder wenn die Administration Ihrer Microsoft-Umgebung niemand im Haus bewerten kann. Wie ich bei IT-Security vorgehe und wo die Themen aus IT-Infrastruktur andocken, steht auf den jeweiligen Seiten.

Quellen

• heise online, „Microsoft stopft zahlreiche Cloud-Schwachstellen", 24.08.2026 — https://www.heise.de/news/Microsoft-stopft-zahlreiche-Cloud-Schwachstellen-11423129.html
• Microsoft Security Response Center, Update Guide zu CVE-2026-69836 (Entra ID), veröffentlicht am 21.08.2026 — https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-69836