Pwn2Own paid $175,000 for an Edge sandbox escape its author says used five logic bugs and no memory corruption

$175,000, five bugs and no memory corruption: the Edge chain in numbers

ZDI's contest rules for Pwn2Own Berlin 2026 price a Microsoft Edge sandbox escape at $175,000 and 17.5 Master of Pwn points. ZDI's Day One post, dated 14 May 2026, paid exactly that for one entry that "chained 4 logic bugs to achieve a sandbox escape on Microsoft Edge". The entrant's own account was published on 28 October 2026, 167 days later (derived), and says the chain "is made up of five bugs and two Windows features", with no memory corruption and no AI. Microsoft's Edge release notes list three Edge specific fixes for a build released the day after the contest. All of this was read between 18:40 to 19:10 GMT on Wednesday 28 October 2026.

That does not establish that the three fixes close the chain. No page read here maps a CVE id to a step of the chain, and the researcher's post prints no CVE id. It does not establish that every step is fixed: the popup allow list, the gap in the list of schemes that refuse script, a Microsoft web service's cross origin setting and a writable folder on the Windows search path are not named in any fix record read. It does not establish that the chain was used against real users: CISA's Known Exploited Vulnerabilities feed, released at 19:00 UTC on 27 October with 1,760 entries, lists none of the three ids (checked in the feed this evening).

This is the technique piece. The contest results themselves are not repeated here; for how ZDI's tables and totals behave at the other 2026 contest, see this site's recount of Pwn2Own Ireland 2026. The Edge entry was at Pwn2Own Berlin in May, not Ireland.

What was read in full: the researcher's blog post, the researcher's slides (111 pages, extracted as text), ZDI's Berlin rules, Day One post and disclosure policy, ZDI's three advisories, Microsoft's Edge security release notes, the CVE and NVD records for the three ids, and CISA's feed. The Hacker News report of today was not read: it answers a challenge page, and this briefing does not get past one. Microsoft's Security Update Guide pages need a browser to render and were not read; the CVE records Microsoft published as the numbering authority were read instead. The Chromium source pages the post links were not opened; code shown here is as the post prints it.

Interests, plainly. ZDI is the contest sponsor and the party that priced, judged and published this result; TrendAI, which runs ZDI, says on ZDI's upcoming advisories page that its customers are protected by filters before public disclosure, so it has a commercial interest in the programme. The author is a researcher at DEVCORE Research Team, which ZDI's Day One post says was leading Master of Pwn at that point, and the post's title and framing about human craft are the author's own. Microsoft makes Edge and published the fixes.

What the record states, and what it does not

Five public sources speak about this chain and none of them says the same thing about its size. ZDI says four logic bugs. The researcher says five bugs and two Windows features, and the slides number bugs 1 to 5 plus one item labelled Feature. ZDI then published three advisories. The table keeps the three counts apart and adds what each source leaves out.

Two derived figures help. The Edge entry was 175,000 of the 523,000 that ZDI says Day One awarded, 33.5 per cent (derived). And $175,000 is $43,750 per bug on ZDI's count of four, or $35,000 per numbered bug on the researcher's count of five (derived). The contest price list pays for a result, not for a bug, so these are only ways of seeing the size.

The chain, bug by bug, as the researcher describes it

The author starts from how Chromium handles a navigation, finds a component called a navigation throttle that Edge uses for Entra ID Conditional Access guidance, and builds outward. The post says the first flaw sat in the author's notes for weeks because, on its own, it only let a page that already ran on a Microsoft login origin execute script there. The turning point was asking which tab a browser started navigation applies to when no source tab is named.

Zoom

Read as a list of classes, every row is a failed check or a trusted list rather than corrupted memory: a missing source, a check on the wrong object, an allow list, a feature that signs in for you, a cross origin setting, a blocklist missing one entry, a path that was not confined, a file that was trusted at start up, and a search path. That is the sense of "logic only" in the post: Chromium's memory defences are never tested. The post's own summary of the economics is that for memory corruption the hard part is exploitation, while for logic bugs the hard part is finding them and chaining is the easy part. It adds that the finished exploit is under 100 lines, that the research took two full months, and that the bugs were found before the author began using coding agents in March. These are the author's statements and none can be checked from the outside.

Two claims in the post rest on the author's own counting. The post says that of the more than 3,000 Chrome CVEs fixed in five years, fewer than 20 relate to navigation throttles. And it calls the first bug a new UXSS attack surface and says even Chromium's own example code gets the pattern wrong. Neither was checked here, and the second is a statement about shared Chromium code, which matters for other browsers: the post says porting the chain to Google Chrome is almost there, and gives no claim that it works.

How the chain crosses the browser sandbox

A sandbox escape usually means a compromised renderer talking to the privileged browser process. Here the story is the other way round. The post describes no compromise of the attacker's own renderer. Edge's own browser process starts a navigation on the page's behalf, and that navigation runs script as another site. From there the author wants code execution, not only web security, so the script has to reach something with native powers.

