CVE-2026-11120 · Chrome Enterprise Reporting Insufficient Input Validation Sandbox…

01 · The Real Story

A fire exit that only matters if the building is already on fire — and nobody has matches

CVE-2026-11120 is an insufficient input validation flaw in Chrome's Enterprise Reporting IPC surface. A remote attacker who has *already compromised the renderer process* — itself a feat requiring a separate, unrelated vulnerability — can send crafted IPC messages through the Enterprise Reporting channel to escape the Chrome sandbox and achieve code execution on the host OS. All Chrome desktop versions prior to 149.0.7827.53 (Windows/Linux) and 149.0.7827.54 (macOS) are affected. The fix shipped in the massive Chrome 149 release on June 2, 2026, which patched a record 429 vulnerabilities.

The NVD CVSS score of 9.6 CRITICAL is dramatically misaligned with reality. The CVSS vector (AV:N/AC:L/PR:N/UI:R/S:C) treats the renderer compromise prerequisite as if it doesn't exist — rating attack complexity as *Low* when the attacker actually needs a separate, independent exploit chain just to reach the starting line. Chromium's own security team rates this Medium, and they're right. A sandbox escape without a renderer exploit is a locked second door with no first door to get through. No public PoC exists, EPSS sits at the 18th percentile (0.27%), it's not KEV-listed, and there is zero evidence of in-the-wild exploitation. For a 10,000-host fleet, this is a normal patching-cycle item, not a fire drill.

"Sandbox escape needs a renderer 0-day first — expensive chain, no PoC, Chromium calls it Medium"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Renderer process compromise

The attacker must first exploit a *separate* vulnerability — typically a V8 type confusion, use-after-free in Blink, or media codec bug — to gain arbitrary code execution inside Chrome's sandboxed renderer process. In modern Chrome (2025+), this alone may require chaining a V8 heap corruption with a V8 sandbox (Ubercage) bypass, making it effectively a two-bug prerequisite before CVE-2026-11120 even becomes relevant.

Conditions required:

Separate renderer exploit (0-day or unpatched n-day)
Victim running Chrome < 149.0.7827.53

Where this breaks in practice:

Chrome V8 sandbox (Ubercage) dramatically raises the bar since 2024
Full renderer exploits command $500K–$3.5M on the broker market (Crowdfense, Zerodium)
Chrome's heap partitioning, MiraclePtr, CFI, and stack protectors make renderer bugs rare and expensive

Detection/coverage: EDR memory-corruption heuristics; Chrome CrashPad telemetry for anomalous renderer crashes

STEP 02

Victim visits attacker-controlled page

The attacker must lure the victim to a page hosting the exploit payload. This can be via spear-phishing link, malvertising injection, or watering-hole compromise. The CVSS vector correctly marks UI:R — user interaction is required. Enterprise environments with URL filtering, DNS sinkholes, and email gateways add friction here.

Conditions required:

Social engineering, malvertising, or watering hole delivery
User clicks or navigates to attacker-controlled content

Where this breaks in practice:

Secure Email Gateway blocks most phishing links
Chrome Safe Browsing flags known malicious domains
DNS-layer filtering (Umbrella, Zscaler) blocks C2 and exploit-kit domains
Enterprise proxy/SWG inspection

Detection/coverage: Web proxy logs; Safe Browsing telemetry in Chrome Enterprise; email gateway quarantine logs

STEP 03

Crafted IPC to Enterprise Reporting surface

From the compromised renderer, the attacker crafts malicious Mojo IPC messages targeting Chrome's Enterprise Reporting component. The insufficient input validation in this component fails to sanitize the attacker-controlled data. This is the actual CVE-2026-11120 bug — a logic flaw in how the browser process handles data from the renderer via the reporting interface.

Conditions required:

Renderer already compromised (Step 1 complete)
Enterprise Reporting IPC endpoint reachable from renderer

Where this breaks in practice:

Chrome's Mojo IPC has type-checked interfaces that limit what a renderer can send
Not all browser-process IPC surfaces are reachable from every renderer — the Enterprise Reporting endpoint may require specific process state
Chrome's MojoJS bindings are disabled in production builds, limiting IPC surface enumeration

Detection/coverage: No practical detection — this is intra-process IPC within the browser; no network signature exists

STEP 04

Sandbox escape and host-level code execution

The validation bypass allows the attacker to escape the Chrome sandbox and execute code on the host OS at the privilege level of the Chrome browser process (typically the logged-in user on Windows, or the chrome process user on Linux). The attacker now has a foothold on the endpoint — but still at user privilege level, not SYSTEM/root. Further local privilege escalation would be needed for full host control.

Conditions required:

Steps 1–3 complete
OS-level mitigations (ASLR, DEP, CIG, ACG) do not block the specific escape vector

Where this breaks in practice:

