This is a second lock on the vault door failing after the burglar is already in the lobby
CVE-2026-10919 is a use-after-free in ANGLE, Chrome’s graphics translation layer, affecting Google Chrome versions prior to 149.0.7827.53. The key qualifier is in the vendor wording: the attacker must have already compromised the renderer process and then use a crafted HTML page to try to escape Chrome’s sandbox. In plain English, this is not the phishing-click-to-full-host-compromise bug by itself; it is the second-stage breakout that turns a renderer foothold into something more dangerous.
Google’s HIGH 8.3 label overstates the operational urgency for enterprise patch triage because it scores the technical impact once the bug is reachable, not the real-world friction to reach it. The decisive downgrade is the prerequisite chain: user interaction + a separate renderer compromise + successful exploit reliability inside a modern sandboxed browser. That keeps this important for browser hygiene, but it is not the kind of naked remote edge exploit that should jump ahead of actively exploited internet-facing flaws.
4 steps from start to impact.
Land code execution in the renderer first
- Victim browses attacker-controlled content
- A separate renderer bug or exploit chain succeeds first
- Attacker gains code execution or equivalent control in the renderer process
- Requires chaining with another bug; CVE-2026-10919 is not initial access
- Modern browser mitigations, exploit hardening, and renderer isolation reduce chain reliability
- No public PoC or in-the-wild evidence lowers opportunistic abuse
Trigger the ANGLE UAF from the compromised renderer
- Renderer compromise already exists
- Target build is <
149.0.7827.53 - The vulnerable ANGLE code path is reachable on the victim platform/configuration
- Exploitability can vary by OS, GPU stack, driver behavior, and backend
- Memory corruption bugs in browser graphics paths are often fragile across builds
- ANGLE bug details were still restricted around release, limiting copycat development
Convert memory corruption into a sandbox escape
- Successful memory corruption primitive from ANGLE
- Exploit stability sufficient to avoid simple crash-only outcomes
- Sandbox defenses do not neutralize or contain the attempt
- Chrome’s sandbox and Site Isolation are explicitly designed to contain compromised renderers
- Many attempts degrade to browser crash/DoS instead of controlled escape
- Cross-version exploit reliability is usually poor without tailored engineering
Act after escape
- Sandbox escape succeeds
- Post-escape privileges are sufficient for the attacker’s goal
- Endpoint controls do not block follow-on actions
- EDR should have a chance to catch abnormal browser child-process or LOLBin activity
- Privilege after escape may still be limited by OS controls and user context
- Enterprise hardening can contain blast radius to a single endpoint/session
The supporting signals.
| In-the-wild status | No public evidence of active exploitation as of 2026-06-04; not observed in the sources reviewed. |
|---|---|
| KEV status | Not listed in CISA KEV at review time. |
| Public PoC | No public PoC found. Chrome bug details commonly stay restricted until most users are updated, which slows copycat weaponization. |
| EPSS | 0.00068 from the supplied intel block — extremely low predicted exploitation likelihood in the next 30 days. |
| Vendor severity | HIGH 8.3 with vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H from the supplied intel. |
| What the vector misses | The CVSS framing captures browser-delivered impact, but it does not price in the operational reality that the attacker must already have renderer compromise. That prerequisite is the main reason for the downgrade. |
| Affected versions | Google Chrome < 149.0.7827.53. |
| Fixed version | Update to 149.0.7827.53 or later. Google published 149.0.7827.53/.54 as an early stable desktop update on 2026-05-29. |
| Exposure / scanning reality | This is a client-side browser flaw, so Shodan/Censys/FOFA are not meaningful exposure measures. Exposure is driven by endpoint browser inventory, unmanaged browsers, and lagging auto-update rings. |
| Researcher / reporting | Public bug detail appears restricted at disclosure, so a named external reporter was not visible in the reviewed official release material. |
noisgate verdict.
The decisive factor is that exploitation requires prior renderer compromise, which makes this a post-initial-access browser escape stage rather than a stand-alone internet-to-host break. That sharply narrows both the reachable population and the number of attackers who can use it reliably, despite the severe impact if chained successfully.
Why this verdict
- Downgrade for attacker position: this is not unauthenticated remote code execution by itself; the attacker must first compromise the renderer, which implies an earlier successful exploit stage.
- Downgrade for exposed population: every Chrome endpoint may carry the vulnerable code, but only the subset facing a working renderer exploit chain is actually reachable for this CVE.
- Downgrade for defensive friction: modern Chrome sandboxing, Site Isolation, exploit mitigations, and EDR raise the failure rate from ‘memory bug exists’ to ‘reliable host impact achieved’.
- Hold at MEDIUM, not LOW: Chrome is massively deployed, ANGLE is security-relevant, and a sandbox escape is high-value to advanced exploit chains even when it is not independently reachable.
- No threat amplifier present: no KEV listing, no known public PoC, and no public in-the-wild evidence were found to justify keeping the vendor’s HIGH operational priority.
Why not higher?
A higher rating would require at least one major amplifier: active exploitation, KEV listing, a public reliable PoC, or direct unauthenticated remote reachability. None are present here. The need for a separate renderer compromise is compounding downward pressure because it assumes the attacker has already cleared the hardest browser exploitation step.
Why not lower?
This is still a sandbox escape in Chrome, not harmless crashware. In environments facing targeted browser exploitation, second-stage escapes are exactly what turns a renderer bug into meaningful host impact, so backlog-only treatment would understate the risk.
What to do — in priority order.
- Enforce browser auto-update — Make sure managed Chrome channels cannot sit below
149.0.7827.53indefinitely. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browsers should still ride normal rapid-update policy rather than discretionary user timing. - Reduce unmanaged browsing — Push users into enterprise-managed Chrome profiles and remove stale side-installed browser copies where possible. This matters because exposure is inventory-driven; for MEDIUM there is no mitigation SLA — go straight to the 365-day remediation window.
- Harden browser exploit surface — Keep Site Isolation, EDR exploit prevention, and OS/browser hardening fully enabled to make renderer-to-sandbox chains less reliable. These are containment controls, not substitutes for patching; for MEDIUM there is no mitigation SLA — go straight to the 365-day remediation window.
- Watch for browser-child anomalies — Tune EDR for suspicious browser process trees, crash bursts, and unexpected broker or child-process behavior. This helps catch exploit-chain execution while you work through the normal remediation cycle; for MEDIUM there is no mitigation SLA — go straight to the 365-day remediation window.
- A network scanner will not prove safety here, because this is not an internet-facing service flaw; you need endpoint version inventory.
- User training alone does not solve the core issue; even though a crafted page is involved, the real gate is the exploit chain inside the browser.
- WAFs or perimeter filtering are weak controls for a client-side browser memory-corruption path and will not reliably stop malicious content delivery.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory tooling. Invoke with python3 check_chrome_cve_2026_10919.py on macOS/Linux or py check_chrome_cve_2026_10919.py on Windows; no admin rights are required as long as the Chrome binary is readable in standard install paths.
#!/usr/bin/env python3
# check_chrome_cve_2026_10919.py
# Detects whether Google Chrome is vulnerable to CVE-2026-10919 based on version.
# Vulnerable: versions prior to 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from typing import Optional, Tuple
FIXED = (149, 0, 7827, 53)
def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def run_version(cmd):
try:
out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
return parse_version(out)
except Exception:
return None
def check_windows() -> Optional[Tuple[int, int, int, int]]:
paths = [
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'),
]
for p in paths:
if p and os.path.exists(p):
v = run_version([p, '--version'])
if v:
return v
if shutil.which('chrome'):
return run_version(['chrome', '--version'])
return None
def check_macos() -> Optional[Tuple[int, int, int, int]]:
paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for p in paths:
if os.path.exists(p):
v = run_version([p, '--version'])
if v:
return v
return None
def check_linux() -> Optional[Tuple[int, int, int, int]]:
candidates = [
'google-chrome',
'google-chrome-stable',
'/opt/google/chrome/chrome',
'chromium',
'chromium-browser',
]
for c in candidates:
path = shutil.which(c) if not c.startswith('/') else c
if path and os.path.exists(path):
v = run_version([path, '--version'])
if v:
return v
return None
def main():
system = platform.system().lower()
if 'windows' in system:
version = check_windows()
elif 'darwin' in system:
version = check_macos()
else:
version = check_linux()
if not version:
print('UNKNOWN - Google Chrome not found or version unreadable')
sys.exit(2)
version_str = '.'.join(str(x) for x in version)
fixed_str = '.'.join(str(x) for x in FIXED)
if version < FIXED:
print(f'VULNERABLE - detected Chrome {version_str}; fixed version is {fixed_str} or later')
sys.exit(1)
else:
print(f'PATCHED - detected Chrome {version_str}; fixed threshold is {fixed_str}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, make sure enterprise auto-update is functioning, and fold stragglers into your normal browser update ring. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is ≤365 days, but because browsers update cheaply and frequently, most mature teams should clear this well before that outer limit rather than leaving stale versions to age in unmanaged pockets.Sources
- Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Chromium - Site Isolation overview
- Chromium - Site Isolation design document
- Chromium source - Sandbox design
- ANGLE project README
- CISA Known Exploited Vulnerabilities Catalog
- Chromium Security - Memory safety
- Chromium Security landing page
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.