The obvious target, a privileged internal page, was already guarded. The post shows Chromium's list of schemes whose pages refuse javascript URLs, with edge, chrome and devtools on it. It says Edge's Immersive Reader was forked early from Chromium and uses a custom read scheme that was not on the list. That is a blocklist doing the work of a control: it protects exactly the names someone remembered. A page on that scheme can call a native diagnostic function, which the post says writes a file whose name and content the caller chooses.

Zoom

The post says it first tried loading a DLL from a folder Edge reads at start up, and gave up because the file write is wrapped in JSON and the content must be valid UTF-8, which it could not make into a valid 64 bit PE header. It took a less obvious path: Edge's protocol allow list component reads a file that says which origins may launch which URL protocol, and the file is in a folder the write can reach. With telnet allowed from any origin, Windows looks for telnet.exe on its search path, finds no copy shipped by default, and reaches a user writable folder on that path. The post says the restart Edge needs to reload the file was only necessary for the contest.

Zoom

What was fixed, and when

The record gives a clear timeline for three ids and a blank for the rest. Microsoft's Edge security release notes list, for Stable build 148.0.3967.70 on 15 May 2026, three Edge specific security fixes: CVE-2026-45495, CVE-2026-45494 and CVE-2026-45492. The notes list CVE-2026-45495 again for iOS on 19 May and for Android on 21 May. The CVE records, published on 18 May by Microsoft as the numbering authority, say Edge is affected below 148.0.3967.70.

Zoom

Reading ZDI's titles against the post, two matches are close and one is open, and all three are inference. ZDI-26-330 names navigation handling and universal XSS, which fits Bug 1. ZDI-26-331 names feedback log file handling and a user supplied path, which fits the file write half of Bug 5. ZDI-26-329 names origin validation in a cross device managed sign in mechanism; it could be Bug 2 or Bug 3, and neither source says. Each advisory says Microsoft has issued an update and each credits the same DEVCORE researcher.

What has no CVE on the record read: the popup allow list (Bug 3, unless it is ZDI-26-329), the missing read scheme on the javascript blocklist, the CORS setting on the Microsoft web service, the OneAuth automatic sign in, the writable folder on the Windows search path and the protocol allow list's trust in a file on disk. A service side setting such as the CORS one can be changed without a client CVE, so the absence of an id is not evidence the setting is still wrong; it is only absence of evidence either way. The release notes also list 24 further Edge specific ids between 31 July and 4 September. The NVD records for those describe classes only (derived tally: 7 memory safety, 5 origin validation, 12 others) and no page read links any of them to this chain.

Three dates do not line up cleanly. The release notes put the fix on 15 May. The three advisories print 20 May as the date reported to vendor, five days later, and 4 June as coordinated public release, 21 days after the contest. ZDI's disclosure policy says it allows a vendor 120 days from notification before publishing; the Berlin rules say vulnerabilities and techniques shown by winners are disclosed to the affected vendors. Neither page explains the order of the 15 and 20 May dates. A plain reading is that the contest itself was the first notice, but that is inference and not on either page.

The severity pattern is the practical finding. Two of ZDI's three advisories, ZDI-26-329 and ZDI-26-331, say an attacker can use the flaw "in conjunction with other vulnerabilities". ZDI scores the three at 4.3, 5.0 and 7.5 (Medium, Medium and High on the CVSS bands, derived) and Microsoft at 5.4, 5.4 and 8.8. A patching rule that defers every Medium would, on ZDI's scores, have deferred two of the three. Microsoft shipped all three in one build, so an Edge that updated on its normal schedule was covered; the risk is in fleets that pin or lag, and in how teams read a score for a part when the harm is the chain.

Friendly names that do the work of a control

Several names in this chain sound like safeguards or conveniences, and each is where a check was missing.

One check in the post's own supporting material is worth testing. The post says Windows 25H2 setup requires a Microsoft account unless a local account workaround is used, and that this is what makes the automatic profile possible. The Microsoft page the post links, read here, describes setup as asking the user to sign in to, or create, a local account or a Microsoft account, and does not state a 25H2 requirement. That does not show the post is wrong; it shows the linked page does not support the sentence on its own.

Technical details

Everything below is printed in the researcher's post, ZDI's pages or Microsoft's notes, read on 28 October 2026, and sliced from the saved copies rather than retyped. None of it is a working exploit. The post's full snippets for the popup sequence and the file write call are not reproduced here beyond the identifiers a defender needs, because the record does not show every step is fixed. Each block says who printed it and what a defender does with it.

The first two blocks are what the researcher printed for Edge's guidance throttle. A defender cannot fix Edge's source, but a reviewer of Chromium based code can use the pattern: a trust check that reads the current tab's last committed URL is not a check on who asked for the navigation. The host name in the throttle's trigger address is the one indicator a browser or proxy log might hold.

location.href = `https://guidance-ca-error/?email={email}&switch_profile={url}`

