Microsoft-Edge-Sicherheitslücke entkam der sandbox ohne Speicherfehler
Eine Kette von Sicherheitslücken in Microsoft Edge ermöglichte es einer bösartigen Webseite, aus der Browser-sandbox auszubrechen und Code auf einem Windows-Computer auszuführen, ohne memory corruption auszunutzen. Eine sandbox ist eine Isolationsgrenze, die verhindern soll, dass Code von Webseiten den übrigen Teil eines Geräts erreicht. Microsoft korrigierte die betroffenen Edge-Komponenten im Mai. Browser, die auf die Stable-Version 148.0.3967.70 aktualisiert wurden, sind für diese Angriffskette nicht anfällig.
Ein DEVCORE-Forscher demonstrierte die Technik im Mai bei Pwn2Own Berlin, erhielt dafür 175.000 US-Dollar und veröffentlichte fünf Monate später, am 28. Oktober, einen ausführlichen Bericht. Microsoft veröffentlichte die Fehlerbehebungen am 15. Mai, einen Tag nach dem Wettbewerb, und DEVCORE erklärte, die Reaktion habe ab der Meldung weniger als 24 Stunden gedauert. Es handelte sich um eine Demonstration im Rahmen eines Wettbewerbs und nicht um einen bekannten realen Angriff. Öffentliche CVE-Einträge melden keine Ausnutzung, und es gibt keine Hinweise darauf, dass die Angriffskette gegen Nutzer eingesetzt wurde.
Das Ungewöhnliche an der Untersuchung ist, dass sie nicht auf memory corruption angewiesen war. Diese tritt auf, wenn Software Daten im Arbeitsspeicher fehlerhaft verarbeitet, und kann mitunter dazu gebracht werden, unerwünschte Anweisungen auszuführen. Stattdessen kombinierte der Exploit Fehler in den Regeln, die legitime Funktionen von Edge und Windows steuern. Nach Angaben des Forschers umfasste der fertige Exploit weniger als 100 Codezeilen. Das Ermitteln und Zusammenfügen der erforderlichen Schwachstellen erforderte jedoch etwa zwei Monate manueller Arbeit ohne Unterstützung durch künstliche Intelligenz.
Die erste Stufe führte zu universal cross-site scripting (UXSS), einer Schwachstelle auf Browserebene, durch die JavaScript im Kontext anderer Webseiten ausgeführt werden kann. Sie umging außerdem Content Security Policy (CSP), eine Webseitenregel, die begrenzt, welche Skripte und anderen Ressourcen eine Seite laden darf. Da die Navigation von einem Edge-Prozess und nicht von einer gewöhnlichen Webseite ausging, konnte die Technik Webseiten wie google.com betreffen, die mit einer herkömmlichen Skripting-Schwachstelle einer Webseite nicht erreichbar wären. DEVCORE bezeichnete dieses Verhalten als eine breitere attack surface und nicht als isolierten Fehler einer Webseite.
Die Angriffskette begann bei einer Edge-Komponente für geschäftliche Anmeldungen, dem sogenannten conditional access navigation throttle. Durch dessen Auslösung begann der Browserprozess eine Navigation, die nicht mehr mit der Seite verknüpft war, von der sie angefordert worden war. Edge verband diese Navigation anschließend mit dem jeweils aktiven Browser-Tab. Diese fehlerhafte Zuordnung verschaffte dem Angreifer die UXSS-Fähigkeit.
Vier weitere Schwachstellen ermöglichten, dass der Vorgang ohne einen Klick funktionierte. Edge versuchte zu überprüfen, ob die Anfrage von einer vertrauenswürdigen Microsoft-Webseite stammte. Der Forscher umging diese Prüfung jedoch, indem er die Anfrage über ein zweites Fenster auslöste. Ein Popup-Blocker hätte das zusätzliche Fenster verhindern sollen, doch Edge enthielt eine fest einprogrammierte Liste zulässiger Adressen, von denen eine das Öffnen des Popups erlaubte. Der Angriff setzte außerdem voraus, dass das Opfer angemeldet war. Diese Voraussetzung wurde durch die automatische Anmeldefunktion von Edge erfüllt, sobald der Nutzer eine Microsoft-Webseite besuchte. Schließlich gab assets.msn.com aufgrund eines falsch konfigurierten cross-origin setting die E-Mail-Adresse des Opfers an jede beliebige Webseite weiter. Ein solches cross-origin setting steuert, ob eine Webseite Daten an eine andere übermitteln darf.
Das Ausführen von JavaScript auf Webseiten verschaffte noch keine Kontrolle über Windows. Daher zielte die Angriffskette als Nächstes auf Immersive Reader, den Lesemodus von Edge. Diese Funktion wurde unter einer eigenen read://-Adresse ausgeführt, doch Microsoft hatte diese Adresse nicht in die Gruppe der Seiten aufgenommen, auf denen die Ausführung von Skripten untersagt war. Der Forscher nutzte diese Lücke, um eine interne Edge-Funktion aufzurufen, die Diagnoseprotokolle komprimieren sollte. Durch den Missbrauch dieser Funktion konnte der Exploit an einer beliebigen Stelle auf dem Datenträger eine Datei mit vom Angreifer ausgewähltem Inhalt und Namen erstellen.
Der beliebige Schreibzugriff auf Dateien führte über zwei weitere Schritte zu code execution. Zunächst ersetzte die Angriffskette eine Konfigurationsdatei, die festlegte, welche Webseiten protocol handlers öffnen durften. Dabei handelt es sich um Programme, die bestimmten Arten von Links zugeordnet sind. Anschließend startete sie Edge neu, damit der Browser die veränderte Konfiguration lud. Laut dem Forscher vereinfachte der Neustart die Demonstration im Wettbewerb, wäre bei einem realen Angriff jedoch nicht erforderlich.
Danach öffnete der Exploit einen telnet://-Link. Windows enthält standardmäßig kein Telnet-Programm und suchte daher im Systempfad nach einem geeigneten Programm. Die Angriffskette nutzte diese Suche aus, indem sie eine vom Angreifer kontrollierte Kopie in einem Ordner ablegte, in den der Nutzer mit geringen Berechtigungen schreiben konnte. Windows führte diese Kopie anschließend aus und vollendete damit den Übergang von einer bösartigen Webseite zu außerhalb der Browser-sandbox ausgeführtem Code.
Edge Stable 148.0.3967.70 enthielt drei Edge-spezifische Sicherheitskorrekturen, die als CVE-2026-45492, CVE-2026-45494 und CVE-2026-45495 erfasst sind. Microsoft stuft die erste als security feature bypass und die zweite als spoofing-Problem ein; beide betreffen Versionen vor 148.0.3967.70. Jeder dieser beiden Einträge weist einen Schweregrad von 5,4 von 10 auf. Diese mittlere Bewertung beschreibt jede Schwachstelle einzeln und bildet nicht die Auswirkungen ab, die sich ergeben, wenn die Fehler zu einer Kette für code execution kombiniert werden.
Für Webseitenbetreiber zeigen die Ergebnisse, dass Browserfehler Schutzmaßnahmen außer Kraft setzen können, die auf einer einzelnen Webseite korrekt konfiguriert wurden, einschließlich CSP, da der Fehler auf Browserebene auftrat. Der direkte Schutz besteht darin, Edge auf dem neuesten Stand zu halten. Automatische Updates haben die Mai-Version bereits an Browser ausgeliefert, die Updates regulär erhalten. Nach der Installation des Updates verlangt Microsoft keine gesonderten Maßnahmen. Organisationen, die nach Schwachstellen wie diesen ihre allgemeinen Sicherheitspraktiken überprüfen, bietet AEU-I sicherheitsorientierte IT, Infrastruktur und Beratung an.
Die Untersuchung zeigt außerdem, warum einzeln betrachtet mittelschwere Logikfehler wesentlich schwerwiegender werden können, wenn sie über Browser- und Betriebssystemfunktionen hinweg miteinander kombiniert werden. Die einzelnen Verhaltensweisen zu finden, war der schwierige Teil der Arbeit. Nachdem alle Bestandteile bekannt waren, ließ sich ihre Verknüpfung vergleichsweise einfach umsetzen. Die Untersuchung erhielt später den Pwnie Award 2026 for Epic Achievement. Die praktische Schlussfolgerung für Nutzer bleibt jedoch einfach: aktuelle Edge-Updates installieren und den Browser neu starten, wenn dazu aufgefordert wird.