Exchange-Server-OWA wird aktiv angegriffen — CVE-2026-42897, Mitigation jetzt, Patch nur für ESU-Kunden

Sechs Tage nach dem Mai-Patchday vom 12. Mai 2026 hat Microsoft am 14. Mai eine außerplanmäßige Sicherheitswarnung für Exchange Server veröffentlicht: Die Schwachstelle CVE-2026-42897 in Outlook Web Access wird aktiv ausgenutzt — und ein dauerhafter Patch steht aktuell nur einem Teil der Kunden zur Verfügung. Die CISA hat die Schwachstelle einen Tag später in den Known Exploited Vulnerabilities Catalog aufgenommen und für US-Bundesbehörden eine Patch-Frist bis zum 29. Mai 2026 gesetzt. Für deutsche Mittelständler ohne CISA-Bindung ist die Lage operativ ähnlich akut, denn die Zero-Day-Ausnutzung läuft seit der Disclosure ohne weitere Eintrittshürden.

Microsoft klassifiziert die Schwachstelle offiziell als Spoofing-Schwachstelle, technisch handelt es sich um eine XSS-Variante in Outlook Web Access. Was nach klassischem Webanwendungsproblem klingt, hat operativ allerdings deutlich gravierendere Wirkung: Eine einzige präparierte E-Mail im Postfach eines Mitarbeitenden reicht aus, damit beliebiger JavaScript-Code im authentifizierten Browser-Kontext der OWA-Sitzung läuft — mit Zugriff auf Postfachinhalte, Session-Tokens und der Möglichkeit, im Namen des Opfers zu agieren. Der Angreifer braucht weder Anmeldedaten noch Insider-Wissen, nur eine valide E-Mail-Adresse des Ziels und einen Anwender, der die Mail in OWA öffnet.

Wer betroffen ist — und wer nicht

Microsoft listet im offiziellen Exchange-Team-Blogpost explizit drei betroffene Produktlinien.

Wer Exchange Online über Microsoft 365 nutzt, muss aktuell nichts unternehmen — Microsoft hat die Schwachstelle in der Cloud-Variante bereits geschlossen. Im Mittelstand betrifft die akute Lage damit vor allem Unternehmen, die aus Datenschutz-, Lizenz- oder Souveränitätsgründen weiterhin Exchange Server On-Premises betreiben. Auch wenn die Microsoft-365-Migration in den letzten Jahren spürbar an Fahrt aufgenommen hat, bleibt das eine relevante Gruppe — vor allem dort, wo Anwaltskanzleien, Steuerberater, Versicherungsbüros und mittelständische Fertigungsbetriebe ihre E-Mail-Infrastruktur bewusst im eigenen Rechenzentrum halten.

Wie der Angriff funktioniert

Der Angriff beginnt mit einer scheinbar harmlosen E-Mail, die im HTML-Body JavaScript-Code transportiert, der so präpariert ist, dass er die OWA-Sanitisierung umgeht. Die Renderlogik filtert eingehende HTML-Inhalte nicht ausreichend — der Schadcode überlebt die Verarbeitung und landet in genau dem Browserfenster, in dem der Empfänger seine Mails liest. Sobald der Empfänger die Mail in OWA öffnet, führt der Browser den Code im Kontext der authentifizierten Exchange-Session aus. Microsoft hat in seiner offiziellen Beschreibung ausschließlich OWA als betroffenen Client genannt — Outlook für Desktop nutzt eine andere HTML-Rendering-Pipeline und ist nicht betroffen, eine explizite Aussage zu Outlook für iOS und Android hat Microsoft bisher nicht veröffentlicht.

Die Folgen sind operativ erheblich. Der eingeschleuste Code kann den Session-Token an einen vom Angreifer kontrollierten Server senden — der Angreifer übernimmt damit die Exchange-Sitzung des Opfers und liest oder versendet E-Mails. Er kann die Postfach-API ansprechen, Adressbuch-Einträge auslesen und gezielt Spear-Phishing-Mails an Kollegen senden, die nun von einer wirklich legitimen Absenderadresse stammen. Und er kann sich, wenn der angegriffene Account weitreichende Postfach-Berechtigungen hat, lateral durch die Organisation bewegen.

