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

Use after free in QUIC in Google Chrome on prior to 148

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

This is a break-in through the lobby that still leaves the attacker stuck behind the inner security door

CVE-2026-9114 is a CWE-416 use-after-free in Chrome’s QUIC/HTTP3 networking stack. Google’s CVE record says Chrome versions prior to 148.0.7778.179 are affected; the May 19, 2026 desktop release shipped 148.0.7778.178/179 for Windows/Mac and 148.0.7778.178 for Linux, so defenders need to rely on vendor packaging rather than assume every platform reports the exact same build string. The bug is reachable by malicious network traffic, which in practice means a victim browser has to talk QUIC to attacker-controlled content.

Vendor HIGH 8.8 overstates the enterprise urgency if you read it like host-level RCE. The important clause is *inside a sandbox*: this is code execution in a constrained browser process, not a sandbox escape, and there is no KEV entry, no public exploitation evidence in the cited sources, and a supplied EPSS of 0.0003 (0.03%). That keeps it real, but not fire-drill real.

"Remote memory corruption, yes—but it stops inside Chrome’s sandbox and lacks exploitation signals."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get the browser onto attacker-controlled QUIC

The attacker stands up a malicious HTTP/3 endpoint using a custom QUIC stack such as aioquic or quiche and lures a user to browse there. Because this is a browser-side networking flaw, the attacker does not need credentials or local access; they need the victim to initiate a QUIC session.
Conditions required:
  • Victim runs Chrome earlier than 148.0.7778.179
  • Victim reaches attacker-controlled content
  • QUIC/HTTP3 is enabled and usable end-to-end
Where this breaks in practice:
  • Many enterprises suppress QUIC by policy, TLS interception, or blocking UDP/443
  • User interaction is required by the CVSS vector
  • This is not a directly internet-exposed server bug
Detection/coverage: Perimeter scanners are poor here; exposure has to come from browser version inventory, EDR software inventory, Chrome Enterprise reporting, or package management data.
STEP 02

Trigger the QUIC use-after-free

The attacker sends crafted QUIC traffic intended to hit the freed-object state in Chrome’s QUIC implementation. Practical weaponization likely needs precise message sequencing and memory-shaping, so this is not the same thing as generic malformed-packet fuzzing.
Conditions required:
  • Attacker can fully control QUIC handshake/application traffic
  • Victim browser parses the crafted sequence
Where this breaks in practice:
  • No public PoC or exploit repo was located in browsed sources
  • Bug details remain restricted in Chromium issue tracking
  • Memory-corruption exploit reliability tends to be version- and platform-sensitive
Detection/coverage: Network IDS coverage is likely weak without a public signature. Browser crash spikes, anomalous QUIC failures, and endpoint telemetry are more realistic than packet-level detection.
STEP 03

Land code execution in the sandboxed browser process

Successful exploitation yields arbitrary code execution, but the public description explicitly says it executes *inside a sandbox*. That means the attacker gets a foothold in a constrained Chrome process, not immediate native code execution with full user rights on the endpoint.
Conditions required:
  • Memory corruption is exploited reliably on the target build
  • Chrome mitigations are bypassed enough to gain instruction control
Where this breaks in practice:
  • Chrome sandboxing, site isolation, CFG/CET, and OS exploit mitigations reduce post-trigger impact
  • No public evidence shows this CVE alone escaping the sandbox
Detection/coverage: EDR may catch anomalous browser memory behavior, crash loops, or suspicious child-process behavior, but pure in-process exploitation can still be quiet.
STEP 04

Chain to meaningful endpoint compromise

To turn this into full workstation compromise, the attacker usually needs a second bug for sandbox escape, a browser-to-OS pivot, or a data theft objective that fits within sandbox constraints. That missing second stage is the biggest reason this lands below High in real-world patch triage.
Conditions required:
  • A follow-on privilege-escalation or sandbox-escape path exists
  • Target data is accessible from the compromised browser context
Where this breaks in practice:
  • No chained exploit is referenced in public sources
  • Blast radius is often one user session, one browser profile, one endpoint