Windows Arbitrary Code Guard (ACG) and Code Integrity Guard (CIG) in Chrome block many sandbox escape patterns
Linux seccomp-bpf and namespace isolation add defense-in-depth
EDR agents detect anomalous child process spawning from browser processes
Exploit lands at user privilege — SYSTEM/root requires additional LPE

Detection/coverage: EDR behavioral detection: browser process spawning cmd.exe, powershell.exe, or writing to unusual filesystem locations; Windows Exploit Guard alerts

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Enable Chrome auto-update and verify fleet is on 149.0.7827.53+ — The definitive fix. Chrome's built-in updater should have pushed this within days of the June 2 release. Verify via enterprise browser management (Chrome Enterprise Core, SCCM, Intune, or equivalent) that ≥99% of your fleet is current. No noisgate mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window, though in practice Chrome auto-update should have resolved this months ago.

MEDIUM 5.5→LOW 3.0

SEVERITY REDUCED

Disable Enterprise Reporting policies if not actively used — If your organization does not use Chrome Enterprise Core reporting (policies CloudReportingEnabled, CloudProfileReportingEnabled), explicitly set them to disabled via GPO or MDM. This removes the IPC surface the vulnerability targets. Even if the underlying code is still present, reducing active IPC registration narrows the attack surface. Deploy within the 365-day remediation window.

MEDIUM 5.5→MEDIUM 5.0

Enforce site isolation and renderer process limits — Ensure SitePerProcess is enabled (default since Chrome 67) and consider StrictOriginIsolation. This limits what a compromised renderer can access via IPC by ensuring cross-origin content runs in separate processes. Does not directly block CVE-2026-11120 but constrains the blast radius of a renderer compromise.

MEDIUM 5.5→MEDIUM 4.5

Deploy EDR with browser-process behavioral monitoring — EDR agents (CrowdStrike, Defender for Endpoint, SentinelOne) should flag anomalous child process creation from chrome.exe — e.g., cmd.exe, powershell.exe, wscript.exe, or writes to %TEMP% with executable extensions. This detects the *outcome* of a successful sandbox escape even if the exploit itself is invisible. Ensure browser process monitoring rules are active.

What doesn't work