Aus Sicht der Angreifer ist das Setup ideal: Keine Schwachstelle im Mail-Gateway umgehen, keine Phishing-Seite hosten, keine geklauten Zugangsdaten ausprobieren — eine einzelne E-Mail trifft direkt im Postfach des Ziels, und der Angriff zündet ausgerechnet dort, wo Anwender besonders viel vertrauen: in ihrem eigenen Webmail-Client.

Mitigation: EEMS automatisch, EOMT manuell

Microsoft bietet zwei Wege, um die Schwachstelle vorübergehend zu entschärfen — beide ohne dauerhaften Patch, aber mit unmittelbarer Schutzwirkung.

Variante 1: Exchange Emergency Mitigation Service (EEMS)

EEMS ist seit Exchange Server 2016 CU22 und Exchange Server 2019 CU11 (September 2021) standardmäßig aktiviert und prüft regelmäßig auf neue Mitigation-Definitionen aus Microsofts Cloud. Bei Servern mit aktiver EEMS-Verbindung hat Microsoft die Mitigation für CVE-2026-42897 automatisch ausgerollt — Administratoren müssen nichts tun, sollten aber die Anwendung verifizieren.

Die Prüfung erfolgt in der Exchange Management Shell:

Get-ExchangeServer | Get-ExchangeMitigation

Das Ergebnis listet die aktiven Mitigations pro Server. Für CVE-2026-42897 muss die zugehörige Mitigation als „Applied" erscheinen. Server, die keine ausgehende Verbindung zu officeclient.microsoft.com aufbauen können — typisch in stark segmentierten Umgebungen oder bei Air-Gap-Betrieb — bekommen das Update nicht automatisch und benötigen die manuelle Variante.

Variante 2: Exchange On-Premises Mitigation Tool (EOMT) manuell

Für Server ohne EEMS-Anbindung stellt Microsoft das EOMT-Skript bereit. Es lädt aktuelle Mitigation-Definitionen, prüft die Exchange-Konfiguration und appliziert die Korrektur über IIS-URL-Rewrite-Regeln und konfigurierbare Exchange-Komponenten.

Für einen einzelnen Server:

.\EOMT.ps1 -CVE "CVE-2026-42897"

Für alle Exchange-Server einer Organisation (Edge-Transport-Server ausgenommen) — die von Microsoft dokumentierte Pipeline-Form:

Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | .\EOMT.ps1 -CVE "CVE-2026-42897"

Status-Prüfung:

.\EOMT.ps1 -ShowMitigationStatus -CVE "CVE-2026-42897"

Die aktuellste EOMT-Version ist im Microsoft Security Response Center verlinkt und sollte vor jedem Einsatz frisch heruntergeladen werden — Microsoft aktualisiert das Skript laufend, ältere Stände decken neuere CVEs nicht ab.

Mit welchen Nebenwirkungen Sie rechnen müssen

Microsoft dokumentiert drei bekannte Nebeneffekte nach Anwendung der Mitigation. Sie sind kosmetisch und beeinträchtigen keine sicherheitsrelevante Funktion, sollten aber im Helpdesk vorab kommuniziert werden, damit Tickets nicht in Eskalations-Loops landen.

Die OWA-Kalender-Druckfunktion arbeitet nach Anwendung der Mitigation nicht mehr zuverlässig — Anwender, die Kalenderwochen oder Tagesübersichten aus OWA heraus drucken, müssen auf den Outlook-Desktop-Client oder eine PDF-Export-Lösung ausweichen. Inline-Bilder im Lesebereich von OWA werden teilweise nicht mehr korrekt dargestellt — sie erscheinen als Platzhalter oder Anhang, statt im Body eingebettet. Die OWA-Light-Variante (URL-Endung /?layout=light) funktioniert nach der Mitigation nicht mehr korrekt; Anwender mit langsamer Verbindung oder Bildschirmleser müssen vorübergehend auf das Standard-Layout wechseln.

Diese Einschränkungen sind aus Sicherheitssicht die richtige Wahl — sie sind das Ergebnis konservativer Filter, die die Angriffsoberfläche reduzieren. Wer sie umgeht, öffnet die Schwachstelle wieder. Der einzige saubere Weg, die Funktionen zurückzubekommen, ist der dauerhafte Patch.

Das Patch-Problem: Extended Security Updates Period 2

