CVE-2026-87491: Chromium V8 Out-of-Bounds Write Added to CISA KEV — Detection and Remediation Guide for Chrome, Edge, and Opera

On September 9, 2026, CISA added CVE-2026-87491 to the Known Exploited Vulnerabilities (KEV) catalog, confirming what many of us in the IR community suspected: a vulnerability in Google Chromium's V8 JavaScript engine is being actively exploited in the wild. This is an out-of-bounds (OOB) write flaw that allows a remote attacker to execute arbitrary code inside the Chromium sandbox simply by getting a victim to load a crafted HTML page.

Let me be direct about the scope of the problem. This is not a Chrome-only issue. Any browser built on Chromium ingests the V8 engine — that means Google Chrome, Microsoft Edge, Opera, Brave, Vivaldi, and a long tail of embedded Chromium frameworks (Electron-based applications, CEF wrappers, WebView components) are all potentially in scope. In most enterprise environments I assess, Chromium-based browsers account for 80–90% of the endpoint browser footprint. The attack surface here is effectively "your entire workforce, every time they open a browser."

The bar for exploitation is low: drive-by compromise via a malicious or compromised website, a weaponized ad network, or a targeted phishing link. No user interaction beyond rendering the page is required. When CISA places a browser vulnerability on the KEV, it means exploitation is confirmed, not theoretical — and with federal agencies now bound by BOD 26-04 (Prioritizing Security Updates Based on Risk) plus CISA's Forensics Triage Requirements, the remediation clock is running for everyone, public and private sector alike.

If you haven't patched yet, treat this as an incident, not a maintenance task.

Technical Analysis

Affected Component and Products

The vulnerable component is V8, Chromium's JavaScript and WebAssembly engine. V8 is where JavaScript is parsed, JIT-compiled, and executed — it is also historically the richest source of remote code execution primitives in the browser, because JIT compilation of untrusted script is an enormously complex, performance-optimized attack surface.

Affected products include, but are not limited to:

• Google Chrome (desktop and Android builds)
• Microsoft Edge (Chromium-based)
• Opera
• Other Chromium-derived browsers (Brave, Vivaldi, Arc, etc.)
• Applications embedding Chromium via Electron or CEF (these frequently lag upstream patches and deserve separate attention)

