Es gibt Patchday-Lücken, die man in Ruhe im nächsten Wartungsfenster einplant. Und es gibt Lücken, bei denen sich die Lage nachträglich ändert. CVE-2026-62911 gehört in die zweite Kategorie.
Die Schwachstelle wurde am 11. August 2026 mit den Exchange-Sicherheitsupdates geschlossen. Microsoft stufte sie zwar als kritisch ein, setzte den Exploit-Status aber auf „Exploitation Less Likely“. Für viele Administratoren war das der Grund, das Update nicht mit höchster Priorität zu behandeln. Ende August ist dann funktionierender Exploit-Code auf GitHub aufgetaucht. Damit ist die Bewertung von Microsoft überholt, und jeder ungepatchte Exchange Server ist ein realistisches Ziel.
Wer noch auf dem Juli-Stand oder älter ist, sollte nicht bis zum September-Patchday warten.
Wie es dazu kam
Der Ablauf erklärt, warum die Einstufung von Microsoft so danebenliegt.
14. bis 16. Mai 2026: Auf der Pwn2Own Berlin demonstriert Orange Tsai vom DEVCORE Research Team eine Kette aus drei Schwachstellen, die zusammen Remote Code Execution mit SYSTEM-Rechten auf einem vollständig gepatchten Exchange Server ergeben. Dafür gibt es 200.000 US-Dollar Preisgeld und 20 Punkte in der Master-of-Pwn-Wertung. Die Organisatoren deuten an, dass das in Redmond für Nachtschichten sorgen dürfte. Details bleiben unter Verschluss, die Meldung läuft über die Zero Day Initiative an Microsoft.
Juni und Juli 2026: Es kommen Exchange-Updates, aber keine Bestätigung, ob der Pwn2Own-Fund damit erledigt ist. In der Community wird spekuliert.
11. August 2026: Das August-SU erscheint und schließt sieben Exchange-CVEs. Im Exchange Team Blog steht dazu die übliche Standardformulierung. Dass CVE-2026-62911 der Pwn2Own-Fund ist, bestätigt das Exchange-Team erst auf Nachfrage im Kommentarbereich der Release-Ankündigung.
Ende August 2026: Ein Sicherheitsforscher veröffentlicht auf GitHub einen Proof of Concept, der die Lücke praktisch nutzbar macht. Der Code ist frei verfügbar. Erfahrungsgemäß dauert es nach so einer Veröffentlichung nicht lange, bis die ersten Massenscans laufen.
Man kennt das Muster von ProxyLogon. Zwischen „theoretisch ausnutzbar“ und „wird flächendeckend gescannt“ liegen bei Exchange üblicherweise Tage, nicht Wochen.
CVE-2026-62911 im Detail
CVSS: 8.0 (Basis) / 7.0 (temporal), CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Schwerwiegenkeit: Kritisch (Microsoft-Einstufung), CWE-294 Authentication Bypass by Capture-replay
Bedrohung: Rechteausweitung über einen Authentifizierungs-Bypass in Microsoft Exchange Server
Exploits: Öffentlich verfügbarer Proof of Concept seit Ende August 2026. Microsoft führt die Lücke weiterhin als „Exploitation Less Likely“ mit Exploit Code Maturity „Unproven“. Diese Bewertung stammt vom Veröffentlichungstag und bildet die aktuelle Lage nicht mehr ab. Die ZDI hat Microsoft nach eigener Aussage funktionierenden Exploit-Code übergeben. Aktive Angriffe in freier Wildbahn sind bisher nicht bestätigt, ein Eintrag im CISA-KEV-Katalog liegt noch nicht vor.
Technische Zusammenfassung: Exchange stellt den MailboxReplicationProxyService (MRSProxy) für Postfachverschiebungen über zwei Pfade bereit. Der Pfad unter /EWS/MRSProxy.svc läuft über den IIS und ist durch Extended Protection abgesichert. Der zweite Endpunkt hängt direkt an HTTP.sys und wird von Extended Protection nicht erfasst. Er akzeptiert Negotiate-Authentifizierung, prüft aber die Channel Bindings nicht.
Genau diese Prüfung ist der Kern von Extended Protection. Fehlt sie, lässt sich eine Authentifizierung, die eigentlich für ein anderes Ziel bestimmt war, an diesen Endpunkt weiterreichen. Ein klassischer Relay-Angriff also. Der Dienst behandelt den Angreifer anschließend als das Konto, dessen Authentifizierung weitergereicht wurde.
Kritisch wird es durch eine Berechtigungs-Voreinstellung: Computerkonten besitzen standardmäßig das Recht ms-Exch-EPI-Token-Serialization. Wer die Authentifizierung eines Exchange-Computerkontos weiterreichen kann, erhält damit vollen Zugriff auf den WCF-Dienst. Von dort führt der Weg über eine unzureichend validierte Pfadangabe zu einem Dateischreibvorgang in ein vom IIS ausgeliefertes Verzeichnis. Das Ergebnis ist eine Webshell, die als NT AUTHORITY\SYSTEM läuft.
Ausnutzbarkeit: Hier weicht die offizielle Beschreibung von der Praxis ab. Microsoft spricht im CVE-Text von einem „authorized attacker“ und der Vektor enthält PR:L (niedrige Privilegien) sowie UI:R (Benutzerinteraktion erforderlich). Der veröffentlichte Proof of Concept kommt ohne beides aus: Er nutzt eine unauthentifizierte Coercion-Technik über MS-EFSR, um einen Exchange Server zur Authentifizierung an einem vom Angreifer kontrollierten Endpunkt zu bewegen, und leitet diese dann weiter. Gültige Zugangsdaten braucht es dafür nicht. Voraussetzung ist Netzwerkzugriff auf die betroffenen Dienste sowie eine Umgebung mit mindestens zwei Exchange Servern, weil das Relay-Ziel nicht identisch mit dem auslösenden Server sein kann.
Für die Praxis heißt das: Wer eine Multi-Server-Umgebung betreibt, sollte von einer Vorauthentifizierungslücke ausgehen, nicht von einer Lücke, die einen kompromittierten Benutzeraccount voraussetzt.
Auswirkungen: Nach erfolgreichem Angriff kann auf sämtliche Postfächer der Organisation zugegriffen werden. Mails lesen, Mails im Namen beliebiger Benutzer versenden, Anhänge herunterladen. Über die Webshell mit SYSTEM-Rechten ist der Server selbst kompromittiert, womit auch der Weg ins Active Directory offensteht. Bei einer Exchange-Kompromittierung geht es also nicht um einen Server, sondern um den Vertrauensanker der gesamten Kommunikationsinfrastruktur.
Workaround: Einen offiziellen Workaround von Microsoft gibt es nicht. Wirksam abgesichert ist die Lücke nur durch das August-SU. Risikomindernd wirken eine vorgeschaltete Authentifizierung über einen Reverse Proxy, konsequent aktivierte Extended Protection auf allen dafür vorgesehenen virtuellen Verzeichnissen, das Blockieren der bekannten Coercion-Vektoren auf RPC-Ebene sowie die Einschränkung von NTLM in Richtung Exchange. Keine dieser Maßnahmen ersetzt das Update, sie verschaffen aber Zeit.
Dringlichkeit: Hoch. Sofort patchen, nicht auf das reguläre Wartungsfenster warten.
Die weiteren sechs Lücken aus dem August-SU
| CVE | Kategorie | CVSS |
|---|---|---|
| CVE-2026-62913 | Remote Code Execution | 8.8 / 7.7 |
| CVE-2026-62914 | Spoofing (OWA Light) | 7.3 / 6.4 |
| CVE-2026-62910 | Elevation of Privilege | 7.2 / 6.3 |
| CVE-2026-62912 | Denial of Service | 6.5 / 5.7 |
| CVE-2026-62915 | Security Feature Bypass | 6.5 / 5.7 |
| CVE-2026-65813 | Elevation of Privilege | 6.5 / 5.7 |
Alle sieben Lücken sind über das Netzwerk ansprechbar. CVE-2026-62913 hat mit 8.8 formal den höheren Basiswert als CVE-2026-62911, spielt in der aktuellen Lage aber die kleinere Rolle, weil dafür kein öffentlicher Exploit vorliegt.
Betroffene Versionen und Ziel-Builds
| Exchange-Version | SU | KB | Ziel-Build | Verfügbarkeit |
|---|---|---|---|---|
| Exchange Server SE RTM | SU9 | KB5121573 | 15.2.2562.46 | Öffentlicher Download |
| Exchange Server 2019 CU15 | SU10 | KB5121574 | 15.2.1748.49 | Nur über ESU Period 2 |
| Exchange Server 2019 CU14 | SU13 | KB5121575 | 15.2.1544.44 | Nur über ESU Period 2 |
| Exchange Server 2016 CU23 | SU24 | KB5121576 | 15.1.2507.72 | Nur über ESU Period 2 |
Liegt die Build-Nummer unter dem Wert in der Tabelle, fehlt das August-Update und der Server ist angreifbar.
Exchange Online ist bereits geschützt, hier besteht kein Handlungsbedarf am Dienst selbst. Wer eine Hybrid-Umgebung betreibt, muss die lokalen Server trotzdem aktualisieren.
Management-Tools-Workstations nicht vergessen. Auch Arbeitsplätze, auf denen nur die Exchange-Verwaltungstools installiert sind, brauchen das Update.
Exchange 2013 und älter bekommen keine Updates mehr. Diese Systeme gehören abgeschaltet.
Die ESU-Falle bei Exchange 2016 und 2019
Der unangenehme Teil: Exchange 2016 und 2019 sind seit Oktober 2025 aus dem Support. Das August-SU gibt es für diese Versionen ausschließlich über das kostenpflichtige Extended-Security-Update-Programm der Phase 2. Wer keine ESU-Lizenz gebucht hat, bekommt schlicht keinen Patch für CVE-2026-62911.
Damit nicht genug. Seit dem Juni-Update hat Microsoft serverseitig etwas am Exchange Emergency Mitigation Service geändert. Server, die nicht mindestens auf dem Juni-2026-Stand sind, können keine neuen Mitigations mehr verarbeiten. Der Rettungsanker, mit dem Microsoft in der Vergangenheit auch ungepatchte Systeme kurzfristig absichern konnte, funktioniert bei diesen Servern nicht mehr. Bereits ausgerollte Mitigations laufen weiter, neue kommen nicht mehr an.
Für Behörden und kommunale IT bedeutet das eine klare Entscheidung: entweder ESU lizenzieren oder die Migration auf Exchange Server SE beziehungsweise Exchange Online zügig abschließen. Ein ungepatchter, aus dem Internet erreichbarer Exchange 2016 ist unter NIS2-Gesichtspunkten kaum noch vertretbar. Das BSI hatte bereits im Oktober 2025 auf Zehntausende gefährdete Exchange-Server in Deutschland hingewiesen, und die Zahl dürfte sich seitdem nicht wesentlich verbessert haben.
Was jetzt zu tun ist
1. Aktuellen Stand ermitteln
In der Exchange Management Shell:
Get-Command ExSetup.exe | ForEach-Object {$_.FileVersionInfo}
Der Befehl Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion zeigt nur den CU-Stand und nicht das installierte Sicherheitsupdate. Für die Prüfung auf das August-SU taugt er also nicht.
Zuverlässiger ist der Health Checker:
# Download unter https://aka.ms/ExchangeHealthChecker
.\HealthChecker.ps1
Ein korrekt aktualisierter Exchange SE meldet Version: Exchange SE RTM Aug26SU und Build Number: 15.02.2562.046.
2. Update installieren
Aus der Praxis der letzten Wochen haben sich zwei Punkte bewährt. Erstens: zuerst die Windows-Updates einspielen und neu starten, danach das Exchange-SU. Zweitens: Bei Installationsproblemen mit der Meldung „Diese Anwendung konnte nicht gestartet werden“ hilft es, den Virenschutz vorübergehend zu deaktivieren. Für die Installation selbst sollte man je nach Umgebung 20 bis 45 Minuten einplanen.
Nach der Installation Server neu starten, Health Checker erneut laufen lassen und prüfen, ob alle Exchange-Dienste sauber gestartet sind.
3. Extended Protection prüfen
Die Lücke lebt davon, dass ein Endpunkt keine Channel Bindings prüft. Extended Protection sollte deshalb in jeder Umgebung durchgängig aktiv sein, auch wenn es diese konkrete Lücke nicht allein schließt. Der Health Checker weist fehlende Extended Protection aus, für die Konfiguration gibt es das Skript ExchangeExtendedProtectionManagement.ps1 aus dem CSS-Exchange-Repository von Microsoft.
4. OWA Light
Mit diesem SU deaktiviert Microsoft den OWA-Light-Client dauerhaft. Hintergrund ist CVE-2026-62914, und der betroffene Code wird nicht mehr gepflegt. Wer das August-SU aus irgendeinem Grund nicht installieren kann, sollte OWA Light zumindest manuell abschalten:
Set-OwaMailboxPolicy -OwaLightEnabled $false
Set-OwaVirtualDirectory -LogonPageLightSelectionEnabled $false
Das ist keine Absicherung gegen CVE-2026-62911, sondern betrifft ausschließlich die Spoofing-Lücke.
5. Auf Kompromittierung prüfen
Wer erst jetzt patcht, sollte anschließend nachsehen, ob der Server bereits besucht wurde. Sinnvolle Prüfpunkte:
- Neu angelegte oder veränderte
.aspx-Dateien in den vom IIS ausgelieferten Exchange-Verzeichnissen, insbesondere unteraspnet_clientsowie in denauth-Unterverzeichnissen von OWA und ECP. Ein Abgleich der Dateizeitstempel gegen das Datum der letzten CU- oder SU-Installation findet Auffälligkeiten schnell. - IIS-Logs auf ungewöhnliche POST-Requests gegen die MRSProxy-Endpunkte, vor allem aus Quellen, die keine Exchange Server sind.
- Prozessbaum:
w3wp.exeals Elternprozess voncmd.exeoderpowershell.exeist auf einem Exchange Server praktisch immer ein Befund. - NTLM-Authentifizierungen von Computerkonten an Exchange-Endpunkten, die nicht zum normalen Betriebsmuster passen.
- Neue oder veränderte lokale Administratorkonten und geplante Aufgaben auf dem Exchange Server.
Bei einem Treffer gilt die übliche Regel: Der Server ist nicht mehr vertrauenswürdig. Incident-Response-Prozess starten, nicht einfach die Webshell löschen und weitermachen.
6. Bekannte Probleme im Blick behalten
Für das August-SU selbst sind bisher keine eigenen Probleme bekannt. Der Punkt aus dem Juni besteht aber weiter: In Hybrid-Umgebungen können nach der Installation sogenannte Wrapper-Nachrichten in Shared Mailboxes auftauchen. Microsoft dokumentiert das unter KB5105719. Zusätzlich nennt der KB-Artikel zum SU Probleme mit veröffentlichten Kalendern (HTTP 500 bei ICS-Abrufen) und mit der Frei/Gebucht-Abfrage delegierter Postfächer in reinen Graph-Hybrid-Konfigurationen.
Einordnung
Zwei Dinge nimmt man aus diesem Fall mit.
Das eine ist die Frage, wie belastbar Herstellerbewertungen bei der Priorisierung sind. „Exploitation Less Likely“ hat hier viele Administratoren in eine falsche Sicherheit gewiegt, obwohl die Lücke drei Monate zuvor auf einer öffentlichen Bühne als Teil einer vollständigen Server-Übernahme demonstriert worden war. Diese Information stand jedem zur Verfügung. Wer ausschließlich auf das Exploitability Assessment im Update Guide schaut, verliert Zeit, die man bei internetseitig erreichbaren Diensten nicht hat. Der Kontext einer Lücke gehört genauso in die Bewertung wie der CVSS-Wert.
Das andere ist die Kommunikation. Dass der Pwn2Own-Fund im Exchange Team Blog keine eigene Erwähnung fand und erst auf Nachfrage im Kommentarbereich bestätigt wurde, macht Administratoren die Arbeit unnötig schwer. Wer den Zusammenhang zwischen der Mai-Demonstration und CVE-2026-62911 nicht selbst hergestellt hat, konnte die Dringlichkeit aus den offiziellen Quellen kaum ableiten.
Und der Rest bleibt, wie er ist: Ein lokaler Exchange Server ist eine dauerhafte Betriebsaufgabe. Wer ihn betreibt, braucht ein Patchfenster, das innerhalb von Tagen greift, und keines, das im Quartalsplan steht.