Detection/coverage: Follow-on behavior is where defenders usually win: EDR, privilege-escalation detections, browser isolation alerts, and abnormal persistence attempts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public in-the-wild exploitation was found in the cited sources. CISA ADP enrichment for the CVE records Exploitation: none and Automatable: no.
KEV statusNot KEV-listed in CISA’s Known Exploited Vulnerabilities Catalog in the cited catalog source.
PoC availabilityNo public GitHub PoC or exploit write-up was located during browsing. Chromium bug details are still restricted, which raises attacker cost.
EPSSSupplied intel says 0.0003 (0.03%), which is very low. Percentile was not provided in the prompt and was not independently confirmed from browsed sources.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means remote and no-auth, but user interaction is required and the public description says execution is inside the sandbox, which is the key real-world downgrade.
Affected versionsChrome before 148.0.7778.179 per CVE/NVD. The release bulletin ties the fix set to the May 19, 2026 desktop update.
Fixed versionsGoogle shipped 148.0.7778.178/179 for Windows/Mac and 148.0.7778.178 for Linux. Debian marks chromium fixed in Bookworm/Trixie security at 148.0.7778.178-1~deb12u1 / 148.0.7778.178-1~deb13u1; Ubuntu marks supported chromium-browser packages as Not affected in its tracker.
Exposure realityShodan/Censys-style external scanning is mostly irrelevant here because this is a client-side browser flaw, not a server service. Exposure measurement is a fleet inventory problem: browser version, QUIC policy, and unmanaged endpoints.
Disclosure timelinePublished on 2026-05-20 in the CVE record; Google’s desktop stable release carrying the fix was posted 2026-05-19.
ReporterGoogle’s release notes list CVE-2026-9114 as reported by Google on 2026-03-24.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.4/10)

The decisive factor is that the advertised code execution lands inside Chrome’s sandbox, not on the host with unrestricted user rights. Without a public escape chain, active exploitation, or broad automatable reach, this looks like a real browser bug that belongs in the normal browser update program rather than emergency change windows.

HIGH Affected-version and fix-version metadata
MEDIUM Enterprise exploitability assumptions around QUIC reachability
MEDIUM Assessment that no public weaponized PoC is currently available

Why this verdict

  • Downgrade for sandbox-only impact: the public advisory explicitly says code execution occurs *inside a sandbox*, so vendor CVSS overstates endpoint-compromise reality unless this is chained with a second bug.
  • Downgrade for reachability friction: exploitation requires a user-driven browser session over QUIC/HTTP3, and many enterprises reduce that path with proxies, browser policy, or UDP/443 blocking.
  • Downgrade for missing threat signal: no KEV listing, CISA ADP says Exploitation: none, supplied EPSS is 0.0003, and no public PoC was found in the cited sources.
  • Keep it above LOW because Chrome is everywhere: this is still unauthenticated remote memory corruption in a massively deployed client, so once users browse attacker content the pre-auth portion of the chain is straightforward.

Why not higher?

If this were a sandbox escape, or if there were active exploitation, a public exploit chain, or clear bypass of common enterprise QUIC controls, this would move up fast. As published, the blast radius is capped by the browser sandbox and by the fact that the attacker still needs user browsing behavior plus QUIC reachability.

Why not lower?

This is not harmless parser weirdness; it is real memory corruption with arbitrary code execution in browser context. Chrome’s install base is enormous, and browser-context code execution can still steal session material, abuse web permissions, or become the first leg of a two-bug chain.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update and relaunch — Use Chrome Enterprise, MDM, RMM, or package management to push fixed builds and enforce restart prompts. For a MEDIUM noisgate verdict there is no mitigation SLA; use this as routine control hygiene and complete the actual patch inside the 365-day remediation window.
  2. Disable QUIC on lagging fleets — If you have unmanaged or hard-to-restart endpoints, disable Chrome QUIC/HTTP3 by policy or block UDP/443 at egress to remove the vulnerable transport path. For MEDIUM, there is no mitigation SLA; treat this as an interim reduction measure while normal patch rollout catches up.
  3. Prioritize high-risk browsing populations — Apply version enforcement first to users who browse untrusted external content heavily: researchers, executives, sales, support, and contractor populations. Even without a mitigation SLA, this narrows the real attack surface early inside the same 365-day remediation window.
  4. Inventory unmanaged Chromium variants — Query EDR/software inventory for Chrome, Chromium, Edge-derived testing builds, VDI gold images, and kiosk systems that miss normal browser cadence. This matters because client-side browser exposure is usually in the long tail, not the managed majority.
