← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11303 · CWE-416 · Disclosed 2026-06-05

Use after free in PDFium in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Real bug, real browser reach, but sandboxed renderer code exec with no exploitation evidence is not a fire drill"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a crafted PDF lure

The attacker weaponizes a malicious PDF and delivers it by email, chat, file-share, or web link. The only 'tool' required here is the crafted PDF itself rendered by Chrome's built-in PDFium engine; no server-side foothold is needed.
Conditions required:
  • Unauthenticated remote attacker can reach a user
  • Target user opens a PDF in Chrome or navigates to a URL serving one
Where this breaks in practice:
  • 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
Detection/coverage: Gateway scanners and browser isolation products may catch the lure, but version scanners cannot detect this step directly.
STEP 02

Trigger the PDFium use-after-free

When Chrome parses the malicious document, PDFium can dereference freed memory and corrupt renderer state. A successful exploit chain would use memory-shaping primitives inside the PDF to redirect execution flow within the renderer process.
Conditions required:
  • Victim is running a vulnerable Chrome build before 149.0.7827.53
  • The malformed PDF reaches the built-in viewer without prior sanitization
Where this breaks in practice:
  • 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
Detection/coverage: Endpoint telemetry may show chrome crashes or anomalous renderer behavior, but most vuln tools only provide version-based coverage.
STEP 03

Gain code execution in the sandboxed renderer

The advertised impact is arbitrary code execution *inside* Chrome's sandbox, not direct OS-level execution. That means the attacker lands in a heavily constrained process with limited filesystem, token, and OS interaction unless they chain a separate escape or abuse browser-session data already reachable in-process.
Conditions required:
  • Exploit achieves stable control flow redirection
  • Chrome sandbox remains enabled but attacker can run code within the renderer
Where this breaks in practice:
  • Chrome's sandbox is the main severity brake here
  • EDR, browser hardening, and exploit mitigations raise post-exploitation cost materially
Detection/coverage: EDR may detect abnormal child-process attempts, token abuse, or browser memory exploitation patterns; many events will still look like a browser crash.
STEP 04

Attempt meaningful impact beyond the renderer

To turn this into enterprise-grade compromise, the attacker usually needs a second bug or a same-session objective such as token theft, page manipulation, or follow-on download execution. Without a sandbox escape, blast radius is usually limited to what the compromised browser process can already touch.
Conditions required:
  • Attacker has a second-stage objective beyond renderer execution
  • Controls like site isolation, EDR, and download restrictions do not stop follow-on activity
Where this breaks in practice:
  • 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
Detection/coverage: This is where defenders are most likely to win: EDR, proxy logs, browser management telemetry, and suspicious download/child-process detections all become relevant.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current public exploitation evidence found. Not in CISA KEV, and Chromium's public notes do not indicate in-the-wild activity.
KEV statusNot listed in KEV. As of the June 5, 2026 KEV catalog view, CVE-2026-11303 is absent.
Proof-of-concept availabilityNo public PoC located. Chromium bug details remain restricted; that is normal immediately after browser fixes ship and slows copycat weaponization.
EPSS0.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 vectorCVSS: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 versionsChrome 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 versionsPatch 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 mismatchImportant 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 realityNot 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 / reporterDisclosed: 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

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.

HIGH Affected/fixed version mapping
MEDIUM Exploitability reassessment with restricted bug details

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.0008 all 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.

05 · Compensating Control

What to do — in priority order.

  1. 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 MEDIUM verdict there is no mitigation SLA; use normal operations and go straight to the remediation window while confirming that stragglers are visible.
  2. 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.
  3. 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.
  4. Watch for renderer crashes and odd Chrome child processes — Hunt for spikes in Chrome crash telemetry, browser-instigated download chains, or chrome.exe/Google Chrome spawning unusual children. This won't prevent the bug, but it can catch attempted exploitation and follow-on activity while patch coverage converges.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as managed browser hygiene with verification, not an incident-response sprint: confirm auto-update health, identify endpoints still below 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

  1. Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
  2. Chromium issue 504416752
  3. Chromium Security page
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS data and statistics
  6. FIRST EPSS API documentation
  7. Chromium source tag diff for 149.0.7827.59 patch line
  8. Chrome Enterprise previous release notes
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.