Microsoft Edge Sandbox Escape via Logic Bugs: How Orange Tsai's $175K Pwn2Own Chain Changes Browser Defense

On October 28, DEVCORE researcher Orange Tsai published the full technical details of the exploit chain that earned $175,000 at Pwn2Own Berlin in May — and the write-up should be mandatory reading for every browser security and detection engineering team. The headline finding: a chain of pure logic flaws, with zero memory corruption, took a victim from rendering a malicious web page in Microsoft Edge to arbitrary code execution on the underlying Windows host, fully outside the Edge sandbox.

Microsoft patched the Edge bugs the day after the contest, so if your fleet is current on Edge updates, you are protected against this specific chain. But the defensive lesson here is much bigger than one patch cycle. For two decades, browser exploitation has been synonymous with memory corruption — use-after-free, type confusion, JIT bugs. Tsai's work demonstrates that modern browsers have accumulated such a massive attack surface of privileged features, custom protocol handlers, internal pages, and brokered IPC that a skilled attacker can walk straight through the front door using logic bugs alone. That has direct consequences for how you patch, how you detect, and how you think about browser isolation.

Technical Analysis

What Happened

Per the DEVCORE disclosure (via The Hacker News), the chain is composed entirely of logic vulnerabilities — flaws in how Edge handles state, privileges, and trust boundaries — rather than corruption of memory. The exploit chain, demonstrated live at Pwn2Own Berlin 2025, achieves:

Initial compromise via web content: A malicious page rendered in the Edge renderer process is the only user interaction required. This is a classic drive-by scenario — the highest-severity browser attack class.
Sandbox escape without memory corruption: Rather than exploiting a JIT or DOM bug for native code execution inside the renderer and then attacking the sandbox broker, the chain abuses logic errors in Edge's privileged surfaces to escalate out of the sandboxed renderer.
Code execution on the Windows host: The end state is attacker-controlled code running outside the sandbox at the user's privilege level — full access to the user's files, credentials in memory, and a pivot point for lateral movement.

Microsoft triaged and shipped fixes within roughly 24 hours of the contest demonstration, and the full methodology was withheld for five months to allow patch adoption before public disclosure.

Why Logic-Only Chains Matter to Defenders

This disclosure breaks several assumptions baked into defensive strategy:

Exploit mitigations don't help. Control-flow integrity, CET, ASLR, DEP, ACG, and sandbox hardening are all designed to raise the cost of memory corruption exploitation. A logic-only chain bypasses the entire mitigation stack because it never corrupts memory — it convinces the browser to do attacker-desired work using legitimate code paths.
Patch velocity is the only reliable control. You cannot signature or mitigate your way out of logic bugs in the browser's privileged attack surface. The day-after-patch turnaround Microsoft delivered at Pwn2Own only helps you if your update rings actually deploy Edge updates within days, not months.
Detection must be behavioral, at the sandbox boundary. Once the chain lands, its observable behavior is a sandboxed browser process doing things a browser should never do: spawning child processes, writing executables to user-writable locations, and invoking OS protocol handlers outside normal navigation flows.

Affected Products and Exposure

Product: Microsoft Edge (Chromium-based) on Windows, versions prior to the May 2025 post-Pwn2Own security updates. Any Edge build older than May 2025 should be treated as exposed to this chain.
Attack prerequisites: Victim visits (or is redirected to) attacker-controlled web content. No additional interaction required. Phishing, malvertising, watering holes, and compromised legitimate sites are all viable delivery vectors.
Platform: Windows hosts running Edge. Enterprise environments with unmanaged browser versions, broken update channels, or users on downlevel Edge builds are the primary risk population.

Exploitation Status

Public technical details: Yes — full methodology published by DEVCORE on October 28, 2026 (five months post-patch).
Patch availability: Yes — Microsoft shipped fixes the day after Pwn2Own Berlin in May 2025.
Known in-the-wild exploitation: None confirmed at time of the disclosure. However, with the full chain now public, weaponization by exploit-kit operators and red teams is a matter of time for any unpatched hosts that remain. Treat any Edge installation not updated since May 2025 as critically exposed.

Detection & Response