What doesn't work
  • A WAF does not protect the endpoint browser from malicious QUIC traffic coming from arbitrary internet sites.
  • External vulnerability scanners will not tell you who is exposed; this is a client version-management problem, not an internet-facing service fingerprinting problem.
  • Assuming TLS inspection solves it is risky because QUIC often bypasses traditional HTTPS interception unless you explicitly disable or block it.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet execution tool. Invoke it with python3 check_cve_2026_9114.py; no admin rights are usually required, but Windows registry reads are more reliable from a normal user session on the local host. The script checks common Chrome install paths and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_9114.py
# Determine whether Google Chrome on this host is vulnerable to CVE-2026-9114.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

FIXED = (148, 0, 7778, 179)


def norm(v):
    nums = [int(x) for x in re.findall(r'\d+', v)]
    while len(nums) < 4:
        nums.append(0)
    return tuple(nums[:4])


def cmp_ver(a, b):
    return (a > b) - (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 get_windows_versions():
    versions = []
    reg_paths = [
        r'HKLM\SOFTWARE\Google\Chrome\BLBeacon',
        r'HKLM\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
        r'HKCU\SOFTWARE\Google\Chrome\BLBeacon',
    ]
    for path in reg_paths:
        out = run_cmd(['reg', 'query', path, '/v', 'version'])
        m = re.search(r'version\s+REG_\w+\s+([0-9\.]+)', out, re.I)
        if m:
            versions.append(('Google Chrome', m.group(1), path))

    exe_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'),
    ]
    for exe in exe_paths:
        if os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            m = re.search(r'(\d+\.\d+\.\d+\.\d+)', out)
            if m:
                versions.append(('Google Chrome', m.group(1), exe))
    return versions


def get_macos_versions():
    versions = []
    apps = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for app in apps:
        if os.path.exists(app):
            out = run_cmd([app, '--version'])
            m = re.search(r'(\d+\.\d+\.\d+\.\d+)', out)
            if m:
                versions.append(('Google Chrome', m.group(1), app))
    return versions


def get_linux_versions():
    versions = []
    bins = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    for b in bins:
        out = run_cmd([b, '--version'])
        m = re.search(r'(\d+\.\d+\.\d+\.\d+)', out)
        if m:
            versions.append((b, m.group(1), b))
    return versions


def main():
    system = platform.system().lower()
    found = []

    if 'windows' in system:
        found = get_windows_versions()
    elif 'darwin' in system:
        found = get_macos_versions()
    elif 'linux' in system:
        found = get_linux_versions()
    else:
        print('UNKNOWN - unsupported platform: {}'.format(platform.system()))
        sys.exit(2)

    if not found:
        print('UNKNOWN - Google Chrome/Chromium not found in common locations')
        sys.exit(2)

    vulnerable = []
    patched = []

    for name, ver, src in found:
        nver = norm(ver)
        if cmp_ver(nver, FIXED) < 0:
            vulnerable.append((name, ver, src))
        else:
            patched.append((name, ver, src))

    # Prefer a vulnerable finding if any matching browser is below the fixed version.
    if vulnerable:
        details = '; '.join(['{} {} [{}]'.format(n, v, s) for n, v, s in vulnerable])
        print('VULNERABLE - found version(s) below {}: {}'.format('.'.join(map(str, FIXED)), details))
        sys.exit(1)

    details = '; '.join(['{} {} [{}]'.format(n, v, s) for n, v, s in patched])
    print('PATCHED - found version(s) at or above {}: {}'.format('.'.join(map(str, FIXED)), details))
    sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: pull a software inventory for Chrome/Chromium below 148.0.7778.179, push the current browser update through your normal endpoint tooling, and clean up unmanaged stragglers and VDI/kiosk images. Because this is MEDIUM, there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window; in practice that means no emergency CAB, but you should finish the patch program by 2027-05-20 under the noisgate remediation SLA. If you have laggards in high-risk browsing groups, disable QUIC or block UDP/443 on those endpoints until the browser update lands.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (May 19, 2026)
  2. NVD - CVE-2026-9114
  3. OpenCVE - CVE-2026-9114
  4. Chromium issue 495798630
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS
  7. Debian security tracker - chromium source package
  8. Ubuntu CVE tracker search results including CVE-2026-9114
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.