Security researcher Orange Tsai has uncovered a complex exploit in Microsoft Edge that strings together five separate vulnerabilities and two Windows features to run code outside the browser’s sandbox — all without triggering a user click. Disclosed on October 28, 2026, the exploit was developed for Pwn2Own Berlin 2026, took two months of research, required no AI, and was implemented in under 100 lines of code.
How the Exploit Works
The chain begins in Edge’s Conditional Access navigation handler. This component is intended to switch users into the correct browser profile when accessing Microsoft services by checking the provided email address. If the email matches the active profile, Edge will proceed with a navigation request to a destination URL. However, instead of tying that navigation to the original tab, Edge incorrectly opens it in whichever tab is currently active. This mix-up allows attacker-controlled JavaScript designed for one site to execute in the context of another — a universal cross-site scripting (UXSS) condition.
Other steps in the chain subvert multiple security checks. Edge attempts to verify whether navigation originates from a Microsoft site, but a cross-window flow bypasses that check. Additionally, a built-in popup exception lets malicious windows open without the user clicking anything. Taken together, these flaws strip away the need for any manual interaction once a hostile page has loaded. Edge’s OneAuth functionality further smooths the path: if a user already has a Microsoft account, OneAuth may auto-create and log into an Edge profile when visiting a Microsoft site. A misconfiguration in cross-origin resource sharing (CORS) on assets.msn.com exposes the signed-in email to attacker-controlled pages.
From UXSS to Code Execution
UXSS alone doesn’t reach into the operating system. To move from script execution to native code, the researcher turned to Edge’s Immersive Reader and its use of the read:// address scheme. Edge neglected to block JavaScript URLs on privileged pages, exposing a feedback API that’s supposed to package diagnostic logs. By exploiting deficiencies in path traversal and null-byte handling, the exploit writes files outside the temporary folder and strips the enforced.json extension — enabling it to host a malicious executable.
To make that executable run outside Edge’s sandbox, the chain modifies Edge’s configuration file for external protocol handlers, protocols.json. Once altered, a webpage can launch Windows protocol handlers — in this case, the built-in telnet handler — to invoke the executable. By placing the malicious file in a directory that Windows checks for executables, the exploit gains full code execution on the host machine.
Implications & Defense
This exploit chain is notable because it doesn’t rely on memory corruption or buffer overflow bugs. Instead, it stitches together logic bugs, browser-feature interactions, and insufficient isolation between components. It underscores the risk posed by emergent vulnerabilities at the intersections of identity management, navigation logic, privileged browser features, and host OS integration.
To protect themselves, users should ensure Microsoft Edge is updated with the latest security patches. Meanwhile, browser isolation or sandboxing—often touted as robust protections—can be circumvented when logic flaws and trusted features are chained together. Security reviewers and teams should be proactively testing not just individual components but how browser navigation, identity systems, protocol handling, and privileged features may be abused in concert.
What to watch next:Microsoft’s upcoming security releases may close some of the flaws in this chain. Researchers will likely scrutinize how OneAuth, CORS policies, and the read:// privileged scheme are handled. If not addressed comprehensively, similar logic chains could be built against other browsers or other OSs. This exploit suggests that defending the browser isn’t enough; defending the full browser-to-OS ecosystem is now essential.