Genau hier liegt der zweite Stolperstein. Der dauerhafte Patch — der die Schwachstelle wirklich schließt, nicht nur abriegelt — ist nur Kunden zugänglich, die in Microsofts Extended Security Updates Period 2 eingeschrieben sind. Konkret bedeutet das laut Microsofts Lifecycle-Dokumentation: Exchange Server 2016 und 2019 ohne ESU bekommen die endgültige Korrektur nicht direkt — sie bleiben auf die EEMS/EOMT-Mitigation angewiesen, bis sie entweder ESU lizenzieren, auf die Subscription Edition (SE) migrieren oder ganz nach Exchange Online umziehen.

Die Subscription Edition selbst — Microsofts Nachfolge-Modell mit jährlicher Lizenzierung — bekommt den Patch innerhalb der ESU-Period-2-Kunden direkt. Wer seine Exchange-2019-Installation in den letzten Monaten auf SE migriert hat oder gerade plant, das zu tun, hat den klaren operativen Vorteil schnellerer Patches und einer langfristig stabileren Update-Versorgung.

Für die kritischen Tage zwischen Disclosure und individuellem Patch-Termin gilt: Die Mitigation ist ausreichend, wenn sie tatsächlich appliziert ist und die Status-Prüfung „Applied" zurückgibt. Eine ungeprüfte Anwendung („wir haben die EEMS, also sind wir geschützt") ist in der Praxis keine Seltenheit — der manuelle Verifikationsschritt mit Get-ExchangeMitigation lohnt sich.

Detektion: Worauf Sie zusätzlich achten sollten

Microsoft hat keine offiziellen Indicators of Compromise veröffentlicht, was bei aktiv ausgenutzten Schwachstellen ohne öffentliche Attribution leider üblich ist. Bis offizielle IOCs vorliegen, sind eigene Detektionsregeln auf Verhaltensbasis sinnvoll.

In Exchange- und Webserver-Logs lohnt sich ein Blick auf ungewöhnliche Mengen an OWA-Anfragen pro Postfach — vor allem, wenn sie aus IP-Adressen ohne typische Geo-Verteilung der Belegschaft stammen. Auffällige Set-Mailbox-Operationen oder das Anlegen neuer Inbox-Regeln durch Anwender, die das normalerweise nicht tun, sind weitere Indizien für eine erfolgte Übernahme. Vermehrte Versuche, Postfach-Inhalte über die EWS-Schnittstelle abzurufen — sichtbar in den IIS-Logs des Exchange-Servers — können auf die Postausleitung nach einem erfolgreichen Angriff hindeuten.

Wer einen SIEM- oder EDR-Stack im Einsatz hat, sollte mit dem zuständigen Team eine Detektionsregel für ungewöhnliche OWA-Aktivität definieren — als Übergangslösung, bis Microsoft öffentliche Signaturen nachliefert. Der Aufwand ist überschaubar, der Mehrwert in den nächsten Wochen erheblich.

Die Reihe ProxyLogon, ProxyShell, ProxyNotShell — und jetzt 42897

CVE-2026-42897 reiht sich in eine längere Sequenz schwerer Exchange-On-Prem-Vorfälle ein, die in den letzten Jahren mehrfach für branchenweite Schäden gesorgt haben. ProxyLogon im März 2021 (CVE-2021-26855 und die zugehörige Kette) ermöglichte vollständige Server-Übernahmen ohne Authentifizierung und betraf laut BSI-Lagebericht 2021 auch tausende deutsche Exchange-Server. ProxyShell im August 2021 und ProxyNotShell im September 2022 folgten demselben Muster: unauthentifizierte Pre-Auth-Schwachstellen in der Außenseite des Exchange-Servers, mit Ransomware-Gruppen, die binnen Tagen massenhaft scannten und ausnutzten.

Der aktuelle Fall hat eine etwas andere Mechanik — Phishing-getriebener XSS statt direkter Server-Übernahme — aber denselben strategischen Effekt: Die Sicherheit des gesamten Postfachsystems hängt an einer einzelnen Komponente, die unter aktivem Angriffsdruck steht und auf den manuellen Patch-Rollout durch lokale Administratoren angewiesen ist. Wer aus diesem Muster nach drei Jahren noch nicht die strukturelle Konsequenz gezogen hat, läuft im nächsten Vorfall ins selbe Problem.

Was Anwender im Outlook-Desktop tun müssen

