This is the second key in a two-key vault, not a burglar opening the front door
CVE-2026-10905 is a use-after-free in Chrome's Network component affecting Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS. Per the CNA description you provided, exploitation requires an attacker to have already compromised the renderer process and then use this bug to move past that boundary, i.e. a likely sandbox-escape / privilege-boundary crossing step rather than initial code execution.
Google's HIGH 8.3 label is technically fair in isolation because a renderer-to-browser escape in Chrome matters. But in real enterprise patch triage, this is not an unauthenticated internet-to-endpoint compromise by itself. The decisive friction is the prerequisite: the attacker must first land a separate renderer exploit or comparable foothold, which turns this from a broad fleet emergency into a chain-dependent post-compromise enabler.
4 steps from start to impact.
Land renderer code execution with a separate bug
- Victim uses a vulnerable Chrome build before 149.0.7827.53/54
- Attacker has a separate working renderer-compromise primitive
- Victim reaches attacker-controlled content or installs attacker-controlled browser content
- Requires a second bug or pre-existing foothold before this CVE matters
- Renderer RCE chains are expensive and not commodity-grade for most actors
- Modern browser mitigations, exploit mitigations, and site isolation raise exploit-development cost
Trigger the Network use-after-free from the compromised renderer
- Reliable renderer foothold already exists
- Attacker can reach the vulnerable Network code path from that context
- Target configuration matches the exploit developer's assumptions
- Use-after-free bugs are often unstable across builds and platforms
- Exploit reliability can break under allocator hardening and version drift
- Restricted bug details slow copycat weaponization
Cross the sandbox boundary
- Successful memory corruption in the Network component
- Exploit chain survives modern Chromium hardening
- Target endpoint permits useful post-escape actions
- Chrome sandbox design is specifically meant to make this step hard
- EDR, exploit prevention, and application control may still stop follow-on payloads
- Impact can remain local to the user context if post-escape privilege elevation is absent
Operationalize endpoint access
- Successful sandbox escape
- Useful user privileges or accessible sensitive data
- No effective EDR/AppControl containment
- Least-privilege endpoints reduce blast radius
- Credential protections and MFA limit token abuse
- EDR containment can cut the chain before persistence or lateral movement
The supporting signals.
| In-the-wild status | No confirmed active exploitation found in reviewed primary sources; the bug is not KEV-listed. |
|---|---|
| Public PoC availability | No public PoC located in primary-source review. Chromium issue details appear restricted, which is normal until broad patch uptake. |
| EPSS | 0.00068 per your intel. That is a very low predicted near-term exploitation probability; percentile was not verified from a primary EPSS record in this review. |
| KEV status | No. As of the reviewed CISA KEV catalog, CVE-2026-10905 does not appear listed. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H means network-reachable with user interaction and high complexity, plus scope change consistent with crossing a trust boundary such as Chrome's sandbox. |
| Affected versions | Google Chrome prior to 149.0.7827.53; Chrome stable notes show patched builds as 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). |
| Fixed versions | Patch to 149.0.7827.53 or later. On Windows/macOS, 149.0.7827.54 is also part of the stable fix release. |
| Exposure reality | This is client software, not a server-side listening service. There is no meaningful Shodan/Censys-style internet exposure surface to count; exposure is driven by endpoint fleet size and patch lag, not public ingress. |
| Disclosure timeline | Disclosed 2026-06-04 per your intel. Google published the Chrome 149 stable patch on 2026-06-02. |
| Researcher / reporting | Google's stable release notes attribute the bug to c6eed09fc8b174b0f3eebedcceb1e792, reported on 2026-02-25. |
noisgate verdict.
The single biggest reason this drops to MEDIUM is the attacker position requirement: this bug only matters after the renderer is already compromised. That makes CVE-2026-10905 a chain component for sophisticated operators, not a stand-alone fleet-wide breach path for commodity attackers.
Why this verdict
- Downgrade for attacker position: the bug requires a pre-compromised renderer, which implies the attacker has already solved initial code execution with a separate exploit stage.
- Downgrade for reachable population: Chrome is everywhere, but this specific step is only reachable in the subset of attacks where a working renderer exploit already exists; that is a much narrower real-world slice than the vendor score assumes.
- Downgrade for defensive friction: Chrome sandboxing, site isolation, allocator hardening, EDR, and exploit protections all stack against reliable weaponization of a UAF chain step.
- Keep it above LOW: if paired with a renderer exploit, the bug can break a critical trust boundary on high-value endpoints, so the impact ceiling remains serious even if prevalence is low.
- No threat intelligence amplifier: no KEV listing, no confirmed in-the-wild use, and a very low EPSS score remove the usual upward pressure.
Why not higher?
Because this is not initial access. Requiring prior renderer compromise means the attack already depends on a separate exploit stage, which sharply reduces both the exposed population and the number of actors capable of using it effectively. Absent KEV, active exploitation, or a public weaponized chain, this does not earn a HIGH/CRITICAL operational priority.
Why not lower?
Because the trust boundary at stake is important. A browser sandbox escape on a widely deployed endpoint platform is still dangerous once chained, especially on privileged admin workstations or users with rich SaaS session access. This is too consequential to treat as backlog-only hygiene.
What to do — in priority order.
- Enforce rapid browser auto-update — Make sure managed Chrome channels are not pinned below 149.0.7827.53/54 and that update suppression policies are removed. For a MEDIUM noisgate rating there is no mitigation SLA, so treat this as operational hardening while you move through the remediation window.
- Prioritize high-value workstation rings — Push validation and update confirmation first on admin endpoints, developer workstations, VDI images, and browser-heavy user groups where a sandbox escape is most valuable to attackers. There is no mitigation SLA for MEDIUM, but these rings are where the exploit chain would pay off most.
- Hunt for Chrome crash anomalies — Look for unusual Chrome renderer/browser crashes, repeated relaunches, or exploit-protection telemetry around the disclosure window. That will not prove exploitation, but it is one of the few practical signals for memory-corruption attempts before a patch reaches full fleet coverage.
- Reduce post-browser blast radius — Confirm EDR tamper protection, application control, least privilege, and credential protections on endpoints so a successful sandbox escape has less room to operationalize. For this verdict, use the normal remediation motion rather than emergency containment.
- A WAF does not help; this is a client-side browser memory corruption issue, not a server-side web app flaw.
- Perimeter network segmentation does not meaningfully prevent the vulnerable code path from being reached through normal browsing.
- Email filtering alone is insufficient because the initial lure could just be a visited website, ad chain, chat link, or other user-driven web content.
Crowdsourced verification payload.
Run this on the target endpoint or via your software inventory agent. Invoke it with python3 verify_cve_2026_10905.py on Linux/macOS or py verify_cve_2026_10905.py on Windows; no admin rights are required if Chrome is installed in standard locations. The script checks local Chrome version and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# verify_cve_2026_10905.py
# Checks whether local Google Chrome is below 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
PATCHED_MIN = (149, 0, 7827, 53)
def parse_version(text):
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_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=5)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def find_linux_version():
candidates = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium', '--version'],
['chromium-browser', '--version'],
]
for cmd in candidates:
if which(cmd[0]):
out = run_cmd(cmd)
ver = parse_version(out)
if ver:
return ver, cmd[0], out
paths = [
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/snap/bin/chromium',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
]
for path in paths:
if os.path.exists(path):
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return ver, path, out
return None, None, None
def find_macos_version():
paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
'/Applications/Chromium.app/Contents/MacOS/Chromium',
]
for path in paths:
if os.path.exists(path):
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return ver, path, out
return None, None, None
def find_windows_version():
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'),
os.path.expandvars(r'%ProgramFiles%\Chromium\Application\chrome.exe'),
]
for path in paths:
if os.path.exists(path):
ps = (
"$p='{}';"
"if (Test-Path $p) {{"
" (Get-Item $p).VersionInfo.ProductVersion"
"}}"
).format(path.replace("'", "''"))
out = run_cmd(['powershell', '-NoProfile', '-Command', ps])
ver = parse_version(out)
if ver:
return ver, path, out
return None, None, None
def main():
system = platform.system().lower()
if 'linux' in system:
ver, source, raw = find_linux_version()
elif 'darwin' in system:
ver, source, raw = find_macos_version()
elif 'windows' in system:
ver, source, raw = find_windows_version()
else:
print('UNKNOWN - Unsupported OS: {}'.format(platform.system()))
sys.exit(2)
if not ver:
print('UNKNOWN - Chrome/Chromium version not found')
sys.exit(2)
if ver < PATCHED_MIN:
print('VULNERABLE - version {} detected from {}'.format('.'.join(map(str, ver)), source))
sys.exit(1)
else:
print('PATCHED - version {} detected from {}'.format('.'.join(map(str, ver)), source))
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.