Es gibt diesen einen Moment in jedem Patch-Zyklus, an dem klar wird: Der ruhige Mai war eine Tarnung. Microsoft hatte den 12. Mai 2026 mit 137 CVEs und – ungewoehnlich genug – ganz ohne aktiv ausgenutzte Zero-Days abgeschlossen. Sicherheitsteams im deutschen Mittelstand atmeten kurz durch. Genau 48 Stunden spaeter, am 14. Mai, riss diese Ruhe. Microsoft veroeffentlichte ein ausserplanmaessiges Advisory: CVE-2026-42897, eine Schwachstelle in Outlook Web Access (OWA) des on-premises Exchange Servers, wird seit Tagen aktiv ausgenutzt – und es gibt keinen Patch. Nur eine Notfall-Mitigation namens M2.

Diese Geschichte trifft die deutsche Wirtschaft an einer empfindlichen Stelle. Trotz aller Cloud-Predigten betreiben tausende mittelstaendische Unternehmen Exchange noch immer im eigenen Rechenzentrum: Anwaltskanzleien, Maschinenbauer, Krankenhaeuser, kommunale Versorger. Jede dieser Mailbox-Infrastrukturen ist seit dem 14. Mai potenziell verwundbar – und ein einziges gut gemachtes E-Mail reicht, um die Kette ins Rollen zu bringen.

Was CVE-2026-42897 wirklich tut

Microsoft beschreibt die Luecke vorsichtig als "Spoofing". Das ist technisch korrekt, klingt aber harmlos. Hinter dem Label verbirgt sich eine Cross-Site-Scripting-Schwachstelle (XSS) in der Render-Logik von Outlook Web Access. Der CVSS-Score steht bei 8.1 – hoch, aber kein "kritisch" im klassischen Sinne. Diese Zahl unterschaetzt, was die Schwachstelle in der Praxis bedeutet.

Der Angriffsablauf ist erschreckend gradlinig:

Ein Angreifer sendet eine speziell praeparierte E-Mail an eine Mailbox auf einem verwundbaren on-premises Exchange Server. Sobald der Empfaenger diese Mail in OWA oeffnet – nicht im Outlook-Client, sondern im Browser – wird unter bestimmten Interaktionsbedingungen JavaScript im OWA-Kontext ausgefuehrt. Das ist der entscheidende Punkt: Der Browser glaubt, dieser Code stamme vom legitimen Exchange-Server. Damit hat der Angreifer Zugriff auf alles, was OWA dem Nutzer zeigt: Mailbox-Inhalt, Kalender, Adressbuch, gespeicherte Cookies, AntiForgery-Tokens, gegebenenfalls SSO-Cookies.

In der Praxis bedeutet das: Vollstaendige Sitzungsuebernahme. Der Angreifer kann im Namen des Opfers Mails lesen und versenden, Weiterleitungs-Regeln anlegen, Geschaeftskorrespondenz spiegeln. Bei Konten mit erweiterten Rechten – Sekretariate, Assistenzen, IT-Administratoren mit OWA-Zugang – eskaliert das schnell zur kompletten Lateral Movement. Genau dieses Muster sehen Incident-Responder seit dem 13. Mai bei den ersten Vorfaellen im Mittelstand.

Warum es keinen klassischen Patch gibt

Microsoft hat am 14. Mai ein Advisory veroeffentlicht, aber bewusst kein kumulatives Update. Stattdessen kam die Korrektur ueber die Exchange Emergency Mitigation (EM) Service-Infrastruktur, die seit September 2021 standardmaessig auf jedem aktuellen Exchange-Server laeuft. Die spezifische Mitigation traegt die Kennung M2.1.x und greift in zwei Ebenen ineinander:

Erstens schreibt M2 eine IIS-URL-Rewrite-Regel auf Server-Ebene, die den Zugriff auf die verwundbaren OWA-Pfade fuer die Deserialisierungs-Endpunkte blockiert. Zweitens installiert die Mitigation ein temporaeres IIS-Modul, das einkommende Anfragen auf weiteren OWA-Pfaden sanitisiert und manipulierte serialisierte Payloads entfernt, bevor sie die Anwendungsschicht erreichen. Beide Massnahmen wirken automatisch – aber nur, wenn der EM Service auf dem Server aktiviert ist und die Internetverbindung zu Microsofts Office Config Service funktioniert.

