Out of bounds write in V8 in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to execute…

CVE-2026-87491 is an out-of-bounds write in V8, Chrome's JavaScript and WebAssembly engine, present in all Chrome builds prior to 153.0.8010.36 (Linux) / 153.0.8010.36/.37 (Windows/Mac). A remote attacker needs only to lure a victim to a crafted HTML page — no authentication, no plugins, no user interaction beyond navigation. The OOB write gives the attacker an arbitrary read/write primitive on the V8 heap, which is the standard first step toward renderer-process code execution. Crucially, the CVE description specifies execution *inside the sandbox*, meaning the V8 bug alone does not breach Chrome's multi-process sandbox boundary.

Chromium's own severity label is Medium, which is strikingly low for a vulnerability confirmed as actively exploited in the wild — the sixth Chrome zero-day of 2026. Chromium rates V8 bugs that stay sandbox-contained as Medium by policy, but that label ignores two realities: (1) attackers exploiting this today are almost certainly chaining it with a sandbox escape (as Google's own Threat Analysis Group has noted in prior zero-day campaigns), and (2) the *population* of affected endpoints is measured in billions. The Medium label is a technical scope judgment, not a risk judgment. For enterprise defenders managing fleets, this is meaningfully more urgent than Medium.

Why this verdict

• Active exploitation confirmed: Google acknowledged in-the-wild exploitation on the disclosure date. This is the strongest possible signal that the bug is weaponized and reliable enough for operational use.
• Remote, no-auth, low-interaction attack vector: Any user visiting a malicious page is vulnerable. The attack requires only that JavaScript is enabled (the default). No plugins, no file downloads, no credential prompts.
• Massive installed base: Chrome has ~3.5 billion installations globally. In a 10,000-host enterprise, effectively 100% of endpoints run Chrome or a Chromium derivative. The exposure population is near-universal.
• Role multiplier: Chrome runs on (a) standard user workstations (low-value), (b) developer and IT admin workstations (high-value — cached credentials, VPN certs, SSO tokens, admin console sessions), and (c) headless Chrome in CI/CD pipelines. On admin workstations, renderer-process compromise alone yields session tokens for identity providers (Okta, Azure AD), cloud consoles, and internal tools — the blast radius extends to identity-tier and potentially fleet-tier impact without needing a sandbox escape. On CI/CD nodes running headless Chromium, compromise can pivot to supply-chain-tier impact. Because ≥10% of Chrome instances in an enterprise sit on privileged admin/dev workstations, the HIGH floor is triggered.
• Sandbox containment is real friction but not a hard stop: The CVE scope is sandbox-contained, which genuinely limits the *direct* OS-level impact. However, renderer-process access still yields cookies, session tokens, DOM content, and autofill data for the active browsing session — this is high-value data on admin workstations without any escape needed.

Why not higher?

CRITICAL would require confirmed OS-level code execution — either a documented sandbox escape chain in this campaign or the CVE itself breaching the sandbox. The CVE description explicitly scopes impact to 'inside the sandbox,' and Google has not confirmed a companion escape CVE. The sandbox is a meaningful, well-tested boundary that limits blast radius to renderer-process data.

Why not lower?

Active in-the-wild exploitation with a remote no-auth attack vector against the world's most popular browser eliminates any argument for MEDIUM. The Chromium 'Medium' label is a scope classification, not a risk classification. An enterprise cannot treat a confirmed-exploited zero-day in its universal browser as anything less than HIGH.

1. Force Chrome auto-update to 153.0.8010.36+ immediately — Use Chrome Enterprise policy TargetVersionPrefix or your MDM (Intune, JAMF, SCCM) to enforce minimum version 153.0.8010.36. This is the definitive fix. Deploy within the noisgate mitigation SLA of 30 days — but given active exploitation, push for 72 hours across your fleet.
2. Enable Chrome Enterprise browser version reporting — Use Chrome Browser Cloud Management or your EDR's software inventory to identify all endpoints running Chrome < 153. You cannot patch what you cannot see. Prioritize admin and developer workstations.
3. Audit Chromium-based browsers (Edge, Brave, Opera, Vivaldi) — These share the V8 engine and are affected until they ship their own patches. Check Microsoft Edge update status separately — Edge often lags Chrome patches by 1–3 days.
4. Block known IOCs at proxy/DNS layer — Monitor Google TAG and CISA for campaign-specific IOCs (domains, IPs) and add them to your web proxy and DNS sinkhole. This reduces the delivery vector while patching rolls out.
5. Restrict Chrome on high-privilege accounts — If feasible, enforce that domain admins and CI/CD service accounts use a hardened browser profile or a separate browser instance with JIT disabled (--js-flags=--jitless) until patched. This kills the V8 JIT exploitation path at a performance cost.

Run on each target Windows endpoint (or via your RMM/SCCM script deployment). No admin privileges required. Example: powershell -ExecutionPolicy Bypass -File Check-CVE-2026-87491.ps1. On Linux/macOS, adapt the path to /opt/google/chrome/chrome or /Applications/Google Chrome.app/Contents/MacOS/Google Chrome.

#!/usr/bin/env pwsh
# Check-CVE-2026-87491.ps1
# Checks if installed Chrome is vulnerable to CVE-2026-87491
# (OOB write in V8, fixed in 153.0.8010.36)
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

$FixedVersion = [version]'153.0.8010.36'

# Try registry first (most reliable on Windows)
$regPaths = @(
    'HKLM:\SOFTWARE\Google\Chrome\BLBeacon',
    'HKLM:\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
    'HKCU:\SOFTWARE\Google\Chrome\BLBeacon'
)

$chromeVersion = $null
foreach ($rp in $regPaths) {
    try {
        $val = (Get-ItemProperty -Path $rp -Name 'version' -ErrorAction Stop).version
        if ($val) { $chromeVersion = $val; break }
    } catch { }
}

# Fallback: check file version
if (-not $chromeVersion) {
    $chromePaths = @(
        "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
        "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
        "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
    )
    foreach ($cp in $chromePaths) {
        if (Test-Path $cp) {
            $chromeVersion = (Get-Item $cp).VersionInfo.ProductVersion
            break
        }
    }
}

if (-not $chromeVersion) {
    Write-Output 'UNKNOWN - Chrome not detected on this host'
    exit 2
}

try {
    $installed = [version]$chromeVersion
} catch {
    Write-Output "UNKNOWN - Could not parse Chrome version: $chromeVersion"
    exit 2
}

if ($installed -lt $FixedVersion) {
    Write-Output "VULNERABLE - Chrome $chromeVersion is below fixed version $FixedVersion (CVE-2026-87491)"
    exit 1
} else {
    Write-Output "PATCHED - Chrome $chromeVersion is at or above fixed version $FixedVersion"
    exit 0
}

Sources

1. Security Online — Chrome 153 Patches Zero-Day CVE-2026-87491
2. The Hacker News — Google Releases Chrome Update to Patch Actively Exploited V8 Zero-Day
3. Security Affairs — Google fixes the sixth actively exploited Chrome zero-day of 2026
4. GBHackers — Google Chrome V8 Flaw Actively Exploited in the Wild
5. Nebula Security — Longinus: V8 Sandbox Escape CVE-2026-6307 Writeup
6. Malwarebytes — Update Chrome before you browse again
7. GitHub — V8 Sandbox Bypass Collection