Microsoft Edge vulnerability escaped sandbox without memory bugs
A Microsoft Edge vulnerability chain allowed a malicious web page to escape the browser sandbox and run code on a Windows computer without exploiting memory corruption. A sandbox is the isolation boundary intended to prevent website code from reaching the rest of a device. Microsoft corrected the affected Edge components in May, and browsers updated to Stable version 148.0.3967.70 are not vulnerable to this chain.
A DEVCORE researcher demonstrated the technique at Pwn2Own Berlin in May, earning $175,000, and published a detailed account on October 28, five months later. Microsoft released the fixes on May 15, the day after the contest, and DEVCORE said the response took less than 24 hours from disclosure. This was a competition demonstration rather than a known real-world attack. Public CVE records report no exploitation, and there is no evidence that the chain was used against users.
The unusual feature of the research is that it did not depend on memory corruption, which occurs when software mishandles data in memory and can sometimes be made to execute unwanted instructions. Instead, the exploit combined mistakes in the rules governing legitimate Edge and Windows features. The researcher said the finished exploit contained fewer than 100 lines of code, although identifying and assembling the necessary weaknesses took about two months of manual work without artificial intelligence assistance.
The first stage produced universal cross-site scripting (UXSS), a browser-level weakness that lets JavaScript run in the context of other websites. It also bypassed Content Security Policy (CSP), a website rule that limits which scripts and other resources a page may load. Because the navigation originated from an Edge process rather than an ordinary website, the technique could affect sites such as google.com that a conventional website scripting flaw could not reach. DEVCORE characterized this behavior as a broader attack surface rather than an isolated website bug.
The chain began with an Edge component used for business sign-ins, called the conditional access navigation throttle. Triggering it caused the browser process to begin a navigation that was no longer associated with the page that requested it. Edge then connected that navigation to whichever browser tab was active. This mismatch gave the attacker the UXSS capability.
Four additional weaknesses made the process work without requiring a click. Edge attempted to verify that the request originated from a trusted Microsoft site, but the researcher bypassed that check by initiating it through a second window. A popup blocker should have prevented the extra window, but Edge contained a hardcoded list of permitted addresses, one of which allowed the popup to open. The attack also depended on the victim being signed in, a condition Edge's automatic sign-in feature supplied when the user visited a Microsoft site. Finally, assets.msn.com exposed the victim's email address to any website because of a misconfigured cross-origin setting, which controls whether one website may provide data to another.
Running JavaScript in websites did not by itself provide control of Windows, so the chain next targeted Immersive Reader, Edge's reading mode. This feature operated under a custom read:// address, but Microsoft had omitted that address from the set of pages prohibited from running scripts. The researcher used this opening to call an internal Edge function designed to compress diagnostic logs. By misusing that function, the exploit could create a file with attacker-selected contents and a chosen name anywhere on the disk.
The arbitrary file write became code execution through two further steps. First, the chain replaced a configuration file governing which websites could open protocol handlers, which are programs associated with special link types. It then restarted Edge so the browser would load the altered configuration. The restart simplified the contest demonstration, according to the researcher, but would not be necessary in a real attack.
The exploit subsequently opened a telnet:// link. Windows does not include a Telnet program by default, so it searched the system path for a suitable program. The chain took advantage of that search by placing an attacker-controlled copy in a folder writable by the low-privileged user. Windows then ran that copy, completing the transition from a malicious web page to code executing outside the browser sandbox.
Edge Stable 148.0.3967.70 included three Edge-specific security fixes tracked as CVE-2026-45492, CVE-2026-45494 and CVE-2026-45495. Microsoft classifies the first as a security feature bypass and the second as a spoofing issue, with both affecting releases before 148.0.3967.70. Each of those two records carries a severity score of 5.4 out of 10. That medium rating describes each weakness separately and does not represent the effect of combining the flaws into a code-execution chain.
For website owners, the findings show that browser defects can defeat protections configured correctly by an individual site, including CSP, because the failure occurred at the browser level. The direct protection is to keep Edge updated. Automatic updates have already delivered the May release to browsers that receive them normally, and Microsoft requires no separate action once the update is installed. For organisations reviewing their wider security practices after flaws such as these, AEU-I offers security-first IT, infrastructure and consulting.
The research also illustrates why individually moderate logic errors can become substantially more serious when combined across browser and operating-system features. Finding the separate behaviors was the difficult part of the work, while linking them became comparatively straightforward once all the pieces were known. The research later received the 2026 Pwnie Award for Epic Achievement, but the practical conclusion for users remains simple: install current Edge updates and restart the browser when prompted.