Genau hier liegt der Stolperstein, ueber den sich die deutsche IT-Landschaft gerade die Knie schlaegt: Viele Mittelstaendler haben den EM Service in der Vergangenheit deaktiviert. Manchmal aus Datenschutz-Reflex, oft nach Empfehlungen aelterer Hardening-Guides, gelegentlich, weil ein interner Proxy die Verbindung nach aussen verhindert. Auf diesen Systemen wirkt die Notfall-Mitigation nicht. Sie sind ungeschuetzt.

Was Administratoren in den naechsten 24 Stunden konkret tun muessen

Es gibt eine klare, schmerzhaft kurze Sofortliste. Wer Exchange Server 2016, 2019 oder Subscription Edition betreibt, muss jetzt die folgenden Schritte abarbeiten – idealerweise heute, bevor der Wochenend-Schichtbetrieb startet:

Schritt 1 – Status des EM Service pruefen. Auf jedem Exchange-Server via PowerShell:

Get-OrganizationConfig | Format-List MitigationsEnabled
Get-ExchangeServer | Format-List Name, MitigationsApplied, MitigationsBlocked

Wenn MitigationsEnabled auf $true steht und MitigationsApplied die Eintraege M2.1.1 oder hoehere Varianten enthaelt, ist die Server-Instanz geschuetzt.

Schritt 2 – Health Checker laufen lassen. Microsoft hat den Exchange Health Checker (Stand v25.x, abrufbar ueber das offizielle GitHub-Repository) so erweitert, dass er die spezifische Mitigation M2.1.x meldet. Das Skript prueft zusaetzlich, ob das Office Config Service erreichbar ist. Fehlende Konnektivitaet wird explizit ausgewiesen.

Schritt 3 – Fallback fuer Server ohne EM Service. Wenn der EM Service deaktiviert ist, muss die Mitigation manuell ueber das Cmdlet Set-ExchangeServer -Identity <Server> -MitigationsEnabled $true aktiviert werden. Anschliessend einmalig das Skript Test-MitigationServiceConnectivity.ps1 ausfuehren. Wer den EM Service aus Compliance-Gruenden weiterhin nicht nutzen kann, muss die IIS-URL-Rewrite-Regeln und das Sanitizing-Modul manuell deployen – Microsoft stellt die Konfigurationsbloecke im Advisory bereit.

Schritt 4 – OWA-Zugriff hart absichern. Solange die Mitigation greift, sollte OWA aus dem oeffentlichen Internet zusaetzlich hinter einem Reverse-Proxy mit Conditional Access und MFA stehen. Geo-Blocking auf nicht relevante Regionen reduziert die Angriffsflaeche massiv – die ersten beobachteten Exploits stammen aus IP-Bereichen ausserhalb des DACH-Raums.

Schritt 5 – Forensik auf zurueckliegende 14 Tage. Da der Exploit bereits in der Wildbahn ist, muessen IT-Verantwortliche pruefen, ob betroffene Server in den letzten zwei Wochen Anzeichen einer Kompromittierung zeigen: ungewoehnliche OWA-Logins, neue Mailbox-Regeln (insbesondere Auto-Weiterleitungen), Aenderungen an Delegationen, neue Application-Impersonation-Rechte. Microsoft empfiehlt dazu das offizielle Exchange-Logsuche-Skript und die Korrelation mit AD-Anmeldeereignissen.

Bekannte Nebenwirkungen der Mitigation

Microsoft macht im Advisory keinen Hehl daraus: Mitigation M2 hat funktionale Nebenwirkungen. Die Print Calendar-Funktion in OWA kann zeitweise versagen, Inline-Bilder in eingehenden Mails werden in der OWA-Vorschau nicht oder verzerrt dargestellt. Fuer Anwender, die Outlook fuer Windows nutzen, sind diese Effekte unsichtbar – aber jede Organisation, die OWA zum Standard-Client gemacht hat (typisch bei reinen Web-Mitarbeitern, Bring-your-own-Device-Setups oder schlanken Linux-Arbeitsplaetzen), spuert die Einschraenkungen sofort. Wer den Service-Desk auf eine erwartbare Welle vorbereitet, spart sich das Krisengespraech am Montagmorgen.

