CVE-2026-62911: Warum 85 Prozent der On-Prem-Exchange-Server angreifbar sind, und was technisch dahintersteckt
Das BSI meldet, dass rund 85 Prozent der On-Premises-Exchange-Server in Deutschland für CVE-2026-62911 anfällig sind. Der Artikel erklärt die Lücke technisch: MRSProxy, fehlendes Channel Binding, NTLM-Relay und die Pwn2Own-Kette von Orange Tsai, dazu die Einordnung der Zahlen und das konkrete Vorgehen.
Das CERT-Bund des BSI hat Ende August 2026 eine Zahl veröffentlicht, die aufhorchen lässt: Rund 85 Prozent der On-Premises-Exchange-Server in Deutschland sind für die Schwachstelle CVE-2026-62911 anfällig. Seit dem 14. August benachrichtigt die Behörde die betroffenen Netzbetreiber. Auslöser ist ein veröffentlichter Proof-of-Concept, der eine vollständige Systemübernahme ermöglicht. Hinter der nüchternen CVE-Nummer steckt eine der interessanteren Exchange-Lücken der letzten Jahre: ein Relay-Angriff über einen Endpunkt, den die meisten Administratoren nicht auf dem Radar haben. Dieser Artikel erklärt den Mechanismus, ordnet die BSI-Zahlen ein und beschreibt das konkrete Vorgehen.
Wer nur das Sicherheitsupdate vom 11. August 2026 einordnen möchte, findet die Übersicht aller sieben CVEs samt Builds und OWA-Light-Abschaltung im Artikel zum August-SU. Hier geht es um die eine kritische Lücke im Detail.
Was CVE-2026-62911 wirklich ist
Microsoft klassifiziert CVE-2026-62911 als Elevation of Privilege mit einem CVSS-Wert von 8.0 und stuft sie als einzige Schwachstelle des August-Patchdays als Critical ein. Die präzisere Beschreibung liefert die CWE-Kategorie: CWE-294, «Authentication Bypass by Capture-Replay». Der Angreifer umgeht die Authentifizierung nicht, indem er ein Passwort errät, sondern indem er eine gültige Authentifizierung eines anderen Kontos abfängt und gegen einen Zielendpunkt wiederverwendet. In der Praxis ist das ein klassischer NTLM-Relay-Angriff.
Entdeckt wurde die Lücke von Orange Tsai vom Forschungsteam DEVCORE. Er demonstrierte sie am Wettbewerb Pwn2Own Berlin 2026, dort als Teil einer Kette aus drei Schwachstellen, die zusammen die Remote-Code-Execution mit SYSTEM-Rechten auf dem Exchange-Server erlaubten. Genau diese Kombination erklärt den scheinbaren Widerspruch in vielen Meldungen: Für sich genommen ist CVE-2026-62911 eine Rechteausweitung, die einen bereits authentifizierten Kontext voraussetzt. Im Verbund mit einer Coercion-Technik, die die Authentifizierung erst erzwingt, wird daraus ein unauthentifizierter Angriff aus dem Netz. Der PoC nutzt genau diesen Verbund.
Der Kern: MRSProxy ohne Channel Binding
Der verwundbare Endpunkt heisst MRSProxy, kurz für Mailbox Replication Service Proxy. Exchange stellt ihn bereit, damit Postfächer zwischen Servern und in Hybrid-Umgebungen zwischen On-Premises und Exchange Online verschoben werden können. MRSProxy akzeptiert Negotiate-Authentifizierung, prüft aber die sogenannten Channel Bindings nicht. Und genau diese Prüfung ist der Kern des Problems.
Channel Binding koppelt die Authentifizierung an den darunterliegenden TLS-Kanal. Vereinfacht gesagt schreibt der Client einen kryptografischen Fingerabdruck der TLS-Verbindung in die Authentifizierungsdaten. Der Server prüft, ob dieser Fingerabdruck zur Verbindung passt, über die die Daten ankommen. Stimmt er nicht überein, wurde die Authentifizierung über einen anderen Kanal geführt, als sie vorgibt, und der Server weist sie ab. Dieses Verfahren ist die technische Grundlage von Extended Protection for Authentication. Fehlt die Prüfung, lässt sich eine an anderer Stelle abgefangene Authentifizierung an den Endpunkt weiterreichen, und der Angreifer wird anschliessend wie das ursprüngliche Konto behandelt.
Der entscheidende Punkt für den Betrieb: Diese Lücke bestand, obwohl Extended Protection in aktuellen Exchange-Versionen längst standardmässig aktiv ist. Der MRSProxy-Endpunkt war eine Ausnahme in der Absicherung; er erzwang das Channel Binding nicht, das andere Endpunkte durchsetzen. Das Sicherheitsupdate schliesst genau diese Lücke, indem MRSProxy die Prüfung nachholt. Deshalb gibt es hier auch keinen Workaround über die Exchange Emergency Mitigation: Das August-Update ist der Fix.
So läuft der Angriff ab
Der veröffentlichte Proof-of-Concept setzt vier Bausteine zusammen. Jeder einzelne ist bekannt; das Zusammenspiel macht den Angriff aus.
| Schritt | Technik | Wirkung |
|---|---|---|
| 1. Coercion | MS-EFSR RPC (PetitPotam) | Zwingt das Maschinenkonto des Exchange-Servers, sich beim Angreifer zu authentifizieren |
| 2. Relay | NTLM-Relay auf den MRSProxy-Endpunkt | Leitet diese Authentifizierung an Exchange weiter |
| 3. Bypass | Fehlendes Channel Binding auf MRSProxy | Exchange akzeptiert die relayte Authentifizierung als das privilegierte Serverkonto |
| 4. Ausführung | Dateischreib-Primitiv, ASPX-Webshell | Platziert eine Webshell und führt Code mit SYSTEM-Rechten aus |
Im ersten Schritt bringt der Angreifer den Exchange-Server dazu, sich von sich aus zu authentifizieren. Dafür dient die Coercion-Technik PetitPotam über die Druck-RPC-Schnittstelle MS-EFSR: Ein präparierter Aufruf veranlasst den Server, sich beim Angreifer mit seinem eigenen Maschinenkonto anzumelden. Dieses Konto besitzt auf dem Exchange-System hohe Rechte. Im zweiten Schritt reicht der Angreifer diese Anmeldung sofort an den MRSProxy-Endpunkt weiter, statt sie selbst zu beantworten. Weil MRSProxy das Channel Binding nicht prüft (Schritt drei), akzeptiert Exchange die weitergereichte Anmeldung, obwohl sie über einen ganz anderen Kanal kam. Der Angreifer agiert nun mit den Rechten des Serverkontos und kann darüber im vierten Schritt eine Datei schreiben, üblicherweise eine ASPX-Webshell, und darüber beliebigen Code als SYSTEM ausführen.
Das Ergebnis ist eine vollständige Übernahme des Servers. Aus Sicht der Betroffenen bedeutet das Zugriff auf sämtliche Postfächer: E-Mails lesen und versenden, Anhänge herunterladen, unabhängig vom einzelnen Benutzer. Ein Exchange-Server ist damit kein isoliertes Mailsystem mehr, sondern ein Fuss in der Tür zum Active Directory dahinter.
Betroffene Versionen und Patches
Betroffen sind alle unterstützten On-Premises-Bauzustände. Das Sicherheitsupdate vom 11. August 2026 hebt die Server auf folgende Builds:
| Version | Build | KB |
|---|---|---|
| Exchange Server SE RTM | 15.2.2562.46 | KB5121573 |
| Exchange Server 2019 CU15 | 15.2.1748.49 | KB5121574 |
| Exchange Server 2019 CU14 | 15.2.1544.44 | KB5121575 |
| Exchange Server 2016 CU23 | 15.1.2507.72 | KB5121576 |
Hier liegt die eigentliche Ursache der hohen Anfälligkeitsquote. Exchange Server 2016 und 2019 sind seit Oktober 2025 ausser regulärem Support. Ihre Sicherheitsupdates von Mai bis Oktober 2026 erhält nur, wer im kostenpflichtigen Extended-Security-Updates-Programm (Period 2) eingeschrieben ist. Nach BSI-Angaben sind in Deutschland aber nur neun Exchange-Server 2016/2019 bekannt, auf denen ein Patch über dieses Programm installiert wurde. Der grosse Rest bleibt schlicht ungepatcht.
Exchange Online ist von der Lücke nicht betroffen; Microsoft hat die Cloud-Seite bereits abgesichert. In Hybrid-Umgebungen muss das Update trotzdem auf jeden On-Premises-Server, auch auf reine Management-Server und Maschinen, auf denen nur die Exchange Management Tools installiert sind.
Die BSI-Zahlen richtig lesen
Die Erhebung stammt vom CERT-Bund, das über eigene Scans und Partnerdaten den Patch-Stand der aus dem Internet erreichbaren Exchange-Server ermittelt. Drei Zahlen sind zentral, und sie hängen zusammen.
Erstens: Ende Oktober 2025 liefen 92 Prozent der rund 33’000 On-Premises-Exchange-Server in Deutschland auf einer nicht mehr unterstützten Version. Das ist die strukturelle Ausgangslage. Zweitens: Rund 85 Prozent dieser Server sind für CVE-2026-62911 anfällig, weil ihnen der August-Patch fehlt. Drittens: Nur neun Server sind über das Period-2-ESU-Programm nachweislich gepatcht. Die Zahlen zeichnen dasselbe Bild aus zwei Blickwinkeln. Ein grosser Teil der Server ist nicht deshalb ungepatcht, weil ein Update übersehen wurde, sondern weil es für die eingesetzte Version regulär gar keins mehr gibt. Der eigentliche Rückstand ist keine Patch-Lücke, sondern eine Migrationslücke.
Für die Schweiz liegt keine vergleichbare flächendeckende Erhebung vor. Die Ausgangslage ist aber strukturell ähnlich, denn Exchange 2016 und 2019 sind auch hier weit verbreitet und seit Oktober 2025 gleichermassen ausser Support. Das NCSC (Bundesamt für Cybersicherheit) empfiehlt bei kritischen, aktiv ausnutzbaren Lücken durchgehend das umgehende Einspielen der Updates. Wer in der Schweiz On-Premises-Exchange 2016 oder 2019 betreibt, steht vor derselben Entscheidung wie die deutschen Betreiber: patchen über ESU als Übergang, dann migrieren.
Was jetzt zu tun ist
Die Massnahmen sind klar und in dieser Reihenfolge sinnvoll.
Spielen Sie das August-Sicherheitsupdate auf allen Exchange-Servern ein. Für Exchange SE ist es ein reguläres, öffentliches Update. Für Exchange 2016 und 2019 setzt es die Einschreibung im Period-2-ESU-Programm voraus; ohne diese Einschreibung erreicht Sie der Patch nicht. Ein Umgehungsverfahren über die Exchange Emergency Mitigation existiert für diese Lücke nicht.
Prüfen Sie, ob Extended Protection auf allen Endpunkten aktiv und korrekt konfiguriert ist. Es ist die dauerhafte, strukturelle Absicherung gegen Relay-Angriffe dieser Art und blockiert sie, wo das Channel Binding greift. Das Update und Extended Protection ersetzen einander nicht: Der Patch schliesst die konkrete MRSProxy-Lücke, Extended Protection härtet die Authentifizierung insgesamt. Beides gehört zusammen.
Beschränken Sie den Zugriff aus dem Internet auf die webbasierten Exchange-Dienste. Ein Server, dessen Verwaltungs- und Replikationsendpunkte nicht offen aus dem Netz erreichbar sind, etwa weil sie nur über VPN zugänglich sind, entzieht diesem Angriff die Grundlage. Das ersetzt das Update nicht, verkleinert aber die Angriffsfläche spürbar.
Und die eigentliche Konsequenz aus den BSI-Zahlen: Planen Sie die Migration weg von Exchange 2016/2019. Das ESU-Programm ist eine Brücke bis Oktober 2026, kein Dauerzustand. Wer heute im ESU-Programm patcht, kauft Zeit für den geordneten Wechsel auf Exchange SE oder nach Exchange Online, nicht mehr. Jeder weitere Monat auf einer nicht mehr unterstützten Version verlängert die Zeit, in der die nächste Lücke ohne verfügbaren Patch trifft.

Kommentare
Die Kommentare werden von GitHub / Giscus geladen.