DEVCORE Researcher Details Edge Sandbox Escape After Pwn2Own Win

Key points

• Orange Tsai and DEVCORE won a Pwn2Own contest with an Edge sandbox-escape chain.
• The technique chained logic flaws to reach code execution on Windows.
• Microsoft fixed the Edge bugs; no CVE identifiers were provided.
• Publication came on October 28 after roughly five months and a day after the contest.

Orange Tsai, a researcher with DEVCORE, has published details of a chain of logic flaws that allowed an escape from Microsoft Edge’s sandbox and led to code execution on Windows. The work was tied to a Pwn2Own contest held in May, where the team won a $175,000 prize. The write-up appeared on October 28, roughly five months after the contest, with the method released a day after the event.

Microsoft addressed the Edge bugs involved, but no CVE identifiers were included in the available facts. That makes patch verification and version tracking more important than usual, because administrators cannot rely on a CVE lookup alone to confirm exposure. The affected population is broad: any organization running Edge on Windows, including school districts and government endpoints, should treat browser update status as part of its exposure review.

The significance is in the boundary that was crossed. A sandbox escape undermines a key containment layer in the browser, and code execution at that level can turn a browser compromise into a broader host problem. Contest research is often high quality and can foreshadow real-world attack paths, even when the immediate risk is limited by fixes and a coordinated disclosure window.

What to watch is straightforward: confirm that Edge and Windows updates are current, look for any later CVE assignment or vendor clarification, and monitor for follow-up technical analysis that could lower the bar for exploitation. The five-month gap and the day-after-contest release also highlight how disclosure timing affects defender visibility. No active exploitation was stated in the facts, so the priority is verification and hygiene rather than incident response.

What to do now

1. Update Microsoft Edge to the latest stable release and restart browsers so the new build is active.
2. Apply current Windows cumulative updates and verify the OS build on managed endpoints.
3. Confirm Edge auto-update and restart policies are enforced, especially on student and shared devices.
4. Inventory Edge versions across the fleet and prioritize unmanaged or rarely updated systems.
5. Review browser sandbox and exploit-protection settings to ensure they have not been disabled.
6. Monitor Microsoft advisories for any CVE assignment or follow-up guidance tied to this research.
7. Limit local administrator rights to reduce the impact of code execution if a browser boundary is crossed.

Original source

The Hacker News