Eine kurze Entwarnung gehört dazu: Der Outlook-Desktop-Client (Win32) und die mobilen Outlook-Apps sind von der Schwachstelle nicht betroffen, weil sie HTML-E-Mails über eine andere Rendering-Pipeline anzeigen als OWA. Wer im Mittelstand ohnehin nahezu ausschließlich Outlook-Desktop nutzt und OWA nur als Notlösung im Browser hat, ist operativ weniger exponiert.

Allerdings: OWA bleibt der Standard-Zugang im Home-Office, beim privaten Endgerät und am Tablet. Solange OWA aktiviert ist — und Microsoft empfiehlt, es als Funktion erreichbar zu lassen — gilt die Schwachstelle für jeden Mitarbeitenden, der die Webmail-Oberfläche auch nur einmal öffnet. Die organisationale Empfehlung „bitte nur Outlook-Desktop nutzen" lässt sich technisch kaum durchsetzen.

Strategische Optionen: ESU, Subscription Edition oder Exchange Online

CVE-2026-42897 wirft eine strategische Frage auf, die viele mittelständische Exchange-Betreiber seit Längerem mit sich tragen: Wie soll der mittelfristige Pfad aussehen — Bestand pflegen, modernisieren oder zur Cloud wechseln? Drei Wege stehen offen, jeder mit eigenen Vor- und Nachteilen. Welcher der richtige ist, entscheidet sich nicht an Microsofts Roadmap, sondern an Datenschutzanforderungen, vorhandenen Investitionen, Integrationsbedarf und IT-Personalstärke des einzelnen Unternehmens.

Bestand pflegen: Exchange 2016/2019 mit ESU Period 2

Wer die bestehende On-Prem-Infrastruktur erhalten möchte, kann über Extended Security Updates Period 2 vorerst weiter den vollen Patch-Zugang halten. Diese Option ist sinnvoll für Unternehmen mit erheblichen Investitionen in die bestehende Exchange-Umgebung, mit sektoralen Vorgaben zu Datensouveränität (Anwaltskanzleien, Steuerberater, Gesundheitssektor, Behörden) oder mit komplexen Integrationen — Praxis-Software, ERP-Anbindungen, branchenspezifische Archivlösungen — die einen Wechsel teuer machen würden. Die laufenden Kosten für ESU-Lizenz, Hardware und Wartung müssen gegen den Migrationspreis und den Aufwand der Mitigation-Pflege abgewogen werden. Mit sauber implementiertem Incident Response-Prozess und konsequenter EOMT-Anwendung ist diese Option auch sicherheitstechnisch tragfähig.

Modernisieren: Exchange Server Subscription Edition

SE ist Microsofts moderne On-Prem-Variante mit jährlicher Lizenzierung und kontinuierlicher Update-Versorgung — ohne die ESU-Paywall der klassischen CU-Versionen. Wer beim On-Prem-Betrieb bleiben will, aber die Lifecycle-Diskussion der CU-Versionen hinter sich lassen möchte, findet hier die ruhigste Patch-Versorgung der drei Optionen. Die Migration erfordert Planung — Mailbox-Verschiebung, Zertifikate, Public Folders, Connectoren — bleibt aber innerhalb der gewohnten Exchange-Welt und ist deutlich weniger disruptiv als ein Wechsel ins Cloud-Modell.

Auslagern: Exchange Online in Microsoft 365

Exchange Online verlagert die operative Patch-Verantwortung zu Microsoft. Das reduziert den eigenen Betriebsaufwand erheblich, schafft aber neue Pflichten: Die DSGVO-Konformität des Datentransfers in US-Cloud-Umgebungen ist seit dem EU-US Data Privacy Framework (Juli 2023) zwar einfacher zu begründen, bleibt aber dokumentationspflichtig — und das Framework selbst ist juristisch nicht unangefochten. Lizenzkosten der Microsoft-365-Pläne, Lock-in-Effekte über die Office-Suite hinaus, und die Geschwindigkeit, mit der Microsoft Funktionen wie Recall, Loop oder Copilot in den Tenant einführen kann, gehören zur Gesamtkostenrechnung. Wichtig auch das Shared-Responsibility-Modell: Microsoft betreibt die Plattform, die Verantwortung für Identitäten, Zugriffsrechte und Datenklassifizierung bleibt vollständig beim Kunden.