Der groessere Kontext: On-Prem Exchange ist 2026 ein strategisches Risiko

CVE-2026-42897 ist nicht der erste Exchange-Vorfall dieses Jahres. Wir hatten ProxyLogon-Aufarbeitungen, wir hatten Probleme mit den Kumulativen Updates, wir hatten Schwierigkeiten mit dem Subscription Edition-Lifecycle. Jede dieser Episoden hat dieselbe Botschaft: Wer Exchange weiterhin selbst betreibt, traegt eine substantielle Sicherheitsverantwortung, die mit jedem Jahr teurer wird. Die Patch-Faktur fuer das laufende Jahr summiert sich beim deutschen Mittelstand auf zigtausend Notfall-Stunden – Zeit, die in der internen Informationssicherheit dringend an anderer Stelle gebraucht wuerde.

Die rationale Antwort ist nicht "alle in die Cloud", aber sie ist auch nicht "weiter so wie 2018". Wer aus regulatorischen Gruenden (Berufsgeheimnis, Datenresidenz, branchenspezifische Vorgaben) on-premises bleiben muss, braucht eine harte, betriebliche Disziplin: aktiviertes EM-Service, monatlicher Patch-Rhythmus mit garantiertem 72-Stunden-Fenster, gehaerteter OWA-Zugriff hinter MFA und Conditional Access, segmentiertes Backup mit getesteten Wiederherstellungen. Diese Massnahmen ergeben sich nicht aus einzelnen Empfehlungen, sondern aus einer durchgaengigen Sicherheitsarchitektur. Wer sie nicht selbst aufbauen kann, sollte rechtzeitig externe Unterstuetzung suchen. Eine pragmatische, am Risiko ausgerichtete Beratung beginnt bei uns mit einem Blick auf die aktuelle Leistungsuebersicht und endet idealerweise in einem belastbaren Mitigations-Plan, bevor das naechste Advisory eintrudelt.

Was wir bei pleXtec in den naechsten Tagen sehen werden

Wenn das Muster der vergangenen Exchange-Zero-Days haelt, folgen in den naechsten 72 Stunden drei Wellen. Erstens: opportunistische Massenscans, die jeden ueber das Internet erreichbaren OWA-Endpunkt durchprobieren. Zweitens: gezielte Spear-Phishing-Kampagnen, die fuer den Mittelstand zugeschnittene Lockmails generieren – mit deutschen Phrasen, lokalem Branchen-Kontext, gefaelschten Lieferanten-Identitaeten. Drittens: ein Patch von Microsoft, vermutlich als ausserplanmaessiges Sicherheitsupdate, irgendwann zwischen Mitte und Ende Mai. Bis dahin steht und faellt der Schutz mit der Mitigation M2 und dem disziplinierten Monitoring.

Wer jetzt handelt – heute, nicht am Wochenende, nicht in der naechsten Wartungs-Slot-Diskussion – minimiert das Risiko substanziell. Wer wartet, geht eine Wette ein, die in den vergangenen Exchange-Zero-Days regelmaessig verloren ging.

Fazit

CVE-2026-42897 ist die unbequeme Erinnerung daran, dass Patch-Tuesday nicht der Endpunkt eines Risiko-Zyklus ist, sondern bestenfalls dessen Anfang. Eine Exchange-Mailbox-Infrastruktur, die nicht innerhalb von 24 Stunden auf einen Out-of-Band-Vorfall reagieren kann, ist 2026 strukturell nicht mehr betreibbar. Die Mitigation M2 ist ein Werkzeug, kein Wundermittel – und sie funktioniert nur dort, wo Vorbereitung und Disziplin schon vorher stimmten.

Wenn Sie unsicher sind, ob Ihre Exchange-Infrastruktur den Stand von gestern – oder den von vorgestern – widerspiegelt: Sprechen Sie uns an. Eine kurze Lagebild-Sichtung dauert weniger Zeit als die Aufraeumarbeiten nach einem Vorfall. Den Erstkontakt finden Sie unter /kontakt.