← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11304 · 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 booby-trapped brochure, not a skeleton key to the enterprise

CVE-2026-11304 is a use-after-free bug in Chrome's embedded PDF renderer, PDFium. Affected builds are Google Chrome desktop versions prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows and macOS, and exploitation requires getting a user to open attacker-controlled PDF content in a vulnerable browser. The public description says the flaw may allow heap corruption via a crafted PDF file; it does not publicly claim a sandbox escape or guaranteed full host compromise.

The 8.8 HIGH score is a classic CVSS overstatement for browser bugs because it assumes worst-case impact once the bug triggers, but it ignores the real-world chain: user interaction, client-side reachability, Chrome sandboxing, and the lack of observed exploitation. More importantly, Google/Chrome itself labeled this issue with Chromium security severity: Low, which is a strong signal that the vendor does not view the public bug as an easy or high-value standalone enterprise break.

"Big install base, but this is still a click-to-bug client-side parser flaw with no exploitation evidence"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver crafted PDF content

The attacker needs to place a malicious PDF in front of a target user, typically through phishing, drive-by content, chat/file share delivery, or a compromised site. The weapon here is the crafted PDF itself, rendered by Chrome's built-in PDFium engine rather than an external reader.
Conditions required:
  • Unauthenticated remote attacker can reach the user
  • Target uses Chrome below 149.0.7827.53
  • Target opens or previews attacker-controlled PDF content
Where this breaks in practice:
  • This is user-interaction required (UI:R), so no wormable server-side path exists
  • Modern email gateways, Safe Browsing, attachment detonation, and browser download reputation all reduce delivery success
  • Many enterprise users do not habitually open unsolicited PDFs in Chrome
Detection/coverage: Email/web security tooling usually sees the delivery event, but not every PDF exploit attempt. Network scanners cannot meaningfully detect exposure because this is a client-side parsing flaw.
STEP 02

Trigger PDFium memory corruption

When the PDF is parsed, the malformed object lifecycle can trigger a use-after-free in PDFium and corrupt heap state. The practical exploit tool here would be a custom exploit PDF plus memory-layout grooming tuned to the target Chrome build.
Conditions required:
  • Victim renders the PDF in vulnerable Chrome
  • Attacker's document reaches the affected PDFium code path
  • Exploit is reliable across the target OS/build/channel
Where this breaks in practice:
  • Public details are sparse and the Chromium issue remains restricted
  • Use-after-free bugs in hardened browser code often need careful allocator and version-specific reliability work
  • Chrome ships with modern exploit mitigations including sandboxing and memory-hardening controls
Detection/coverage: Crash telemetry, EDR browser-child-process crashes, and SOC monitoring of repeated Chrome faults can catch failed attempts. Signature-based vuln scanners generally cannot validate exploitability here.
STEP 03

Gain code execution in the renderer context

If exploitation succeeds, the most realistic immediate outcome is code execution in the compromised browser renderer/PDF process. For Chrome-class browser bugs, that is often materially different from full machine compromise because the renderer is sandboxed.
Conditions required:
  • The memory corruption is shaped into controlled execution rather than a crash
  • Target defenses do not terminate or isolate the process before payload execution
Where this breaks in practice:
  • The public record does not claim an unsandboxed RCE path
  • EDR, exploit protection, and Chrome crash/mitigation behavior can break many real-world exploit attempts
  • Impact may remain confined to a renderer context without a second bug
Detection/coverage: Behavioral EDR may flag suspicious child-process creation, token access, LOLBin launch, or abnormal browser process trees after renderer compromise.
STEP 04

Escape sandbox or steal session data

To turn renderer compromise into broad host impact, the attacker usually needs a second-stage technique: sandbox escape, credential theft via browser/session access, or post-exploitation using user context. The weaponized chain here is no longer CVE-2026-11304 alone; it becomes a browser exploit chain.
Conditions required:
  • Attacker has or pairs this bug with a sandbox escape or strong in-browser objective
  • The victim's endpoint controls fail to stop follow-on activity
Where this breaks in practice:
  • No public evidence ties this CVE to an in-the-wild chain
  • A second bug or strong post-exploitation path is typically required for major blast radius
  • Enterprise EDR usually has a better chance of seeing the second-stage activity than the initial PDF bug
Detection/coverage: Good EDR coverage on credential access, process injection, abnormal PowerShell/cmd spawn, or browser persistence materially raises attacker cost after initial exploit.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in reviewed sources; this CVE is not in CISA KEV.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog as reviewed.
EPSS0.00068 as supplied in the intel block — very low predicted near-term exploitation probability. FIRST documents EPSS as a 30-day exploitation likelihood estimate, not an impact score.
Proof-of-concept availabilityNo public PoC or exploit repository located in reviewed search results. The Chromium bug link exists, but details appear restricted, which is normal for fresh Chrome bugs.
Vendor vs scoring authorityGoogle/Chrome labels the issue Chromium security severity: Low, while CISA-ADP attached CVSS 8.8 HIGH. That mismatch is the core reason to downgrade.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H captures remote delivery and required user interaction, but it assumes worst-case impact after trigger and does not price in sandbox friction.
Affected versionsChrome desktop prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows/macOS per Google's June 2, 2026 stable-channel update.
Fixed versionsUpgrade to 149.0.7827.53 or later on Linux and 149.0.7827.53/54 or later on Windows/macOS. Reviewed sources did not provide a clean distro-backport matrix for this exact CVE.
Exposure/scanning realityShodan/Censys/FOFA-style exposure data is not meaningful here because this is a client-side browser parser issue, not an internet-exposed listening service.
Disclosure and reportingPublicly disclosed on 2026-06-05 in the supplied intel; NVD shows the CVE received from Chrome on 2026-06-04 and references the Chrome stable release from 2026-06-02. The Chrome release notes list it as reported by Google on 2026-04-20.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.4/10)

The decisive downgrade factor is that this is a client-side, user-driven browser parsing bug with no public exploitation evidence and no public claim of a sandbox escape. In practice, most enterprises only take meaningful damage from this class of bug when it is chained with delivery success and a second-stage escape or post-exploitation path.

HIGH Version/fix and vendor-vs-ADP severity mismatch
MEDIUM Practical exploitability assessment without full bug details
MEDIUM No-current-evidence judgment on public PoC / active exploitation

Why this verdict

  • Downgrade for attacker position: the attacker is remote but must still convince a user to open a crafted PDF, which makes this a delivery problem, not a straight reachable service bug.
  • Downgrade for real-world blast radius: successful exploitation most plausibly lands in a sandboxed browser process, not instant unconstrained host takeover.
  • Downgrade for threat evidence: no KEV, no public exploitation, and a very low EPSS all argue against emergency-tier prioritization.
  • Downgrade for vendor assessment: Chrome itself called the bug Low severity, while the 8.8 comes from scoring enrichment logic that predictably inflates browser memory-corruption cases.
  • Hold at MEDIUM, not LOW: Chrome is ubiquitous, PDFs are common lures, and use-after-free bugs can become valuable when paired with a second-stage exploit chain.

Why not higher?

There is no public evidence that CVE-2026-11304 is being used in the wild, and the published record does not claim a sandbox escape. The enterprise damage path depends on multiple compounding prerequisites: user action, exploit reliability against a hardened browser, and likely a second-stage escape or follow-on objective.

Why not lower?

This is still a memory-corruption bug in an extremely common client application, and PDF workflows are normal enough that users will render attacker-controlled documents. Even when a standalone bug is not emergency-grade, the reachable population is large enough that it should not be treated as mere backlog trivia.

05 · Compensating Control

What to do — in priority order.

  1. Force rapid browser auto-update — Validate that Chrome enterprise policies are allowing and enforcing stable-channel updates so endpoints move past 149.0.7827.53/54. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browser updates should happen much faster because the operational cost is low.
  2. Block risky PDF delivery paths — Use email gateway, secure web gateway, and chat/file-sharing controls to detonate, rewrite, or quarantine unsolicited PDFs from low-trust senders. This materially cuts the only practical first step in the chain and is the best compensating control until patch coverage is complete.
  3. Harden browser-to-reader handling — Where business workflow allows it, open untrusted PDFs in a more controlled viewer path or remote browser/session isolation instead of directly inside user Chrome sessions. Apply this for high-risk user groups first while you finish patch rollout inside the 365-day remediation window.
  4. Watch for browser crash clusters — Alert on abnormal spikes in chrome/chromium crashes involving PDF rendering, especially if they correlate with downloaded PDFs, phish campaigns, or child-process anomalies. Failed exploit attempts often show up as noisy browser instability before they show up as confirmed compromise.
What doesn't work
  • Perimeter network scanning does not help; this is not a server-side listening service with a remotely testable socket.
  • MFA does not stop exploitation of the PDF parser; it may help with later account abuse, but not with triggering the bug.
  • Generic vulnerability scanners usually cannot prove exploitability for this class of client-side browser issue; version inventory is the real control.
06 · Verification

Crowdsourced verification payload.

Run this on the target host or via your software-distribution/EDR live response tooling. Invoke it as python3 check_chrome_cve_2026_11304.py with standard user rights; it attempts to auto-detect Chrome on Windows, macOS, and Linux and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check local Google Chrome version for CVE-2026-11304 exposure
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / could not determine

import os
import platform
import re
import subprocess
import sys
from shutil import which

FIXED = (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_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def detect_windows():
    candidates = [
        [r'C:\Program Files\Google\Chrome\Application\chrome.exe', '--version'],
        [r'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe', '--version'],
    ]
    local_appdata = os.environ.get('LOCALAPPDATA')
    if local_appdata:
        candidates.append([os.path.join(local_appdata, 'Google', 'Chrome', 'Application', 'chrome.exe'), '--version'])

    for cmd in candidates:
        if os.path.exists(cmd[0]):
            out = run_cmd(cmd)
            v = parse_version(out)
            if v:
                return v, cmd[0]

    ps = which('powershell') or which('pwsh')
    if ps:
        script = r"""
$paths = @(
  'HKLM:\Software\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
  'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
  'HKCU:\Software\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe'
)
foreach ($p in $paths) {
  try {
    $item = Get-ItemProperty -Path $p -ErrorAction Stop
    if ($item.'(default)') { Write-Output $item.'(default)'; break }
  } catch {}
}
"""
        out = run_cmd([ps, '-NoProfile', '-Command', script])
        exe = out.strip().splitlines()[0] if out.strip() else ''
        if exe and os.path.exists(exe):
            ver = parse_version(run_cmd([exe, '--version']))
            if ver:
                return ver, exe

    return None, None


def detect_macos():
    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):
            out = run_cmd([p, '--version'])
            v = parse_version(out)
            if v:
                return v, p
    return None, None


def detect_linux():
    names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    for name in names:
        exe = which(name)
        if exe:
            out = run_cmd([exe, '--version'])
            v = parse_version(out)
            if v:
                return v, exe

    extra_paths = [
        '/opt/google/chrome/chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/snap/bin/chromium',
    ]
    for p in extra_paths:
        if os.path.exists(p):
            out = run_cmd([p, '--version'])
            v = parse_version(out)
            if v:
                return v, p

    return None, None


def compare_versions(found, fixed):
    if found < fixed:
        return -1
    if found > fixed:
        return 1
    return 0


def main():
    system = platform.system().lower()
    if 'windows' in system:
        version, source = detect_windows()
    elif 'darwin' in system:
        version, source = detect_macos()
    else:
        version, source = detect_linux()

    if not version:
        print('UNKNOWN: could not determine local Chrome/Chromium version')
        sys.exit(2)

    print(f'DETECTED: {source} -> {".".join(map(str, version))}')
    cmp = compare_versions(version, FIXED)
    if cmp < 0:
        print('VULNERABLE')
        sys.exit(1)
    else:
        print('PATCHED')
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as medium-priority browser hygiene, not an all-hands zero-day. Push inventory and update validation now, make sure untrusted PDF delivery is being screened, and complete version remediation to 149.0.7827.53/54 inside the noisgate remediation SLA of ≤365 days; for this MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window. If your org has high-risk user groups that routinely open external PDFs, tighten PDF delivery controls immediately while the browser fleet catches up.

Sources

  1. NVD entry for CVE-2026-11304
  2. Chrome Releases stable channel update for desktop (June 2, 2026)
  3. Chromium issue 504418475
  4. Canadian Centre for Cyber Security advisory AV26-544
  5. GovCERT.HK alert A26-06-08
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS overview
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.