This is a prison-break tunnel that only matters after the attacker is already inside the cell block
CVE-2026-10960 is an uninitialized-use bug in Chrome's Codecs component affecting Google Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS. The published description is unusually important here: the attacker must already have *compromised the renderer process* and then use a crafted HTML page to try to turn that foothold into a sandbox escape.
Google's HIGH label is technically understandable because a browser sandbox escape can convert a renderer compromise into broader system impact. But for enterprise patch triage, the vendor score overstates standalone urgency: this CVE is not a clean pre-auth remote browser takeover by itself, has no known public exploit chain, is not KEV-listed, and carries a very low EPSS, so the real-world severity drops once you audit the prerequisites.
4 steps from start to impact.
Land code execution in the renderer
- Victim must browse attacker-controlled or attacker-influenced content
- Attacker must already possess a working renderer compromise
- Target must still be on a version prior to
149.0.7827.53
- Requires a second vulnerability or prior compromise before this CVE matters
- Modern browser exploit chains are expensive and usually reserved for higher-value targeting
- Chrome's auto-update narrows the vulnerable window in managed fleets
Trigger the codec bug from crafted web content
- Codec-relevant code path must be reachable in the victim's browser build
- Attacker-controlled content must execute successfully in the compromised renderer
- Exploit reliability against uninitialized-memory bugs is often weaker than for cleaner memory-corruption primitives
- Chrome process isolation and hardening can reduce practical exploit stability
Attempt sandbox escape
- Step 2 must succeed reliably enough to cross the sandbox boundary
- Target platform defenses must not stop post-exploitation behavior
- EDR, exploit guard, and OS mitigations may catch the escape or follow-on actions
- A sandbox escape is impactful, but not automatically full-system compromise
Convert browser escape into enterprise impact
- Successful sandbox escape
- Useful local secrets, tokens, or reachable enterprise applications
- Standard-user desktops limit immediate privilege
- MFA, token binding, EDR, and browser isolation reduce follow-on value
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found as of 2026-06-06; not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC or GitHub exploit chain was found during this review. The Chromium issue is referenced but access-restricted, which is typical while fixes propagate. |
| EPSS | 0.00069 (~0.069%), which is extremely low and consistent with a hard-to-weaponize, chain-dependent browser bug. |
| KEV status | Not KEV-listed; no CISA addition date because it is absent from the catalog. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the score is pulled upward by browser-to-host impact, but AC:H and UI:R understate the *real* prerequisite: prior renderer compromise. |
| Affected versions | Google Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows/macOS. |
| Fixed versions | Update to 149.0.7827.53 or later on Linux and 149.0.7827.53/.54 or later on Windows/macOS. Chrome is shipped as a bundled browser release; distro-style CVE backport guidance is not the main enterprise decision point here. |
| Exposure and scanning reality | This is a client-side browser issue, not a scan-addressable internet service. Shodan/Censys exposure counts are therefore *not decision-useful* for direct reachability; the reachable population is instead your browser fleet size. |
| Disclosure timeline | Vendor release 2026-06-02; CVE publication visible in NVD 2026-06-04; NVD change history shows NIST analysis on 2026-06-05. |
| Reporter | Reported by Google on 2026-04-28 in the Chrome stable release notes. |
noisgate verdict.
The decisive factor is the prerequisite chain: this CVE only becomes useful *after* the attacker already has renderer compromise, which makes it a post-initial-exploitation escape component rather than a standalone remote enterprise compromise path. That sharply narrows both the reachable population and the number of real attackers who can operationalize it, despite the potentially high impact if chained successfully.
Why this verdict
- Major downward adjustment: requires prior renderer compromise — attacker position is not simple unauthenticated remote web access in practice; it implies a separate exploit, prior code execution, or a private chain already in hand.
- Population narrowing — Chrome is ubiquitous, but this step is only reachable against endpoints that are both unpatched *and* hit by a working renderer exploit, which cuts real exposed population far below the raw install base.
- Threat intel is quiet — no KEV entry, no public PoC identified, and EPSS is extremely low, all of which argue against treating this as a top-of-queue emergency on its own.
- Still not low — if chained, a sandbox escape is exactly the kind of primitive that turns a browser foothold into material endpoint risk, so it remains worth patching in normal browser maintenance.
Why not higher?
Because the attack path starts with a hidden tax: the adversary already needs renderer compromise. That means this CVE is not a one-bug internet-to-host event, not broadly reachable from the open web by commodity actors, and not supported by current exploitation evidence. In enterprise prioritization terms, those are compounding friction points that pull it out of the HIGH bucket.
Why not lower?
Because browser sandbox escapes are strategically valuable even when chain-dependent. Chrome is widely deployed, the vulnerable component sits in an attacker-influenced content path, and a successful escape can materially raise impact from a contained browser exploit to a real endpoint incident. That keeps it above backlog-only hygiene.
What to do — in priority order.
- Force browser auto-update compliance — Validate that enterprise policy is actually pulling Chrome to
149.0.7827.53/.54+and that stalled update cohorts are remediated. For aMEDIUMverdict there is no mitigation SLA — go straight to the 365-day remediation window, but for browsers you should close drift in the next routine endpoint maintenance cycle rather than letting exceptions linger. - Harden browser isolation for high-risk users — Use remote/browser isolation or stronger application containment for admins, developers, executives, and users handling sensitive SaaS sessions. This reduces the value of renderer-to-host exploit chaining while patching rolls through; with
MEDIUM, use it as targeted risk reduction rather than an emergency fleet-wide control. - Watch for crash and exploit-protection telemetry — Collect Chrome crash spikes, EDR exploit-mitigation alerts, and suspicious browser-child-process behavior on endpoints that have not yet updated. This does not replace patching, but it helps you spot whether a chain is being tested before you complete normal remediation.
- Reduce privileged browsing — Keep users out of local admin and separate admin workflows from daily browsing. Even if a browser chain lands, lower endpoint privilege reduces post-escape payoff; enforce during ordinary endpoint hardening work, not as a special emergency motion.
- A perimeter WAF does not help because this is client-side browser exploitation, not a server-side HTTP parsing issue in your environment.
- Relying on
AC:Hin the CVSS vector as a comfort blanket does not help; the real problem is chainability, and sophisticated actors can still use private exploit chains. - Version-only scanning by itself does not tell you which users are actually high risk; it finds drift, but it does not expose whether the separate renderer-exploit prerequisite exists.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory agent. Invoke with python3 chrome_cve_2026_10960_check.py on Windows, macOS, or Linux; no admin rights are required for basic local checks, though reading some install locations may work better with standard software-inventory permissions.
#!/usr/bin/env python3
# CVE-2026-10960 Chrome version check
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
TARGET_LINUX = (149, 0, 7827, 53)
TARGET_WIN_MAC = (149, 0, 7827, 53) # .53/.54 are fixed; >= .53 is treated as patched
def parse_version(text):
if not text:
return None
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def version_ge(a, b):
return a >= b
def run_cmd(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def find_windows_version():
candidates = [
os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
]
# Try registry first
reg_queries = [
["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
["reg", "query", r"HKCU\Software\Google\Chrome\BLBeacon", "/v", "version"],
["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
]
for cmd in reg_queries:
out = run_cmd(cmd)
v = parse_version(out)
if v:
return v, 'registry'
for path in candidates:
if os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
return v, path
return None, ''
def find_macos_version():
app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(app):
out = run_cmd([app, '--version'])
v = parse_version(out)
if v:
return v, app
plist = '/Applications/Google Chrome.app/Contents/Info.plist'
if os.path.exists(plist):
out = run_cmd(['/usr/bin/defaults', 'read', plist, 'CFBundleShortVersionString'])
v = parse_version(out)
if v:
return v, plist
return None, ''
def find_linux_version():
bins = [
'google-chrome',
'google-chrome-stable',
'chromium',
'chromium-browser',
]
for b in bins:
path = shutil.which(b)
if path:
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
return v, path
common = [
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
]
for path in common:
if os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
return v, path
return None, ''
def main():
system = platform.system().lower()
if 'windows' in system:
version, source = find_windows_version()
threshold = TARGET_WIN_MAC
elif 'darwin' in system or 'mac' in system:
version, source = find_macos_version()
threshold = TARGET_WIN_MAC
elif 'linux' in system:
version, source = find_linux_version()
threshold = TARGET_LINUX
else:
print('UNKNOWN: unsupported platform')
sys.exit(2)
if not version:
print('UNKNOWN: Google Chrome version not found')
sys.exit(2)
if version_ge(version, threshold):
print(f'PATCHED: detected version {".".join(map(str, version))} from {source}')
sys.exit(0)
else:
print(f'VULNERABLE: detected version {".".join(map(str, version))} from {source}')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window for the actual patch, but in practice you should push Chrome 149.0.7827.53/.54+ through your next managed browser rollout and clean up update drift promptly. There is no active-exploitation override here, so do not preemptively disrupt operations with emergency controls; instead, validate auto-update health now, identify lagging cohorts, and complete patch adoption within the noisgate remediation SLA window while prioritizing high-risk user groups first.Sources
- Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
- NVD entry for CVE-2026-10960
- Chromium issue 507258786 (restricted bug reference)
- Canadian Centre for Cyber Security advisory AV26-544
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- Shodan Internet Exposure Observatory
- Censys Search product overview
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.