Vulnerability Mechanics (Defender's View)

An out-of-bounds write in V8 means attacker-controlled JavaScript can corrupt memory adjacent to a legitimate V8 object. The classic exploitation chain for this bug class looks like this:

1. Delivery: Victim renders a crafted HTML page — phishing link, compromised legitimate site, or malicious advertisement.
2. Trigger: JavaScript in the page exercises the vulnerable V8 code path (frequently JIT/optimizer-related), producing a controlled OOB write.
3. Primitive escalation: The OOB write is used to corrupt object metadata (array lengths, type confusion adjacency) to build an arbitrary read/write within the renderer process.
4. In-sandbox code execution: Arbitrary code runs inside the Chromium renderer sandbox.
5. Sandbox escape (frequently chained): In-the-wild campaigns against V8 bugs are typically paired with a second vulnerability to escape the sandbox and achieve full host compromise. The KEV listing tells us the exploit chain is operational — assume the worst.

Exploitation requirements: None beyond page rendering. No authentication, no clicks, no downloads. This is the highest-risk class of client-side vulnerability.

Exploitation Status

• CISA KEV: Added 2026-09-09 — confirmed active exploitation in the wild.
• Mandated action: Apply vendor mitigations; federal agencies must comply with BOD 26-04 timelines and CISA's Forensics Triage Requirements. Private-sector organizations should treat KEV-listed CVEs with the same urgency.
• Practical implication: Any endpoint running an unpatched Chromium browser since before the vendor fix should be treated as potentially compromised, especially if users browse externally hosted content (which is all of them).

Why This Matters for Detection Strategy

Browser exploits of this class are deliberately fileless in their initial stage — the payload executes in the renderer's memory. You will not reliably catch the exploit itself with signature AV. What you can catch is the post-exploitation behavior: a browser process doing things browsers never do. That is where your detection engineering effort should go.

Detection & Response

The highest-fidelity detection for Chromium renderer exploitation is anomalous child process spawning from the browser process tree. A compromised renderer — whether still sandboxed or post-escape — almost always needs to spawn something to achieve the attacker's objective: cmd.exe, powershell.exe, wscript.exe, rundll32.exe, or a dropped payload. Legitimate Chrome/Edge/Opera installations virtually never spawn command interpreters. This is a mature, low-noise detection that every SOC should have in production regardless of this CVE.

Secondary telemetry worth hunting:

• Browser processes writing executable content (.exe, .dll, .js, .hta, .lnk) to user-writable directories outside normal cache/download paths.
• Renderer crash patterns (chrome.exe / msedge.exe crash dumps in rapid succession) preceding suspicious process activity — JIT exploitation attempts frequently crash the renderer on failed attempts before succeeding.
• Persistence established shortly after browser activity (scheduled tasks, Run keys) with a browser process in the ancestry chain.

Sigma Rules

---
title: Chromium Browser Spawning Command Interpreter or Scripting Host
id: 8b4f2c71-3a9e-4d55-bc18-9f6a2e407351
status: experimental
description: Detects Chrome, Edge, or Opera spawning command interpreters or scripting hosts, a high-fidelity indicator of successful renderer exploitation such as CVE-2026-87491 post-exploitation activity.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-87491
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/10
tags:
  - attack.execution
  - attack.t1059
  - attack.t1203
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\opera.exe'
      - '\brave.exe'
      - '\vivaldi.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\wmic.exe'
      - '\bitsadmin.exe'
      - '\certutil.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare legitimate browser extension or enterprise tooling integrations
  - Developer workflows launching debug tools from browser sessions
level: high
---
title: Chromium Browser Writing Executable Content to User-Writable Directories
id: 2e7d1a94-6f38-4c91-bd25-4c8f3a90e612
status: experimental
description: Detects Chromium-based browser processes dropping executable or script content to user profile locations outside standard download behavior, consistent with payload staging after CVE-2026-87491 renderer compromise.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-87491
  - https://attack.mitre.org/techniques/T1204/
author: Security Arsenal
date: 2026/09/10
tags:
  - attack.execution
  - attack.t1203
  - attack.t1105
logsource:
  category: file_event
  product: windows
detection:
  selection_image:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\opera.exe'
  selection_path:
    TargetFilename|contains:
      - '\AppData\Local\Temp\'
      - '\AppData\Roaming\'
      - '\Users\Public\'
      - '\ProgramData\'
  selection_ext:
    TargetFilename|endswith:
      - '.exe'
      - '.dll'
      - '.hta'
      - '.lnk'
      - '.ps1'
      - '.bat'
  filter_downloads:
    TargetFilename|contains: '\Downloads\'
  condition: selection_image and selection_path and selection_ext and not filter_downloads
falsepositives:
  - Browser self-update mechanisms writing to ProgramData (verify against update service child processes)
  - Legitimate extensions packaging scripts
level: high
---
title: Persistence Created with Chromium Browser in Process Ancestry
id: 5c1a8f63-2b47-4e88-ac93-7d5f9b218304
status: experimental
description: Detects scheduled task creation or Run key modification by processes spawned from a Chromium browser process tree, indicating post-exploitation persistence following browser compromise.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-87491
  - https://attack.mitre.org/techniques/T1053/
author: Security Arsenal
date: 2026/09/10
tags:
  - attack.persistence
  - attack.t1053.005
  - attack.t1547.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_schtasks:
    Image|endswith: '\schtasks.exe'
    CommandLine|contains: '/create'
  selection_reg:
    Image|endswith: '\reg.exe'
    CommandLine|contains:
      - '\CurrentVersion\Run'
      - '\CurrentVersion\RunOnce'
  filter_browser_ancestry:
    CommandLine|contains:
      - '--type='
      - 'chrome://'
  condition: (selection_schtasks or selection_reg) and not filter_browser_ancestry
falsepositives:
  - Enterprise software deployment via scheduled tasks (correlate ParentImage ancestry for browser processes before tuning)
level: medium

Analyst note on the third rule: The real fidelity comes from joining the persistence event back to browser ancestry in your EDR — the rule above catches the raw behavior, but the triage step is checking whether schtasks.exe or reg.exe sits under chrome.exe/msedge.exe in the process tree. If it does, you have a confirmed incident. Escalate immediately and begin forensic triage per CISA's Forensics Triage Requirements.

KQL — Microsoft Sentinel / Defender

This query hunts for anomalous child processes under Chromium browsers, enriched with renderer crash correlation. It is designed to run against DeviceProcessEvents and returns the full process tree context an analyst needs for triage:

// Hunt: Chromium browsers spawning command interpreters or LOLBins
// Context: CVE-2026-87491 (Chromium V8 OOB write) - active exploitation per CISA KEV
let Browsers = dynamic(["chrome.exe", "msedge.exe", "opera.exe", "brave.exe", "vivaldi.exe"]);
let SuspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "wmic.exe", "bitsadmin.exe", "certutil.exe", "schtasks.exe", "reg.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ (Browsers)
| where FileName in~ (SuspiciousChildren)
| extend BrowserPath = InitiatingProcessFolderPath
| project TimeGenerated, DeviceName, AccountName,
          Browser = InitiatingProcessFileName,
          BrowserCmdLine = InitiatingProcessCommandLine,
          ChildProcess = FileName,
          ChildCmdLine = ProcessCommandLine,
          ChildSHA256 = SHA256,
          ReportId, DeviceId
| order by TimeGenerated desc

A companion query to find renderer crash storms — repeated tab/renderer crashes that may indicate exploitation attempts against unpatched endpoints:

// Hunt: Repeated Chromium renderer/tab crashes (possible exploit attempt pattern)
let Browsers = dynamic(["chrome.exe", "msedge.exe", "opera.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ (Browsers)
| where FileName in~ (Browsers)
| where ProcessCommandLine has "--type=renderer"
| summarize RendererStarts = count(),
            DistinctTabs = dcount(ReportId)
    by DeviceName, AccountName, bin(TimeGenerated, 1h)
| where RendererStarts > 50
| order by RendererStarts desc

Tune the 50 threshold against your environment baseline. A renderer spawning dozens of times per hour on a single host is abnormal and warrants pulling the user's browsing history and any browser crash dumps for that window.

Velociraptor VQL

For live endpoint triage on hosts where you suspect compromise — particularly systems that were unpatched during the exposure window — this artifact enumerates browser child processes and their command lines:

-- Hunt for anomalous child processes spawned by Chromium browsers
-- Context: CVE-2026-87491 post-exploitation triage
SELECT Pid,
       Ppid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime
FROM pslist()
WHERE Ppid IN (
    SELECT Pid
    FROM pslist()
    WHERE Name =~ '(?i)(chrome|msedge|opera|brave|vivaldi)\.exe'
)
  AND Name =~ '(?i)(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|wmic|bitsadmin|certutil|schtasks)\.exe'

Follow up on any hit by pulling a memory acquisition of the browser process tree and the child process before terminating anything — if the attacker is still resident in the renderer, the exploit payload and staging code live in memory only.

Remediation Script

The following PowerShell script inventories installed Chromium browser versions on a Windows endpoint, compares them against vendor release channels, and forces an update check. Run it fleet-wide via your RMM, Intune, or GPO startup script to identify lagging endpoints:

# CVE-2026-87491 - Chromium browser version audit and update enforcement
# Run as SYSTEM or Administrator fleet-wide. Exit code 1 = unpatched/stale browser found.

$stale = $false

# --- Google Chrome version check ---
$chromePaths = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe"
)
foreach ($path in $chromePaths) {
    if (Test-Path $path) {
        $ver = (Get-Item $path).VersionInfo.ProductVersion
        Write-Output "[INFO] Chrome installed version: $ver"
        # Compare against the current stable channel. Query Google's version API:
        try {
            $latest = (Invoke-RestMethod -Uri "https://versionhistory.googleapis.com/v1/chrome/platforms/win/channels/stable/versions" -TimeoutSec 15).versions[0].version
            Write-Output "[INFO] Chrome latest stable: $latest"
            if ([version]$ver -lt [version]$latest) {
                Write-Output "[ALERT] Chrome is OUTDATED. Triggering update check."
                $stale = $true
                # Force Google Update to run
                if (Test-Path "$env:ProgramFiles(x86)\Google\Update\GoogleUpdate.exe") {
                    Start-Process "$env:ProgramFiles(x86)\Google\Update\GoogleUpdate.exe" -ArgumentList "/ua /installsource scheduler" -Wait -NoNewWindow
                }
            } else {
                Write-Output "[OK] Chrome is current."
            }
        } catch {
            Write-Output "[WARN] Could not reach Chrome version API - verify manually against https://chromereleases.googleblog.com/"
        }
    }
}

# --- Microsoft Edge version check ---
$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) {
    $edgeVer = (Get-Item $edgePath).VersionInfo.ProductVersion
    Write-Output "[INFO] Edge installed version: $edgeVer"
    # Force Edge update via its updater
    $edgeUpdate = "${env:ProgramFiles(x86)}\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe"
    if (Test-Path $edgeUpdate) {
        Start-Process $edgeUpdate -ArgumentList "/ua /installsource scheduler" -Wait -NoNewWindow
        Write-Output "[INFO] Edge update check triggered."
    }
    Write-Output "[ACTION] Verify Edge build against https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnotes-security"
}

# --- Enforce enterprise update policies (prevents update-disabled drift) ---
$chromePolicy = "HKLM:\SOFTWARE\Policies\Google\Update"
if (-not (Test-Path $chromePolicy)) { New-Item -Path $chromePolicy -Force | Out-Null }
Set-ItemProperty -Path $chromePolicy -Name "UpdateDefault" -Value 1 -Type DWord
Write-Output "[OK] Google Update policy enforced (updates enabled)."

# --- Audit: list Electron apps that may embed vulnerable Chromium ---
Write-Output "[INFO] Scanning for Electron-based applications (separate patch cycle - review manually)..."
Get-ChildItem "$env:LOCALAPPDATA\Programs","$env:ProgramFiles" -Recurse -Filter "*.exe" -ErrorAction SilentlyContinue |
    Where-Object { Test-Path (Join-Path $_.DirectoryName "resources\app.asar") } |
    Select-Object -First 20 FullName |
    ForEach-Object { Write-Output "[REVIEW] Electron app: $($_.FullName)" }

if ($stale) { exit 1 } else { exit 0 }

Remediation

1. Patch every Chromium-based browser immediately. Chrome and Edge auto-update, but auto-update only completes on browser restart — and in my experience, a meaningful percentage of enterprise endpoints have browsers that have been running for weeks without a restart. Push the update, then enforce browser restarts via your endpoint management tooling. Verify the deployed build matches or exceeds the fixed version listed in the vendor security advisories: the Chrome Releases blog for Chrome and Microsoft Edge Security Update release notes for Edge. Opera publishes its Chromium rebase status in its own changelog.

2. Do not forget Electron and embedded Chromium. Slack, Teams (legacy), Discord, VS Code, and hundreds of line-of-business tools bundle their own Chromium runtime that does not update with the browser. Inventory Electron apps on your endpoints and track vendor updates for each — these routinely lag weeks behind upstream Chromium fixes and are a favorite secondary target once a V8 exploit becomes public.

3. Meet the compliance obligations. Federal civilian agencies are bound by the KEV remediation deadline attached to this CVE's catalog entry and by BOD 26-04 risk-based prioritization requirements, including CISA's Forensics Triage Requirements — meaning you must not only patch but also assess whether exploitation occurred during the exposure window. Private-sector organizations should adopt the same discipline: patch, then hunt, then document.

4. Hunt retroactively. Any endpoint that browsed the internet while unpatched is in scope for the retro-hunt queries above. Given that exploitation is confirmed, assume motivated actors had this chain before the KEV listing. Prioritize high-value users (executives, finance, admins, developers with production access) for deeper forensic review.

5. Harden for the next one. V8 bugs are a recurring tax on Chromium-based fleets. Reduce the blast radius now: enforce browser isolation for high-risk users or high-risk categories of sites, deploy attack surface reduction rules blocking Office and script child processes from browsers, and ensure your EDR is collecting full process ancestry telemetry — the detections in this article are only as good as your process tree data.

6. Ad-block at the DNS/proxy layer. Malvertising is the most common mass-delivery vector for drive-by browser exploits. Filtering ad networks at your secure web gateway or DNS resolver measurably reduces exposure to exactly this class of attack.

If you find evidence of post-exploitation activity — browser-spawned interpreters, staged payloads, persistence — treat it as a full incident: isolate the host, acquire memory before reboot, preserve browser profile artifacts, and scope laterally. A renderer RCE that escaped the sandbox means the attacker had code execution as the logged-on user, with everything that implies for credential theft and token replay.

Related Resources

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