MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

CVE-2026-42897 EEMS M2.1 OWA CSP

Am 12. Mai 2026 hat Microsoft noch gebloggt, dass es im Mai 2026 kein Security Update-Paket (CU/SU) für Exchange SE/2019/2016 gibt und a, 14. Mai wurde dann ganz schnell ein per EEMS - Exchange Emergency Mitigation Service bereitgestellte temporäre Härtung verteilt, weil ein Angreifer eine besonders formatierte Mail an ein Exchange OnPremises Postfach senden kann, die beim Lesen des Anwenders mittels Browser in OWA einen Schaden verursachen kann.

Vermutlich war die Zeit zu kurz, einen Patch zu entwickeln und zu testen und daher hat man den Weg über EEMT gewählt.

Lücke

Der CVE beschreibt nur, dass eine "besondere Mail" von einem Benutzer in OWA geöffnet werden muss, um einen Schaden zu provozieren. Die Lücke wird aber zumindest am 15. Mai noch nicht ausgenutzt und es gibt zu dem Zeitpunkt auch noch keinen öffentlichen Proof of Concept. Das kann sich aber noch ändern aber das Problem ist demnach, wie Exchange vermutlich Anlagen einer Mail zur Anzeige an den  Client ausliefert, der dann darin enthaltenen Code oder URLs nachlädt und ggfls. ausführt. Die Schutzfunktionen des Browsers, dass der Schadcode von einer andere URL nicht den gleichen Vertrauenslevel hat, wie die OWA-URL wird dabei wohl ausgehebelt. Es gibt also drei Komponenten, die hier mitspielen müssen und die auch den Schaden minimieren könnten.

  • SMTP-Transport mit Schutzfunktion
    Jeder Mailserver nutzt Spamfilter aber auch Malware-Erkennung, um die Anwender vor schädlichem Code, insbesondere als Anlage, zu schützen. NoSpamProxy hat, wie viele andere Programme eine Funktion, um URLs umzuschreiben und beim Aufruf durch den Anwender gesondert erneut zu prüfen. Als Firma könnten Sie auch überlegen, zu bestimmte Anlagen, z.B. PDF, DOCX, XLSX, PPTX zu erlauben oder zumindest die meist schädlichen Anlagen wie .EXE, .BAT, .PS1, .JS, .vbs und natürlich Makros (DOCM, XLSM, PPTM etc.) zu blocken. Das scheint aber hier nicht auszureichen.
  • Exchange Server
    Wenn Exchange die Mails interpretiert und für die Auslieferung an einen Browser aufbereitet, dann "liest" Exchange zum Teil die Mail. Exchange Server könnte hier etwas genauer hinschauen, und gewisse Inhalte blockieren. Das macht Exchange in Bezug auf CVE-2026-42897 anscheinend nicht ausreichend. Ich erwarte aber, dass Microsoft hier eine dauerhafte Lösung schafft.
  • Browser/Malwarescanner auf dem Client
    Im Grunde muss der Browser den Daten vertrauen, die er von einem Webserver bezieht und es ist gar nicht einmal ungewöhnlich, dass eine HTML-Datei oder hier vermutlich eine HTML-Mail auch Inhalte nachlädt. Wir kennen das von Outlook, dass z.B. als "<img>"-Tag eingebundene externe Bilder meist nicht automatische geladen werden, sondern eine gesonderte Bestätigung durch den Anwender erfordern. Wenn OWA nun eine Anlage einer Mail öffnen, die der Browser der "Exchange-Zone" zuweist, dann sollte das dennoch kein Freibrief sein, alles ungeprüft auszuführen.
    Übrigens hat Microsoft extra eigene "Download-Domains" für Anlagen erstellt, um die Lücke CVE-2021-1730 zu umgehen. Das scheint hier aber nicht auszureichen

Am 15. Mai konnte ich noch keine weitergehenden Informationen über die Lücke und deren Risiken und Ausnutzung in Erfahrung bringen. Das ist aber nicht ungewöhnlich. So gewinnen Hersteller und Administratoren etwas Zeit, entsprechenden Gegenmaßnahmen umzusetzen.

Gegenmaßnahmen

