This is a second-story window, not the front door
CVE-2026-10927 is an out-of-bounds read in Chrome's Dawn component, the graphics layer behind WebGPU, fixed in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS. The key catch is in Google's own description: the attacker must have already compromised the renderer process before this bug becomes useful, which makes it a post-compromise browser-chain primitive rather than a clean one-shot drive-by.
Google rated it HIGH (8.3), which is fair if you score pure technical impact inside a browser exploit chain. For enterprise patch triage, though, that overstates the standalone risk: this bug requires a prior browser exploit stage, lives behind Chrome's sandbox and Site Isolation design, has no KEV listing, very low EPSS, and no public in-the-wild exploitation evidence located. That combination pushes it down to MEDIUM for most fleets.
4 steps from start to impact.
Land malicious browser content
- User browses to attacker-controlled or attacker-influenced content
- Chrome version is older than the fixed build
- Relevant Dawn/WebGPU code path is reachable on the platform
- This is still UI-required browser exposure, not unauthenticated service exposure
- Many enterprise web gateways, URL filtering stacks, and browser isolation products reduce delivery success
- WebGPU reachability can vary by platform, feature state, and enterprise policy
Compromise the renderer first
- A separate renderer compromise exists and is reliable enough to run first
- The victim's browser hardening and patch level still allow that first-stage exploit
- Reliable modern Chrome renderer exploitation is expensive and noisy to develop
- Browser auto-update, exploit mitigations, and sandboxing sharply reduce the usable population
- Most opportunistic threat actors do not burn two-stage browser chains on broad enterprise users
Trigger Dawn out-of-bounds read
- Compromised renderer can invoke the vulnerable Dawn path
- Memory layout and code path are stable enough for useful reads
- Out-of-bounds read is weaker than a direct write or use-after-free RCE primitive
- Memory disclosure alone often needs additional grooming and chaining to become operationally valuable
- Platform-specific behavior in GPU stacks can hurt exploit reliability
Use the leak to advance the chain
- Leaked memory contains secrets, pointers, or cross-context data valuable to the attacker
- A follow-on chain stage exists to convert the read into meaningful compromise
- Chrome's sandbox and Site Isolation limit what a compromised renderer should be able to reach directly
- Cross-site and OS-level impact typically needs another bug or policy weakness
- Many enterprise sessions do not contain high-value browser-resident secrets at the moment of exploitation
The supporting signals.
| In-the-wild status | No public in-the-wild exploitation evidence located as of 2026-06-05; not listed in CISA KEV. |
|---|---|
| KEV status | No — absent from the CISA Known Exploited Vulnerabilities Catalog. |
| PoC availability | No public PoC or turnkey exploit repo for CVE-2026-10927 was located. Expect only custom exploit-chain code if this is used at all. |
| EPSS | 0.00068 from user-supplied intel; that is a very low exploitation probability signal relative to internet-facing mass-exploitation candidates. Source framework: FIRST EPSS. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the big tells are AC:H and UI:R, and Google's description adds an even more important real-world prerequisite: renderer compromise first. |
| Affected versions | Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows/macOS, per the stable release notes. |
| Fixed versions | Patched in 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS. Chrome's Android stable release notes state desktop security fixes generally carry over to the corresponding mobile release. |
| Exposure population | Chrome is ubiquitous in enterprise, but this is client-side endpoint exposure, not directly measurable internet service exposure. Shodan/Censys/FOFA-style internet scans are not meaningful for prioritizing this CVE. |
| Disclosure date | 2026-06-04 in the advisory data you supplied; the stable channel security release published 2026-06-02 and includes the fixed CVE. |
| Reporter | Reported by Google on 2026-04-06 in the Chrome stable channel security notes. |
noisgate verdict.
The decisive factor is the prerequisite that the attacker must already have compromised the renderer process. That turns this from a broad drive-by browser risk into a post-initial-exploitation chain component with a much smaller reachable population and much higher attacker cost.
Why this verdict
- Renderer compromise required: this is not a clean remote entry point; it assumes the attacker already beat Chrome once, which is major downward pressure on urgency.
- Client-side, UI-driven exposure: the reachable population is every browser endpoint in theory, but exploitation still depends on users rendering hostile content and the attacker having a working first-stage renderer exploit.
- Low threat telemetry: no KEV listing, no located public PoC, and a very low EPSS all argue against broad opportunistic exploitation right now.
Why not higher?
If this were a standalone remote code execution bug or an immediately weaponizable sandbox escape with public exploitation evidence, it would stay in HIGH or higher. But the chain starts with 'attacker already owns the renderer', which means this CVE is mostly useful to advanced operators already carrying a separate browser exploit stage.
Why not lower?
This still sits inside Chrome, one of the most widely deployed enterprise applications on the planet, and browser exploit chains remain strategically valuable. Even a read primitive can matter for mitigation bypass, secret leakage, or stabilizing a follow-on escape, so writing it off as backlog-only would be too casual.
What to do — in priority order.
- Force evergreen browser updates — Make sure Chrome auto-update is enforced and that stragglers are surfaced in fleet management. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but for browsers you should still close version drift quickly because chained browser bugs age badly.
- Tighten WebGPU and risky browser features where not needed — If business workflows do not require WebGPU or advanced graphics features, restrict them through enterprise policy for high-risk user groups and unmanaged browsing tiers. There is no mitigation SLA for MEDIUM here; treat this as hardening that reduces exploit-chain surface while you remediate within the 365-day window.
- Protect high-risk users with browser isolation or stronger web filtering — Executives, admins, developers, and helpdesk operators are the people worth spending a two-stage browser chain on. Apply stronger link isolation, category filtering, or remote browser isolation to those cohorts to make stage-one delivery and renderer compromise materially harder.
- Monitor for stale Chrome populations — Inventory endpoints that missed the Chrome 149 rollout and treat them as hygiene debt. MEDIUM means no mitigation SLA, but it does not mean you should tolerate unknown browser versions across a 10,000-host fleet.
- A network perimeter scanner won't tell you whether the vulnerable Dawn path is reachable or whether WebGPU is enabled on endpoints; this is client software, not a server socket problem.
- MFA is valuable for downstream account abuse, but it does not stop the browser memory bug itself.
- A generic WAF is largely irrelevant here because the exploit executes in the browser client, not against your web app edge.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory/EDR remote execution layer. Save as check_cve_2026_10927.py and invoke with python3 check_cve_2026_10927.py on macOS/Linux or py check_cve_2026_10927.py on Windows; no admin rights are required if the browser is installed in standard locations.
#!/usr/bin/env python3
# Check Chrome/Chromium version against CVE-2026-10927 fixed builds
# Outputs exactly one of: VULNERABLE, PATCHED, UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from pathlib import Path
FIXED = (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 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 '') + ' ' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def candidates_windows():
paths = []
envs = [
os.environ.get('ProgramFiles'),
os.environ.get('ProgramFiles(x86)'),
os.environ.get('LocalAppData'),
]
suffixes = [
r'Google\Chrome\Application\chrome.exe',
r'Chromium\Application\chrome.exe',
]
for base in envs:
if not base:
continue
for suf in suffixes:
p = Path(base) / Path(suf)
paths.append(str(p))
return paths
def candidates_macos():
return [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
str(Path.home() / 'Applications/Chromium.app/Contents/MacOS/Chromium'),
]
def candidates_linux():
return [
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
'/snap/bin/chromium',
'/opt/google/chrome/chrome',
]
def detect_version():
system = platform.system().lower()
paths = []
if 'windows' in system:
paths = candidates_windows()
elif 'darwin' in system:
paths = candidates_macos()
else:
paths = candidates_linux()
for path in paths:
if Path(path).exists():
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return path, ver, out
# Fallback to PATH resolution
for cmd in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
out = run_cmd([cmd, '--version'])
ver = parse_version(out)
if ver:
return cmd, ver, out
return None, None, None
def main():
path, ver, raw = detect_version()
if not ver:
print('UNKNOWN')
sys.exit(2)
if version_ge(ver, FIXED):
print('PATCHED')
sys.exit(0)
else:
print('VULNERABLE')
sys.exit(1)
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.