Because this is a logic-only chain, there are no crash artifacts, no corrupted heap signatures, and no shellcode to catch. The detection opportunity concentrates on one invariant: the Edge renderer and GPU/utility processes should never spawn interactive child processes, and msedge.exe should never launch command interpreters, script engines, or unsigned binaries. That behavior is the post-exploitation fingerprint of virtually every browser sandbox escape, logic-based or otherwise.

Sigma Rules

YAML

---
title: Microsoft Edge Spawned Command or Script Interpreter - Possible Sandbox Escape
id: 3f9c2e71-8b4a-4d6f-9e21-7a5b8c3d2e1f
status: experimental
description: Detects msedge.exe spawning command interpreters, script engines, or LOLBins. A browser process launching cmd, PowerShell, wscript, rundll32, or mshta is a hallmark of successful browser exploitation with sandbox escape, as demonstrated in the DEVCORE Pwn2Own Berlin Edge logic-flaw chain.
references:
  - https://thehackernews.com/2026/10/researcher-reveals-how-logic-bugs-alone.html
  - https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/10/29
tags:
  - attack.initial_access
  - attack.t1203
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\msedge.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\wmic.exe'
      - '\msbuild.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare enterprise browser extensions or internal tooling that shell out from Edge
  - SSO agents or legacy IE-mode helpers (validate per environment before tuning)
level: high
---
title: Edge Renderer or Utility Process Spawning Any Child Process
id: 8d4e6a12-5c7b-4f3e-b912-6e9d0a4c7f83
status: experimental
description: Detects any process spawned by an Edge renderer, GPU, or utility process (identified by the --type= flag on the parent command line). Sandboxed renderer processes must never create child processes; this is a near-zero-false-positive indicator of renderer compromise and sandbox escape.
references:
  - https://thehackernews.com/2026/10/researcher-reveals-how-logic-bugs-alone.html
  - https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/10/29
tags:
  - attack.initial_access
  - attack.t1203
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith: '\msedge.exe'
    ParentCommandLine|contains:
      - '--type=renderer'
      - '--type=gpu-process'
      - '--type=utility'
  condition: selection
falsepositives:
  - None expected; renderer child processes are abnormal by design
level: critical
---
title: Executable Dropped to User-Writable Location by Microsoft Edge
id: b27f4a95-3e8d-4c1a-a654-9f2e7d6b1c08
status: experimental
description: Detects msedge.exe writing executable or script files to startup folders, temp directories, or AppData locations outside its download cache. Post-exploitation stage of browser sandbox escapes commonly drops a payload to a user-writable path for execution or persistence.
references:
  - https://thehackernews.com/2026/10/researcher-reveals-how-logic-bugs-alone.html
  - https://attack.mitre.org/techniques/T1203/
  - https://attack.mitre.org/techniques/T1547/
author: Security Arsenal
date: 2026/10/29
tags:
  - attack.initial_access
  - attack.t1203
  - attack.persistence
  - attack.t1547.001
logsource:
  category: file_event
  product: windows
detection:
  selection_image:
    Image|endswith: '\msedge.exe'
  selection_path:
    TargetFilename|contains:
      - '\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\'
      - '\AppData\Local\Temp\'
      - '\AppData\Roaming\'
      - '\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\'
  selection_ext:
    TargetFilename|endswith:
      - '.exe'
      - '.dll'
      - '.bat'
      - '.cmd'
      - '.ps1'
      - '.vbs'
      - '.js'
      - '.hta'
      - '.lnk'
  filter_downloads:
    TargetFilename|contains: '\Downloads\'
  condition: selection_image and selection_path and selection_ext and not filter_downloads
falsepositives:
  - Browser extensions writing helper scripts (rare; verify file reputation and signer)
level: high

KQL Hunt — Microsoft Sentinel / Defender for Endpoint

This query hunts for the core sandbox-escape fingerprint — Edge spawning suspicious children — and enriches it with the process tree so analysts can pivot quickly. Run it across at least 30 days given that the exploit details are now public and retro-hunts matter.

KQL — Microsoft Sentinel / Defender