Seit Sep 2021 hat Microsoft alle Exchange Server mit dem EEMS - Exchange Emergency Mitigation Service ausgestattet, der regelmäßig bei Microsoft nach sehr kritischen Lücken sucht, die sofort abgesichert werden müssen. Das war auch eine Erfahrung aus dem Hafnium Exploit. Der IIS ist schon allein durch seine Erreichbarkeit aus dem Internet ein immer wieder gerne attackierte Gegenstelle. Nachdem EEMS erstmals beim Exchange-0-day-Exploit 2022 aktiviert wurde, ist es nun  hier in dem Fall erneut soweit, dass Microsoft über EEMS auf allen Exchange Servern einen temporären Fix ausrollt, der ohne Neustart sehr schnell aktiv wird. Sie können über mehrere Wege kontrollieren, ob der Fix schon auf ihrem Server aktiv ist.

Die Bilder sind von einem Exchange 2019 CU15 Server, der nicht im ESU-Programm ist. Das ist aber nur ein "Quick Fix".
Der richtige Fix wird später über ein Security Updates kommen, welches aber nur Kunden mit ESU bekommen. Alle anderen werden wohl mit den Einschränkungen leben müssen.

Die Tatsache, das Microsoft hier ein EEMT-Update an alles Server verteilt, könnte ein Hinweis auf sein wirklich hohes Risiko sein. Der CVE meldet zwar "nur" ein 8,5 und "User interaction required", wodurch es nicht das Potential eines Hafnium Exploit hat, aber anscheinend ist es schon ernst genug, damit nicht auf die nächsten Security Updates im Juni 2026 zu warten.

  • PowerShell
    Mit folgendem Befehl können Sie auf dem Server den Patch M2.1.0 prüfen:

    Mein Server meint hier ein "Mitigation invalid for this exchange version". Das ist aber eine falsche Aussage und Microsoft hat dies auch dokumentiert.

.We are aware of the mitigation showing the "Mitigation invalid for this exchange version." in mitigation details. This issue is cosmetic and the mitigation DOES apply successfully if the status is shown as "Applied"
Quelle: https://techcommunity.microsoft.com/blog/exchange/addressing-exchange-server-may-2026-vulnerability-cve-2026-42897/4518498& 

  • Eventlog
    Wie ich auf EEEMS - Exchange Emergency Mitigation Service schon beschrieben habe, protokolliert der Mitigation Service die Anwendung auch im Eventlog:
  • Logfile C:\Program Files\Microsoft\Exchange Server\V15\Logging\MitigationService
    Der Service wendet die Updates jede Stunde immer wieder an und protokolliert auch jedes Vorkommen.
  • IIS-Einstellung
    Die Schutzfunktion wird über eine URL_Rewrite-Regel im IIS umgesetzt.

Wenn ihr Exchange Server keine Verbindung zu den Microsoft Endpunkten im Internet aufbauen darf, dann können und sollten Sie den Hotfix manuell einspielen

Exchange On-premises Mitigation Tool (EOMT)
https://aka.ms/UnifiedEOMT
https://microsoft.github.io/CSS-Exchange/Security/EOMT/

Laden Sie das Skript auf einem anderen Computer herunter und starten Sie es auf dem Exchange Server

Invoke-WebRequest https://aka.ms/UnifiedEOMT -OutFile EOMT.ps1	
	
.\EOMT.ps1 -CVE "CVE-2026-42897"

Einschränkungen

Der schnelle Fix über eine  URL_Rewrite-Regel blockiert die Anforderung und damit die Auslieferung bestimmte Inhalte. Damit ist zwar die Lücke nicht mehr ausnutzbar aber auch erwünschte Funktionen sind blockiert. Microsoft führt dazu aus:

  • Kalender in OWA drucken funktioniert nicht
    Man könne aber z.B. einen Screenshot machen und Drucken
  • Inline-Bilder werden nicht der Lese-Ansicht nicht angezeigt.
    Der Absender sollte die Bilder als normale Anlage senden oder Sie lesen die Mails mit Outlook
  • OWA Light funktioniert nicht mehr korrekt
    Das Feature wurde übrigens schon 19. Aug 2026, also für mehr als 20 Monaten abgekündigt. Interessant, das es im Code immer noch nutzbar war und nicht durch ein CU/SE deaktiviert wurde.
  • Angeblich fallen einige Monitoring-Probes auf die Nase
    Bei mir war es die "OWACalendarProxyTestProbe", welche ich wie folgt deaktiviert habe, bis Microsoft mit dem Security Update oder einer feineren Filterbedingung wieder korrigiert.