Wann ist welcher Weg der richtige?

Die Wahl ist keine Technologie-, sondern eine Geschäftsentscheidung. Datenschutzanforderungen, sektorale Compliance, Betriebskostenrechnung und vorhandene IT-Kapazität sind gleichberechtigte Eingangsgrößen. CVE-2026-42897 ist ein guter Anlass, die Frage strukturiert zu beantworten — sie ist aber kein Argument, das die Antwort schon vorgibt. Wer aktuell on-premises betreibt, hat mit korrekter Mitigation-Anwendung den akuten Vorfall im Griff und kann die Migrationsentscheidung in Ruhe und auf Basis der eigenen Kriterien treffen.

NIS2-Bezug für regulierte Branchen

Für Unternehmen, die unter den Anwendungsbereich von NIS2 fallen — also besonders wichtige und wichtige Einrichtungen nach dem deutschen NIS2UmsuCG — verschiebt sich die Bewertung. Ein erfolgreicher Angriff über CVE-2026-42897 wäre als bedeutender Sicherheitsvorfall meldepflichtig: Die initiale Meldung an das BSI muss innerhalb von 24 Stunden erfolgen, der konkrete Meldebericht innerhalb von 72 Stunden, der Abschlussbericht innerhalb eines Monats. Wer in den nächsten Wochen seine Mitigation-Anwendung nicht dokumentieren kann, hat im Schadensfall ein zusätzliches Compliance-Problem oberhalb des eigentlichen Vorfalls.

Das bedeutet konkret: Die Anwendung der Mitigation muss nicht nur erfolgen, sondern auch nachweisbar sein. Ein knappes Protokoll im IT-Service-Management-System mit Zeitstempel, Server-Name, Mitigation-Status und verantwortlicher Person reicht in der Regel — aber es muss vorliegen, sobald das BSI nach einem Vorfall Nachweise anfordert oder im Rahmen seiner Aufsichtsbefugnisse nach § 64 NIS2UmsuCG eine Prüfung anstößt. Routinemäßige Audits wie in ISO 27001 oder TISAX gibt es unter NIS2 für „wichtige Einrichtungen" — also den Großteil mittelständischer Unternehmen — nicht; die Prüfung erfolgt anlassbezogen. Das macht die Dokumentation nicht weniger wichtig, sondern eher gefährlicher zu vernachlässigen: Sie wird genau dann gebraucht, wenn ohnehin schon etwas schief gelaufen ist.

Aktionsplan für die nächsten 72 Stunden

Konkret heißt das für IT-Teams im Mittelstand: heute oder morgen die Mitigation verifizieren — Get-ExchangeMitigation auf jedem Exchange-Server der Organisation, Ergebnis dokumentieren, bei Servern ohne EEMS das EOMT-Skript ausführen. Anwender vorab über die OWA-Funktionseinschränkungen informieren, damit der Helpdesk nicht in Reaktionsmodus rutscht. Parallel die SIEM- oder EDR-Logs der letzten zwei Wochen rückblickend auf ungewöhnliche OWA-Aktivität prüfen — frühere Exploits dieser Klasse hatten oft eine Phase stiller Aufklärung vor der eigentlichen Angriffswelle. Und schließlich die strategische Frage ESU/SE/Online auf die Tagesordnung des nächsten IT-Lenkungstermins setzen.

Wir unterstützen bei der Umsetzung

Mitigation-Verifikation, Detection-Setup und Migrations-Beratung in einem Schritt. Wir prüfen die Anwendung der CVE-2026-42897-Mitigation auf Ihren Exchange-Servern, richten verhaltensbasierte Detection-Regeln für die kommenden Wochen ein und liefern eine fundierte Bewertung der drei strategischen Optionen — ESU-Verlängerung, SE-Migration oder Wechsel zu Exchange Online. Im Rahmen unserer IT-Schwachstellenprüfung erhalten Sie zusätzlich eine vollständige Analyse Ihrer Exchange-Konfiguration nach BSI-IT-Grundschutz und Microsoft Security Baseline. Sie bekommen eine umsetzbare Maßnahmenliste mit Aufwandsschätzung — und die Dokumentation, die Sie nach NIS2UmsuCG im Vorfallsfall gegenüber dem BSI vorlegen können.

Exchange-Schwachstellenanalyse anfragen.