// Hunt: Microsoft Edge spawning suspicious child processes (sandbox escape pattern)
// Relevant to DEVCORE Pwn2Own Berlin Edge logic-flaw chain disclosure (Oct 2026)
let suspiciousChildren = dynamic([
    "cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe",
    "mshta.exe", "rundll32.exe", "regsvr32.exe", "wmic.exe", "certutil.exe",
    "bitsadmin.exe", "msbuild.exe", "regsvcs.exe", "installutil.exe"
]);
DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where InitiatingProcessFileName =~ "msedge.exe"
| where FileName in~ (suspiciousChildren)
| extend RendererParent = InitiatingProcessCommandLine has_any ("--type=renderer", "--type=utility", "--type=gpu-process")
| project TimeGenerated, DeviceName, AccountName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          RendererParent, SHA256, FolderPath, ReportId
| sort by TimeGenerated desc

A companion hunt for the dropper stage — Edge writing executables outside the Downloads cache:

KQL — Microsoft Sentinel / Defender

// Hunt: Edge writing executables/scripts to persistence or staging locations
DeviceFileEvents
| where TimeGenerated > ago(30d)
| where InitiatingProcessFileName =~ "msedge.exe"
| where FolderPath has_any ("Startup", "\\AppData\\Local\\Temp\\", "\\AppData\\Roaming\\")
| where FolderPath !has "\\Downloads\\"
| where FileName endswith_any (".exe", ".dll", ".ps1", ".bat", ".cmd", ".vbs", ".js", ".hta", ".lnk")
| project TimeGenerated, DeviceName, FileName, FolderPath, SHA256,
          InitiatingProcessCommandLine, RequestingAccountName
| sort by TimeGenerated desc

Velociraptor VQL Hunt

Use this as a live-fleet sweep to find currently-running evidence of browser compromise — any process whose parent is an Edge renderer or whose parent is Edge and which matches a LOLBin set:

VQL — Velociraptor

-- Hunt: Suspicious child processes of Microsoft Edge (sandbox escape indicator)
-- Scope: live process list across the fleet via hunt
LET procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
  FROM pslist()

LET edge_parents = SELECT Pid, Name, CommandLine
  FROM procs
  WHERE Name =~ 'msedge'

SELECT child.Pid AS ChildPid,
       child.Name AS ChildName,
       child.CommandLine AS ChildCommandLine,
       child.Username AS ChildUser,
       child.CreateTime AS ChildCreateTime,
       parent.Pid AS EdgePid,
       parent.CommandLine AS EdgeCommandLine
FROM procs AS child
JOIN edge_parents AS parent
ON child.Ppid = parent.Pid
WHERE child.Name =~ '(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|wmic|certutil|bitsadmin)'
   OR parent.CommandLine =~ '--type=(renderer|utility|gpu-process)'

Remediation / Verification Script

This PowerShell script validates Edge patch posture across a host: it pulls the installed Edge version, flags builds older than the May 2025 post-Pwn2Own fix window as critically exposed, verifies the Edge Update service is healthy, and confirms site isolation is not disabled via policy.

PowerShell

# Edge Pwn2Own Logic-Chain Exposure Check
# Run elevated. Flags Edge builds predating the May 2025 Pwn2Own Berlin fixes.

$minSafeBuild = [version]"136.0.0.0"   # Edge stable channel as of May 2025 post-contest fixes; update per current stable

# 1. Detect installed Edge version
$edgePath = "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe"
if (-not (Test-Path $edgePath)) { $edgePath = "$env:ProgramFiles\Microsoft\Edge\Application\msedge.exe" }

if (Test-Path $edgePath) {
    $edgeVersion = (Get-Item $edgePath).VersionInfo.ProductVersion
    Write-Host "[+] Installed Edge version: $edgeVersion"
    if ([version]$edgeVersion -lt $minSafeBuild) {
        Write-Warning "[!] Edge build is OLDER than May 2025 - EXPOSED to the DEVCORE Pwn2Own logic-flaw chain. Update immediately."
    } else {
        Write-Host "[OK] Edge version is at or above the post-Pwn2Own fix baseline."
    }
} else {
    Write-Warning "[!] Microsoft Edge not found in standard install paths."
}

# 2. Verify Edge Update services are present and not disabled
Get-Service -Name "edgeupdate","edgeupdatem" -ErrorAction SilentlyContinue | ForEach-Object {
    $status = if ($_.StartType -eq 'Disabled') { "DISABLED - updates broken, remediate" } else { "$($_.StartType) / $($_.Status)" }
    Write-Host "[+] Service $($_.Name): $status"
}