Add-GlobalMonitoringOverride `
   –Identity OWACalendar.Proxy\OWACalendarProxyTestProbe `
   -Item Probe `
   -PropertyName Enabled `
   -PropertyValue 0 `
   -ApplyVersion "15.02.2562.17"

Es könnten natürlich noch weitere Einschränkungen im laufe der Zeit bekannt werden.

Details

Die Umsetzung durch EEMS als URL_Rewrite-Regel erlaubt uns natürlich im IIS die Anpassungen von Microsoft zu betrachten. Hier der Blick auf einen Exchange 2019 CU15 Server. Ich bin aber sicher, dass die Änderungen auch bei den anderen Versionen identisch sind. Sie sind nämlich sehr einfach gehalten.

Auf dem Exchange Frontend-Server wird im "owa"-Verzeichnis eine neue "URL Rewrite"-Regel angelegt:

Diese Regel hat als Action einfach mal die Funktion, das Feld "script-src-attr" auf "none" zu setzen. Damit wird dem Browser mitgeteilt, dass er keine Skripte auf dieser Seite weiter ausführen soll.

Das Gilt natürlkich nicht generell, sondern nur für gewisse Pfade und Dokumente.

Die Regular Expression für "REQUEST_URI" ist  

^/owa/?($|\?|default\.aspx|projection\.aspx|readingPane\.aspx|popout\.aspx)

Die M2.1.0-Mitigation blockiert also die Ausführung von Skripten, wenn diese einen "text/html"-Inhalt liefern, der über folgende URLs ausgeliefert würde:

/owa/
/owa/?
/owa/default.aspx
/owa/projection.aspx
/owa/readingPane.aspx
/owa/popout.aspx

Anscheinend gibt es für Angreifer einen Weg, eine HTML-Mail an einen Exchange Empfänger zu senden, in der Skripte enthalten sind, die dann vom Browser ausgeführt werden würden. Outlook wird ja hoffentlich "sicher genug" sein, um Skripte in HTML-Mails einfach gar nicht auszuführen aber ein Browser kann das ja erst einmal nicht erkennen. Für ihn ist auch OWA erst mal nur eine Webseite

Zwischenstand

Exchange Server liefern HTML-Mails per OWA an Clients aus, die dann im Body hinterlegte Skripte ausführen. Mehr Details weiß ich noch nicht aber es war Microsoft wohl so wichtig, auf allen Exchange 2016/2019/SE-Servern per EEMS eine URL-Rewrite-Regel zu verteilen, um das erst mal per Script-Directive komplett zu blocken. Leider habe ich kein Sample aber wenn es "<script>"-Blöcke im Body einer Mail sind, dann sollte auch ein SMTP-Malware-Filter dies erkennen und unschädlich machen können. Ich würde solche Mails ja konsequent abweisen. Skripte in HTML-Mails sehe ich als ähnlich gefährlich an, wie Makros in Office Dokumente.

Interessant wird nun natürlich das nächste Security Updates für Exchange 2016/2019, welche nur Kunden mit aktivem ESU-Vertrag erhalten sollen. Microsoft hat lange und deutlich gesagt, dass der Exchange 2016/2019-Support im Oktober 2025, also vor mehr als 7 Monaten schon abgelaufen ist und das ESU-Programm eigentlich nur aufgelegt wurde, um die Kunden nicht im Regen stehen zu lassen, die mit der Migration noch nicht fertig sind. Ob diese Lücke zusammen mit dein Einschränkungen nun weitere Kunden dazu bringt, ESU zu kaufen, würde ich bezweifeln. Denn ab Oktober 2026 sollte auch der letzte Exchange 2016/2019 außer Betrieb gehen

Weitere Links