WAF or network IDS/IPS — This is a client-side browser vulnerability exploited via IPC within the browser process. There is no network signature to detect or block. WAF rules are irrelevant.
Disabling JavaScript — The renderer compromise prerequisite is the hard part; if an attacker already has renderer code execution, disabling JS doesn't prevent the IPC-based sandbox escape.
Network segmentation — The exploit chain occurs entirely within the browser process on the endpoint. Network segmentation does not prevent the sandbox escape itself, though it limits post-exploitation lateral movement.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None observed. Not listed in CISA KEV. No reports from Google TAG, Mandiant, or other threat intel vendors of active exploitation campaigns. GreyNoise shows no scanning activity (expected — client-side browser vuln has no server-side scan surface).
Proof-of-concept	No public PoC. No repositories found on GitHub named after CVE-2026-11120. Not indexed on pocindex.io. Not present in SecureWithUmer/CVE-2026-PoCs or nomi-sec/PoC-in-GitHub. No Nuclei template. The renderer-compromise prerequisite makes standalone PoC development impractical.
EPSS	0.00265 (0.27%) — 18th percentile. Bottom quintile of exploitation probability. Consistent with a chained vulnerability that has no public exploit code.
KEV status	Not listed. No CISA Known Exploited Vulnerabilities catalog entry as of 2026-09-30.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H` — 9.6 CRITICAL per NVD. The `AC:L` (Attack Complexity: Low) rating is the primary source of score inflation. The renderer-compromise prerequisite should push this toward `AC:H`, which would drop the score to ~8.3. Chromium's own assessment: Medium.
Affected versions	All Google Chrome desktop versions prior to 149.0.7827.53 (Linux) / 149.0.7827.54 (Windows, macOS). Chromium-based browsers (Edge, Brave, Opera, Vivaldi) sharing the affected codebase are also impacted if below the equivalent version.
Fixed versions	Chrome 149.0.7827.53 (Linux), 149.0.7827.54 (Windows/macOS), released June 2, 2026. Debian/Ubuntu: marked Not affected — likely does not ship the Enterprise Reporting component in their Chromium builds. Microsoft Edge: check corresponding Chromium base version.
Chromium severity	Medium — Chromium's own security team rates this two full tiers below NVD's CRITICAL. Chromium uses a custom severity model that accounts for exploit chain prerequisites. Red Hat also rates it Moderate.
Exploit market context	Full Chrome renderer + sandbox escape chains command $3–3.5M from brokers like Crowdfense. A sandbox escape alone is valued at ~$250K–$500K. This pricing reflects the extreme difficulty of the prerequisite renderer compromise.
Disclosure	Published 2026-06-04. Chromium issue tracker: issues.chromium.org/issues/501467566 (likely access-restricted). Reporting researcher not publicly credited in available release notes.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Renderer compromise prerequisite is a full exploit chain unto itself. The CVSS vector rates AC:L but the attacker needs a separate, independent vulnerability to compromise the renderer *before* CVE-2026-11120 becomes exploitable. Modern Chrome renderer exploits require 2+ bugs (V8 heap corruption + Ubercage bypass) and cost $500K–$3.5M on the broker market. This is not 'low complexity.'
Chromium's own team rates this Medium, not Critical. Google's Project Zero and Chrome Security team invented the modern browser sandbox model. When they rate their own sandbox escape bug as Medium, that assessment carries more signal than a mechanical CVSS calculation that ignores chaining prerequisites.
Zero exploitation evidence across all indicators. No KEV listing, no ITW reports, no public PoC, EPSS at 18th percentile (0.27%). Nearly four months post-disclosure with no movement toward weaponization.
Role multiplier: Chrome is an endpoint application, not a high-value infrastructure component. Chrome does not run as a domain controller, hypervisor, CI/CD server, identity provider, or network edge appliance. Even a fully successful exploit chain (renderer compromise → this sandbox escape) yields code execution on a *single endpoint* at user privilege level. The blast radius is host-level, not domain/fleet/supply-chain scale. No floor override applies. Chrome on an admin workstation increases *consequence* but that's true of any endpoint RCE — it doesn't make this CVE's inherent severity higher.
Friction compounds across the chain. Delivery requires social engineering past email gateways and URL filters. Renderer exploitation must defeat V8 sandbox, MiraclePtr, heap partitioning, and CFI. Sandbox escape must bypass CIG, ACG, ASLR, and DEP. EDR detects anomalous browser-process behavior. Each layer independently reduces the exploitable population.

Why not higher?

Upgrading to HIGH would require either active exploitation evidence, a public PoC lowering the attacker bar, or the affected component being a canonically high-value infrastructure role. None of these conditions are met. Chrome is a user-facing browser; even successful exploitation compromises a single endpoint at user privilege. The three-stage chain (renderer compromise → IPC abuse → sandbox escape) with no public tooling makes mass exploitation implausible.

Why not lower?

Dropping to LOW or IGNORE would undercount the strategic value of sandbox escapes to APT actors. While the chain is expensive, it *is* technically sound — a well-resourced adversary with a renderer exploit gains meaningful capability from this bug. Chrome's installed base is enormous (~3.5 billion users), and the Enterprise Reporting component ships in all desktop builds. The vulnerability is real and the patch is straightforward; it deserves normal patching-cycle priority, not dismissal.

06 · Verification

Crowdsourced verification payload.

Run on each target Windows host — no elevated privileges required. Execute via powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-11120.ps1 or push via SCCM/Intune. For Linux hosts, check google-chrome --version against 149.0.7827.53.

noisgate-verify.ps1

POWERSHELLREAD-ONLYSAFE

#Requires -Version 5.1
<# CVE-2026-11120 - Chrome Enterprise Reporting Sandbox Escape
   Checks installed Chrome version against fixed build 149.0.7827.53.
   Exit 0 = PATCHED, Exit 1 = VULNERABLE, Exit 2 = UNKNOWN #>

$FixedVersion = [version]'149.0.7827.53'
$RegPaths = @(
    'HKLM:\SOFTWARE\Google\Chrome\BLBeacon',
    'HKLM:\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
    'HKCU:\SOFTWARE\Google\Chrome\BLBeacon'
)
$Found = $false
foreach ($p in $RegPaths) {
    if (Test-Path $p) {
        $v = (Get-ItemProperty $p -ErrorAction SilentlyContinue).version
        if ($v) {
            $Found = $true
            try {
                $Installed = [version]$v
            } catch {
                Write-Output "UNKNOWN - Could not parse Chrome version: $v"
                exit 2
            }
            if ($Installed -ge $FixedVersion) {
                Write-Output "PATCHED - Chrome $v >= $FixedVersion (CVE-2026-11120 fixed)"
                exit 0
            } else {
                Write-Output "VULNERABLE - Chrome $v < $FixedVersion (CVE-2026-11120 applies)"
                exit 1
            }
        }
    }
}
# Fallback: check chrome.exe file version directly
$ExePaths = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
    "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
)
foreach ($exe in $ExePaths) {
    if (Test-Path $exe) {
        $Found = $true
        $fi = (Get-Item $exe).VersionInfo.ProductVersion
        try {
            $Installed = [version]$fi
        } catch {
            Write-Output "UNKNOWN - Could not parse Chrome exe version: $fi"
            exit 2
        }
        if ($Installed -ge $FixedVersion) {
            Write-Output "PATCHED - Chrome $fi >= $FixedVersion (CVE-2026-11120 fixed)"
            exit 0
        } else {
            Write-Output "VULNERABLE - Chrome $fi < $FixedVersion (CVE-2026-11120 applies)"
            exit 1
        }
    }
}
if (-not $Found) {
    Write-Output "UNKNOWN - Google Chrome not detected on this host"
    exit 2
}