# 3. Check that update policies have not been blocked via registry
$updatePolicy = "HKLM:\SOFTWARE\Policies\Microsoft\EdgeUpdate"
if (Test-Path $updatePolicy) {
    $blockUpdate = Get-ItemProperty -Path $updatePolicy -Name "UpdateDefault" -ErrorAction SilentlyContinue
    if ($blockUpdate -and $blockUpdate.UpdateDefault -eq 0) {
        Write-Warning "[!] EdgeUpdate policy UpdateDefault=0 (updates disabled). Remove this policy."
    } else {
        Write-Host "[OK] EdgeUpdate policy does not block updates."
    }
}

# 4. Verify site isolation is not disabled via Edge policy (critical sandbox control)
$edgePolicy = "HKLM:\SOFTWARE\Policies\Microsoft\Edge"
if (Test-Path $edgePolicy) {
    $siteIsolation = Get-ItemProperty -Path $edgePolicy -Name "SitePerProcess" -ErrorAction SilentlyContinue
    if ($siteIsolation -and $siteIsolation.SitePerProcess -eq 0) {
        Write-Warning "[!] SitePerProcess=0 - site isolation DISABLED. This materially weakens renderer sandboxing."
    }
}

# 5. Force an Edge update check (triggers EdgeUpdate task)
Write-Host "[*] Triggering Edge Update task..."
Start-ScheduledTask -TaskName "MicrosoftEdgeUpdateTaskMachineCore" -ErrorAction SilentlyContinue
Write-Host "[*] Done. Re-run this script post-update to confirm version baseline."

Remediation

1. Patch Edge fleet-wide — today, not this quarter. Microsoft shipped fixes the day after Pwn2Own Berlin in May 2025. Any Edge installation with a build date older than May 2025 is exposed to a now fully-public exploit chain. Audit your fleet for stragglers: VDI images, offline systems, kiosks, lab machines, and servers where admins browse (they shouldn't — enforce a no-browsing policy on servers).

2. Fix broken update channels. The most common root cause of stale Edge installs is disabled EdgeUpdate services or the UpdateDefault=0 policy left over from legacy management decisions. Use the verification script above across your fleet via your RMM or Intune remediation.

3. Adopt a browser patch SLA measured in days, not months. Browser zero-days and n-day chains with public methodology are weaponized fast. Treat Chromium/Edge security updates with the same urgency as CISA KEV entries: 72-hour deployment target for standard users, 24 hours for high-risk populations (executives, finance, admins).

4. Deploy the detections above. The renderer-child-process Sigma rule is near-zero false positive by design — a sandboxed renderer spawning a child process is anomalous in essentially every environment. Route these alerts as high-severity in your queue; browser sandbox escapes are rare, high-fidelity events that justify immediate triage.

5. Layer compensating controls for the logic-bug reality:

Application control (WDAC/AppLocker): Constrain what code can execute even if a browser is fully compromised — block unsigned binaries and script execution from user-writable paths.
Attack Surface Reduction rules: Enable ASR rules blocking Office and script abuse, and critically monitor for child-process creation from browsers.
Remote browser isolation for high-risk user populations and untrusted browsing categories.
Credential Guard and LSASS protection to limit the blast radius of post-exploitation credential theft once an attacker lands outside the sandbox.

6. Verify site isolation and sandbox policies. Audit Edge/Chrome enterprise policies (SitePerProcess, sandbox-related flags) — any policy that relaxes site isolation or disables renderer sandboxing for "compatibility" directly enlarges the attack surface this research exploited.

7. Retro-hunt. With the full methodology now public since October 28, run the KQL hunts above over the longest retention window you have. Any historical Edge-spawned interpreter activity deserves forensic review even on patched hosts — patches fix the bug, they don't evict an intruder.

Key Takeaway

Orange Tsai's chain is a proof point that the browser's biggest risk is no longer just memory safety — it is the sprawling, under-audited logic layer of privileged browser features. Defenders cannot mitigate logic flaws the way we mitigated memory corruption. Our controls are update velocity, strict application control, and behavioral detection anchored on the sandbox boundary. Get those three right, and a fully-public $175,000 exploit chain becomes a manageable event instead of a breach.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub