Microsoft Edge 150.0.4078.48 Code Execution Flaw With Public PoC — Detection, Patching, and Browser Hardening Guide

A critical code execution vulnerability affecting Microsoft Edge 150.0.4078.48 has been published with a corresponding exploit entry on Exploit-DB (EDB-ID 52632). When exploit code for a mainstream enterprise browser hits a public repository, the clock starts immediately: mass-scanning for vulnerable browser versions and drive-by delivery campaigns typically follow within days, not weeks. Every Windows endpoint in your environment running this Edge build — and in most enterprises, that's the default browser on every machine — is a potential initial access vector.

No CVE identifier has been formally assigned in the source material at time of writing, so treat this as an unnamed but publicly exploitable flaw. That distinction matters for your risk calculus: lack of a CVE does not reduce severity when working exploit code is available to any low-skill actor with a copy-paste habit. If your vulnerability management program keys exclusively off CVE feeds, this is exactly the kind of exposure that slips through — and exactly why your detection layer needs to catch the behavior, not the bulletin.

This post covers what's known about the flaw, how exploitation typically unfolds in Chromium-based browsers, and — most importantly — the detection content and remediation steps your SOC and endpoint teams should execute today.

Technical Analysis

Affected Product and Exposure Surface

• Product: Microsoft Edge (Chromium-based)
• Affected version: 150.0.4078.48
• Platforms: All Windows platforms shipping this Edge build (Windows 10/11, Windows Server where Edge is installed); Chromium-based Edge also ships for macOS and Linux
• Exposure vector: Remote, via web content — user visits a malicious or compromised page, or opens attacker-controlled HTML content

Edge is the default browser on every modern Windows build, which means your exposure surface is effectively your entire Windows fleet plus any servers where admins browse (they shouldn't, but they do).

How the Attack Works (Defender's View)

Public exploit entries for Chromium-based browsers of this class almost universally follow the same attack chain, and defenders should plan against it:

1. Delivery: Victim is lured to an attacker-controlled or compromised page (phishing link, malvertising, watering hole) serving the exploit HTML/JavaScript.
2. Renderer exploitation: Malicious JavaScript triggers the flaw in the browser's rendering engine context, achieving arbitrary read/write or code execution inside the renderer process (msedge.exe with --type=renderer).
3. Sandbox considerations: Depending on whether the flaw is exploitable from the sandboxed renderer or requires a chained sandbox escape, the attacker either lands code execution in a constrained renderer context or breaks out to full user-level execution. Public PoCs frequently target the renderer first and pair with a separate escape — assume full user-context code execution is achievable.
4. Post-exploitation: The compromised browser process spawns child processes or drops payloads. The canonical observable: msedge.exe spawning cmd.exe, powershell.exe, wscript.exe, mshta.exe, rundll32.exe, or regsvr32.exe — behavior that virtually never occurs legitimately.

Exploitation Status

• Public PoC: Yes — published on Exploit-DB (EDB-ID 52632)
• Confirmed in-the-wild exploitation: Not confirmed in the source material, but public exploit availability for a default-install browser must be treated as imminent mass exploitation
• CISA KEV: Not listed at time of writing (no CVE assigned in source)

The presence of exploit code on Exploit-DB collapses the timeline between "theoretical" and "active." Red teams and threat actors alike pull from EDB within hours of publication.

Detection & Response

The most reliable detection surface for browser exploitation is child process lineage. Edge's normal process tree is well-defined: the browser process spawns renderer, GPU, utility, and crashpad processes — never shells, script interpreters, or LOLBins. Hunt there.

Sigma Rules

---
title: Microsoft Edge Spawning Shell or Script Interpreter
id: 3f8a2c91-7b4d-4e1a-9c52-8d1e6f0a2b47
status: experimental
description: Detects msedge.exe spawning command shells, script interpreters, or LOLBins — a strong indicator of browser exploit post-exploitation activity such as that following the Edge 150.0.4078.48 code execution flaw (EDB-ID 52632).
references:
  - https://www.exploit-db.com/exploits/52632
  - https://attack.mitre.org/techniques/T1203/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/04
tags:
  - attack.execution
  - attack.t1203
  - 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'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\wmic.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare enterprise browser extensions or internal web apps launching local helpers — investigate before tuning
level: high
---
title: Edge Renderer Process Executing Unexpected Binary From User-Writable Path
id: 9c1d4e72-3a58-4f6b-b2d1-5e7c9a0f3d86
status: experimental
description: Detects Microsoft Edge processes executing binaries or scripts from user-writable directories (AppData\Local\Temp, Downloads, Public), consistent with payload staging after successful browser exploitation.
references:
  - https://www.exploit-db.com/exploits/52632
  - https://attack.mitre.org/techniques/T1204.002/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/08/04
tags:
  - attack.execution
  - attack.t1204.002
  - attack.command_and_control
  - attack.t1105
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\msedge.exe'
  selection_path:
    Image|contains:
      - '\AppData\Local\Temp\'
      - '\Downloads\'
      - '\Users\Public\'
      - '\AppData\Roaming\'
  filter_edge_updates:
    Image|contains:
      - '\Microsoft\EdgeUpdate\'
      - '\Microsoft\Edge\Application\'
  condition: selection_parent and selection_path and not filter_edge_updates
falsepositives:
  - Browser-delivered legitimate installers launched by users — validate via download history and file reputation
level: high

KQL — Microsoft Sentinel / Defender

This query hunts the post-exploitation pattern across your fleet and enriches with the initiating process details so analysts can pivot quickly. Run it over at least the last 7 days initially, then schedule it:

// Hunt: msedge.exe spawning shells, script interpreters, or LOLBins
// Context: Edge 150.0.4078.48 public exploit (EDB-ID 52632)
let SuspiciousChildren = dynamic([
    "cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe",
    "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe",
    "bitsadmin.exe", "wmic.exe", "rundll32.exe"
]);
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "msedge.exe"
| where FileName in~ (SuspiciousChildren)
| project TimeGenerated, DeviceName, AccountName,
          InitiatingProcessCommandLine, InitiatingProcessId,
          FileName, ProcessCommandLine, ProcessId,
          SHA256, FolderPath
| extend RendererFlag = iff(InitiatingProcessCommandLine has "--type=renderer", "RendererChild", "BrowserChild")
| order by TimeGenerated desc

A complementary version check to size your exposure directly from Defender TVM data:

// Identify endpoints still running the affected Edge build
DeviceTvmSoftwareInventory
| where SoftwareName has "microsoft_edge"
| where SoftwareVersion startswith "150.0.4078.48"
| summarize Endpoints = dcount(DeviceId), Devices = make_set(DeviceName, 50) by SoftwareVersion
| project SoftwareVersion, Endpoints, Devices

Velociraptor VQL

For DFIR teams running Velociraptor, this artifact surfaces live Edge child-process anomalies and can be deployed as a fleet-wide hunt:

-- Hunt: Suspicious child processes of msedge.exe (Edge exploit post-exploitation)
-- Reference: EDB-ID 52632 / Edge 150.0.4078.48 code execution flaw
LET edge_pids = SELECT Pid
FROM pslist()
WHERE Name =~ '(?i)msedge'

SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Ppid IN (SELECT Pid FROM edge_pids)
  AND Name =~ '(?i)(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|certutil|bitsadmin|wmic)'

For host triage on a suspected compromised endpoint, also pull the Edge version and recent download artifacts:

-- Triage: Edge version and recently created executables in user-writable paths
SELECT FullPath, Size, Mtime, Btime
FROM glob(glob='C:/Users/*/AppData/Local/Microsoft/Edge/Application/*/msedge.exe')

SELECT FullPath, Size, Mtime, Btime
FROM glob(glob='C:/Users/*/{Downloads,AppData/Local/Temp}/**.exe')
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC

Remediation & Verification Script

Run via Intune, SCCM/MECM, GPO startup script, or your RMM to audit and force Edge updates across the fleet:

# Edge 150.0.4078.48 (EDB-ID 52632) - Audit and Remediation
# Run as SYSTEM / elevated. Safe to run repeatedly.

$affectedVersion = "150.0.4078.48"
$edgeExe = "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe"
if (-not (Test-Path $edgeExe)) { $edgeExe = "$env:ProgramFiles\Microsoft\Edge\Application\msedge.exe" }

# --- 1. Audit installed version ---
if (Test-Path $edgeExe) {
    $installed = (Get-Item $edgeExe).VersionInfo.ProductVersion
    Write-Output "[AUDIT] Installed Edge version: $installed"
    if ($installed -eq $affectedVersion) {
        Write-Output "[VULNERABLE] Endpoint is running the affected build $affectedVersion"
    } else {
        Write-Output "[INFO] Build differs from known-affected version - verify against current stable channel"
    }
} else {
    Write-Output "[INFO] Edge not found in standard paths"
}

# --- 2. Force Edge update check ---
$edgeUpdate = "${env:ProgramFiles(x86)}\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe"
if (Test-Path $edgeUpdate) {
    Write-Output "[ACTION] Triggering Microsoft Edge Update..."
    Start-Process -FilePath $edgeUpdate -ArgumentList "/ua /installsource scheduler" -Wait -NoNewWindow
}

# --- 3. Enforce update policy via registry (prevents users/admins disabling updates) ---
$policyPath = "HKLM:\SOFTWARE\Policies\Microsoft\EdgeUpdate"
New-Item -Path $policyPath -Force | Out-Null
Set-ItemProperty -Path $policyPath -Name "UpdateDefault" -Value 1
Set-ItemProperty -Path $policyPath -Name "AutoUpdateCheckPeriodMinutes" -Value 360
Write-Output "[HARDEN] Edge automatic updates enforced via policy"

# --- 4. Re-audit post-update ---
if (Test-Path $edgeExe) {
    $post = (Get-Item $edgeExe).VersionInfo.ProductVersion
    Write-Output "[VERIFY] Post-update Edge version: $post"
    if ($post -eq $affectedVersion) {
        Write-Output "[FAIL] Still on affected build - escalate for manual remediation"
        exit 1
    }
}
Write-Output "[DONE] Edge audit/remediation complete"

Remediation

1. Update Edge fleet-wide immediately. Push the latest Edge Stable channel build — anything later than 150.0.4078.48 that includes the fix. Verify the resolved build number against Microsoft's current Edge release notes (learn.microsoft.com/deployedge/microsoft-edge-relnotes-security) and the Microsoft Security Update Guide before declaring closure.
2. Enforce automatic updates. Edge updates out-of-band from Windows Update via Microsoft Edge Update. Ensure the EdgeUpdate scheduled tasks and services haven't been disabled by "optimization" scripts, gold images, or hardening baselines — this is a depressingly common finding. The registry policy in the script above enforces this.
3. Inventory your exposure. Use the TVM KQL query above (or your EDR/software inventory) to count endpoints on the affected build. Don't forget servers, VDI images, and lab machines.
4. Block and hunt the PoC. Add EDB-ID 52632 to your threat intel watchlist. If your proxy/SWG can detonate or inspect HTML/JS payloads, alert on known PoC signatures. Hunt the child-process behavior retroactively — publication of the PoC means attempted use may predate your patch.
5. Harden the browser attack surface while you patch:
   • Enable Microsoft Defender SmartScreen and potentially unwanted app (PUA) protection fleet-wide via Edge policy.
   • Enable Attack Surface Reduction (ASR) rules, particularly "Block Office applications from creating child processes" patterns applied conceptually to browsers — at minimum, ensure your EDR is in block mode, not audit.
   • Restrict browsing on servers entirely (no interactive browsing from server OS) and enforce via AppLocker/WDAC where feasible.
   • Consider Edge Enhanced Security Mode (site isolation + JIT mitigations) for high-risk user populations — it trades compatibility for meaningful exploit resistance against exactly this class of renderer bug.
6. Watch for a CVE and KEV listing. No CVE is assigned in the source material yet. When one lands, expect CISA KEV inclusion with a federal remediation deadline (typically 21 days) — private sector should treat that as the outer bound, not the target.
7. Brief the SOC. Pre-stage the detections above, set up an escalation playbook for browser child-process alerts, and make sure analysts know that msedge.exe → cmd.exe is never a "wait and see" alert.

Category & Context

This incident belongs squarely in your vulnerability management program, but with IR-grade urgency. The combination of a default-install enterprise browser, remote unauthenticated attack surface, and public exploit code is the trifecta that turns a routine patch cycle into a weekend. Treat it accordingly.

Related Resources

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