This is a burglar getting into the mall after closing, not into the vault
CVE-2026-11303 is a CWE-416 use-after-free in Chrome's PDFium renderer. Affected builds are Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows and macOS, with the June 2, 2026 stable release carrying the fix. The bug is triggered by a crafted PDF and can yield code execution in the browser's sandboxed renderer process.
The raw CVSS 8.8 overstates enterprise urgency if you read it like 'host compromise from the internet.' The decisive reality check is that execution is explicitly *inside the sandbox*, exploitation needs user interaction with attacker-supplied content, there is no KEV listing, no public in-the-wild signal, and EPSS is extremely low; that pushes this down from emergency patching into routine-but-real browser hygiene.
4 steps from start to impact.
Deliver a crafted PDF lure
PDFium engine; no server-side foothold is needed.- Unauthenticated remote attacker can reach a user
- Target user opens a PDF in Chrome or navigates to a URL serving one
- Requires user interaction (
UI:R), not a drive-by network daemon exploit - Mail security, Safe Browsing, attachment detonation, and user training cut a lot of commodity delivery volume
Trigger the PDFium use-after-free
- Victim is running a vulnerable Chrome build before
149.0.7827.53 - The malformed PDF reaches the built-in viewer without prior sanitization
- Modern browser exploit reliability against current Chrome builds is non-trivial even when bug class is familiar
- Bug details are still restricted in Chromium issue tracking, which slows fast follower weaponization
chrome crashes or anomalous renderer behavior, but most vuln tools only provide version-based coverage.Gain code execution in the sandboxed renderer
- Exploit achieves stable control flow redirection
- Chrome sandbox remains enabled but attacker can run code within the renderer
- Chrome's sandbox is the main severity brake here
- EDR, browser hardening, and exploit mitigations raise post-exploitation cost materially
Attempt meaningful impact beyond the renderer
- Attacker has a second-stage objective beyond renderer execution
- Controls like site isolation, EDR, and download restrictions do not stop follow-on activity
- No public evidence yet of a working escape chain tied to this CVE
- Meaningful host takeover generally requires additional vulnerabilities or very permissive endpoint controls
The supporting signals.
| In-the-wild status | No current public exploitation evidence found. Not in CISA KEV, and Chromium's public notes do not indicate in-the-wild activity. |
|---|---|
| KEV status | Not listed in KEV. As of the June 5, 2026 KEV catalog view, CVE-2026-11303 is absent. |
| Proof-of-concept availability | No public PoC located. Chromium bug details remain restricted; that is normal immediately after browser fixes ship and slows copycat weaponization. |
| EPSS | 0.0008 from the user intel block, which is *very low* in practical exploitation-likelihood terms. I could confirm FIRST's EPSS publication mechanics, but not a browsable per-CVE record from the provided official pages. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — the score is driven by remote reach and full CIA impact assumptions, but it does not model the decisive enterprise friction here: sandbox confinement. |
| Affected versions | Chrome prior to 149.0.7827.53. Google released 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS on 2026-06-02. |
| Fixed versions | Patch floor: 149.0.7827.53 or later. For managed fleets, treat Windows/macOS 149.0.7827.54 and Android 149.0.7827.59 as fixed-family descendants of the same patch line. |
| Vendor severity mismatch | Important discrepancy: the user-supplied CVSS-style severity is HIGH 8.8, but Google's Chrome release notes label CVE-2026-11303 as Low Chromium security severity. |
| Exposure/scanning reality | Not meaningfully internet-scannable. This is a client-side browser bug, so Shodan/Censys/FOFA-style census data is mostly irrelevant; your exposure is your managed browser population, not an exposed listener. |
| Disclosure / reporter | Disclosed: 2026-06-05 per the user intel block and ecosystem records. Reported by: Google in Chrome's release notes, with the Chromium issue created around 2026-04-20. |
noisgate verdict.
The single biggest downgrade factor is that successful exploitation yields code execution inside Chrome's sandbox, not a clean path to host compromise. This is still worth fixing because Chrome is everywhere and PDFs are normal business content, but the required user interaction plus lack of exploitation evidence keep it out of the urgent patch-now bucket.
Why this verdict
- Start at 8.8, then subtract hard for sandbox confinement: the stated impact is arbitrary code execution *inside a sandbox*, which materially narrows blast radius versus true browser-to-host RCE.
- Subtract for user interaction: the attacker still needs a user to open or render a crafted PDF, so this is not an unauthenticated server-side smash-and-grab path.
- Subtract for threat intel reality: no KEV listing, no public PoC found, and EPSS
0.0008all argue against rapid mass exploitation pressure right now.
Why not higher?
It is not HIGH or CRITICAL because the exploit chain, as disclosed, stops at sandboxed renderer execution. To become enterprise-disruptive at scale, an attacker usually needs a second vulnerability, a very specific browser-session objective, or a separate post-exploitation path that is not included in this CVE.
Why not lower?
It is not LOW or IGNORE because Chrome is ubiquitous across enterprise fleets and PDF handling is routine user behavior. Even sandboxed browser code execution can still support phishing bypass, session abuse, or follow-on exploitation, so this deserves scheduled remediation rather than documentation-only treatment.
What to do — in priority order.
- Verify browser auto-update health — Make sure managed endpoints are actually receiving Chrome stable updates and not pinned behind broken update channels or stale ring policies. For a
MEDIUMverdict there is no mitigation SLA; use normal operations and go straight to the remediation window while confirming that stragglers are visible. - Restrict inline PDF handling for high-risk users — For admins, executives, developers with prod access, and internet-facing support staff, consider forcing PDF download/open in a hardened reader or isolated browser session instead of inline rendering. This is a selective risk-reduction move, not a fleet-wide emergency control, and should be deployed during normal control windows because there is no noisgate mitigation deadline for
MEDIUM. - Lean on browser isolation where already deployed — If your stack already includes remote browser isolation or detonation for web/email-delivered documents, route suspicious PDFs through it. This helps most at the lure and render stages without needing disruptive endpoint changes.
- Watch for renderer crashes and odd Chrome child processes — Hunt for spikes in Chrome crash telemetry, browser-instigated download chains, or
chrome.exe/Google Chromespawning unusual children. This won't prevent the bug, but it can catch attempted exploitation and follow-on activity while patch coverage converges.
- A network perimeter scan will not tell you much here, because this is not an internet-facing service vulnerability.
- MFA does nothing for the exploit path itself; the attacker is targeting a local browser renderer, not authenticating to a remote service.
- Generic WAF rules are weak coverage because the trigger can arrive as a file attachment, a CDN-hosted PDF, or any user-opened local document.
Crowdsourced verification payload.
Run this on the target endpoint or via your endpoint-management agent, not from an auditor workstation. Invoke with python3 check_chrome_cve_2026_11303.py on Linux/macOS or py check_chrome_cve_2026_11303.py on Windows; standard user rights are usually enough because it only reads installed version metadata and common executable paths.
#!/usr/bin/env python3
# Check Google Chrome / Chromium family version against CVE-2026-11303 patch floor.
# Outputs exactly 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
PATCH_FLOOR = (149, 0, 7827, 53)
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 run_version_cmd(path):
try:
cp = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=5)
out = (cp.stdout or '') + ' ' + (cp.stderr or '')
return parse_version(out)
except Exception:
return None
def detect_windows():
versions = []
# Registry beacon first
try:
import winreg
reg_paths = [
(winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon'),
(winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Google\Chrome\BLBeacon'),
(winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'),
]
for hive, key in reg_paths:
try:
with winreg.OpenKey(hive, key) as k:
val, _ = winreg.QueryValueEx(k, 'version')
v = parse_version(str(val))
if v:
versions.append(('registry', v))
except OSError:
pass
except Exception:
pass
# Executable fallback
env_paths = [
os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for p in env_paths:
if p and os.path.exists(p):
v = run_version_cmd(p)
if v:
versions.append((p, v))
return versions
def detect_macos():
versions = []
candidates = [
'/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 p in candidates:
if os.path.exists(p):
v = run_version_cmd(p)
if v:
versions.append((p, v))
return versions
def detect_linux():
versions = []
commands = ['google-chrome', 'google-chrome-stable', 'chromium-browser', 'chromium', 'chrome']
for cmd in commands:
path = shutil.which(cmd)
if path:
v = run_version_cmd(path)
if v:
versions.append((path, v))
return versions
def main():
system = platform.system().lower()
if 'windows' in system:
found = detect_windows()
elif 'darwin' in system:
found = detect_macos()
else:
found = detect_linux()
if not found:
print('UNKNOWN')
sys.exit(2)
# Use the highest discovered version if multiple channels/installs exist.
highest = max(v for _, v in found)
if highest >= PATCH_FLOOR:
print('PATCHED')
sys.exit(0)
else:
print('VULNERABLE')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, and clean up pinned or stale rings first. Because this is a MEDIUM reassessment, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use that as the formal deadline, but in practice you should finish browser fleet convergence on your next normal update cycle and reserve selective PDF-handling controls for high-risk users rather than forcing disruptive fleet-wide mitigations.Sources
- Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
- Chromium issue 504416752
- Chromium Security page
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS data and statistics
- FIRST EPSS API documentation
- Chromium source tag diff for 149.0.7827.59 patch line
- Chrome Enterprise previous release notes
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.