content::WebContents* web_contents = navigation_handle()->GetWebContents();
const GURL last_committed_url = web_contents->GetLastCommittedURL();

if ( !IsSupportedLoginUrl(last_committed_url) )
    return content::NavigationThrottle::CANCEL_AND_IGNORE;

The next block is the Chromium fallback the post says makes a source less navigation bind to the active tab. It is printed from a path in Chromium's source; the post's comment markers are the post's.

  if (!params->source_contents && params->browser) {
    params->source_contents = params->browser
                  ->GetBrowserForMigrationOnly()
                  ->tab_strip_model()
                  ->GetActiveWebContents(); // <--- [1] Use the active tab as the navigation source
  }

The post prints the schemes whose pages Chromium refuses to run javascript URLs on. The post says Edge's read scheme was not among them. A defender with Edge policy or extension controls should know the scheme exists and that it is a privileged internal page.

edge
chrome-extension
chrome
chrome-untrusted
chrome-distiller
chrome-error
chrome-native
chrome-search
devtools
// more...

Two strings the post gives as identifiers. The first is the popup allow list entry it says Edge granted; the second is the Microsoft web service endpoint the post says returned the signed in user's email to any site. Both are public addresses and neither is shown here with the request that used it. A defender can check whether proxy or browser logs show requests to the endpoint from unrelated origins, though a client side fix would leave no server side trace.

about:blank#quickAuthPopup
https://assets.msn.com/service/community/users/me?profile=social&it=edgeid

The configuration file the chain overwrites is the one place a defender can watch directly. The path is as the post prints it for one build of the component, and the first entries of the file's structure are as printed. The post says its modified copy allowed a protocol such as telnet from any origin. In plain words, hunt for an allow entry whose origins are a wildcard, or for any change to this file that does not match what Edge's component update delivered.

AppData\Local\Microsoft\Edge\User Data\AutoLaunchProtocolsComponent\1.0.0.10\protocols.json

{
  "allow": [
    {
      "origins": [
        "https://.get.microsoft.com",
        "https://.apps.microsoft.com"
      ],
      "protocol": "ms-windows-store"
    },
    {
      "origins": [
        "https://.onedrive.com",
        "https://.onedrive.live.com",
        "https://sharepoint.com"
      ],
      "protocol": "ms-word"
    },
    // [...]
  ],
  "warn": [
    // [...]
  ],
  "block": [
    // [...]
  ]
}

The last block is the search order the post prints for telnet.exe, with its note that the final folder is writable for a low privilege account. A defender can check this on their own images.

C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0
C:\WINDOWS\System32\OpenSSH
C:\Users\lowpriv\AppData\Local\Microsoft\WindowsApps    # <--- it's writable for `lowpriv`...

May 15, 2026
Microsoft released the latest Microsoft Edge for Stable (Version 148.0.3967.70) which incorporates the latest Security Updates of the Chromium project. For more information, see the Security Update Guide
This update contains the following Microsoft Edge specific security fixes:
CVE-2026-45495
CVE-2026-45494
CVE-2026-45492

Derived by this briefing from the post and not printed by it. Treat these as hunts to adapt, not detection rules from any source.

1. File integrity: alert on any change to protocols.json under the Edge User Data AutoLaunchProtocolsComponent folder that is not delivered by an Edge component update, and on any allow entry with a wildcard origin.
2. Execution: alert on telnet.exe running from a folder under AppData\Local\Microsoft\WindowsApps, or any telnet.exe on a machine that does not ship the telnet client.
3. Browser telemetry, where it exists: a navigation to the host guidance-ca-error from a page that is not a Microsoft login origin.
4. Inventory: Edge Stable below 148.0.3967.70 on any managed device.

What to do, in the order worth doing

What could not be verified

The chain was not run, and nothing here tests whether any step still works. The researcher's counts, timings and the claim of no AI use are the author's own. The Pwnie Awards claim in the post, that the chain won Epic Achievement, was not confirmed: the Pwnies site read here shows no 2026 page. The mapping of the three CVE ids to the chain's steps is inference from titles. Microsoft's Security Update Guide pages were not read, and The Hacker News report was not read. The Edge build used at the contest is not stated. Whether ZDI counted four bugs because one numbered item is a feature, or for another reason, is not stated. The post's contest demonstration video was not watched, and the post's claim of a related Windows bug is a separate matter: the one MSRC link in the post is CVE-2026-58608, which NVD describes as a Windows Print Spooler race condition published on 14 July, and the slides list it under work done with language models, so it is not part of the logic only chain.

The question that exposes the gap

A contest paid $175,000 for a chain, a vendor shipped three fixes the next day, and the researcher's account still needs five bugs and two features. The three fixes carry scores of 4.3, 5.0 and 7.5 from ZDI. Can your browser vendor show, link by link, which fix closes which step of a chain it has already seen demonstrated, or are you relying on three ids and a Medium label?

Key facts