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

Uninitialized Use in Codecs in Google Chrome prior to 149

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

This is a prison-break tunnel that only matters after the attacker is already inside the cell block

CVE-2026-10960 is an uninitialized-use bug in Chrome's Codecs component affecting Google Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS. The published description is unusually important here: the attacker must already have *compromised the renderer process* and then use a crafted HTML page to try to turn that foothold into a sandbox escape.

Google's HIGH label is technically understandable because a browser sandbox escape can convert a renderer compromise into broader system impact. But for enterprise patch triage, the vendor score overstates standalone urgency: this CVE is not a clean pre-auth remote browser takeover by itself, has no known public exploit chain, is not KEV-listed, and carries a very low EPSS, so the real-world severity drops once you audit the prerequisites.

"Serious bug, wrong priority: this is a sandbox-escape component, not a one-click internet-to-host compromise."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land code execution in the renderer

The attacker first needs a separate renderer-compromise primitive, typically from a different browser bug or an already weaponized web exploit chain. CVE-2026-10960 is not that initial bug; it is a *post-renderer-compromise* escalation step. No public weaponized tool for this CVE was identified, so any use today would likely ride inside a private chain.
Conditions required:
  • Victim must browse attacker-controlled or attacker-influenced content
  • Attacker must already possess a working renderer compromise
  • Target must still be on a version prior to 149.0.7827.53
Where this breaks in practice:
  • Requires a second vulnerability or prior compromise before this CVE matters
  • Modern browser exploit chains are expensive and usually reserved for higher-value targeting
  • Chrome's auto-update narrows the vulnerable window in managed fleets
Detection/coverage: Vulnerability scanners can identify vulnerable Chrome versions, but they cannot prove exploitability because the gating factor is the separate renderer exploit.
STEP 02

Trigger the codec bug from crafted web content

Once the renderer is compromised, the attacker serves or navigates the victim to crafted HTML that drives the vulnerable Codecs path. The uninitialized-use condition can then be manipulated as part of an attempt to cross Chrome's sandbox boundary.
Conditions required:
  • Codec-relevant code path must be reachable in the victim's browser build
  • Attacker-controlled content must execute successfully in the compromised renderer
Where this breaks in practice:
  • Exploit reliability against uninitialized-memory bugs is often weaker than for cleaner memory-corruption primitives
  • Chrome process isolation and hardening can reduce practical exploit stability
Detection/coverage: Network controls have poor visibility here; browser crash telemetry, EDR child-process anomalies, and exploit-protection events are more useful than perimeter detections.
STEP 03

Attempt sandbox escape

The intended payoff is a break from the low-privilege renderer sandbox into a more privileged browser or OS context. That can materially increase attacker reach, but it is still constrained by OS mitigations, user rights, and the quality of the overall exploit chain.
Conditions required:
  • Step 2 must succeed reliably enough to cross the sandbox boundary
  • Target platform defenses must not stop post-exploitation behavior
Where this breaks in practice:
  • EDR, exploit guard, and OS mitigations may catch the escape or follow-on actions
  • A sandbox escape is impactful, but not automatically full-system compromise
Detection/coverage: Behavioral EDR may catch suspicious process interactions or memory-corruption side effects; version-only scanners will miss exploitation attempts.
STEP 04

Convert browser escape into enterprise impact

Only after a successful escape does the attacker move to credential theft, session theft, or local pivoting. The blast radius is then driven less by the CVE itself and more by the victim's privileges, endpoint hardening, and whether the browser session has access to sensitive enterprise apps.
Conditions required:
  • Successful sandbox escape
  • Useful local secrets, tokens, or reachable enterprise applications
Where this breaks in practice:
  • Standard-user desktops limit immediate privilege
  • MFA, token binding, EDR, and browser isolation reduce follow-on value
Detection/coverage: Downstream identity and endpoint telemetry usually provides better signal than web logs.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found as of 2026-06-06; not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC or GitHub exploit chain was found during this review. The Chromium issue is referenced but access-restricted, which is typical while fixes propagate.
EPSS0.00069 (~0.069%), which is extremely low and consistent with a hard-to-weaponize, chain-dependent browser bug.
KEV statusNot KEV-listed; no CISA addition date because it is absent from the catalog.
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the score is pulled upward by browser-to-host impact, but AC:H and UI:R understate the *real* prerequisite: prior renderer compromise.
Affected versionsGoogle Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows/macOS.
Fixed versionsUpdate to 149.0.7827.53 or later on Linux and 149.0.7827.53/.54 or later on Windows/macOS. Chrome is shipped as a bundled browser release; distro-style CVE backport guidance is not the main enterprise decision point here.
Exposure and scanning realityThis is a client-side browser issue, not a scan-addressable internet service. Shodan/Censys exposure counts are therefore *not decision-useful* for direct reachability; the reachable population is instead your browser fleet size.
Disclosure timelineVendor release 2026-06-02; CVE publication visible in NVD 2026-06-04; NVD change history shows NIST analysis on 2026-06-05.
ReporterReported by Google on 2026-04-28 in the Chrome stable release notes.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

The decisive factor is the prerequisite chain: this CVE only becomes useful *after* the attacker already has renderer compromise, which makes it a post-initial-exploitation escape component rather than a standalone remote enterprise compromise path. That sharply narrows both the reachable population and the number of real attackers who can operationalize it, despite the potentially high impact if chained successfully.

HIGH Affected version range and fixed builds
MEDIUM Severity downgrade based on the renderer-compromise prerequisite
MEDIUM Absence of public PoC or active exploitation evidence

Why this verdict

  • Major downward adjustment: requires prior renderer compromise — attacker position is not simple unauthenticated remote web access in practice; it implies a separate exploit, prior code execution, or a private chain already in hand.
  • Population narrowing — Chrome is ubiquitous, but this step is only reachable against endpoints that are both unpatched *and* hit by a working renderer exploit, which cuts real exposed population far below the raw install base.
  • Threat intel is quiet — no KEV entry, no public PoC identified, and EPSS is extremely low, all of which argue against treating this as a top-of-queue emergency on its own.
  • Still not low — if chained, a sandbox escape is exactly the kind of primitive that turns a browser foothold into material endpoint risk, so it remains worth patching in normal browser maintenance.

Why not higher?

Because the attack path starts with a hidden tax: the adversary already needs renderer compromise. That means this CVE is not a one-bug internet-to-host event, not broadly reachable from the open web by commodity actors, and not supported by current exploitation evidence. In enterprise prioritization terms, those are compounding friction points that pull it out of the HIGH bucket.

Why not lower?

Because browser sandbox escapes are strategically valuable even when chain-dependent. Chrome is widely deployed, the vulnerable component sits in an attacker-influenced content path, and a successful escape can materially raise impact from a contained browser exploit to a real endpoint incident. That keeps it above backlog-only hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Validate that enterprise policy is actually pulling Chrome to 149.0.7827.53/.54+ and that stalled update cohorts are remediated. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but for browsers you should close drift in the next routine endpoint maintenance cycle rather than letting exceptions linger.
  2. Harden browser isolation for high-risk users — Use remote/browser isolation or stronger application containment for admins, developers, executives, and users handling sensitive SaaS sessions. This reduces the value of renderer-to-host exploit chaining while patching rolls through; with MEDIUM, use it as targeted risk reduction rather than an emergency fleet-wide control.
  3. Watch for crash and exploit-protection telemetry — Collect Chrome crash spikes, EDR exploit-mitigation alerts, and suspicious browser-child-process behavior on endpoints that have not yet updated. This does not replace patching, but it helps you spot whether a chain is being tested before you complete normal remediation.
  4. Reduce privileged browsing — Keep users out of local admin and separate admin workflows from daily browsing. Even if a browser chain lands, lower endpoint privilege reduces post-escape payoff; enforce during ordinary endpoint hardening work, not as a special emergency motion.
What doesn't work
  • A perimeter WAF does not help because this is client-side browser exploitation, not a server-side HTTP parsing issue in your environment.
  • Relying on AC:H in the CVSS vector as a comfort blanket does not help; the real problem is chainability, and sophisticated actors can still use private exploit chains.
  • Version-only scanning by itself does not tell you which users are actually high risk; it finds drift, but it does not expose whether the separate renderer-exploit prerequisite exists.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory agent. Invoke with python3 chrome_cve_2026_10960_check.py on Windows, macOS, or Linux; no admin rights are required for basic local checks, though reading some install locations may work better with standard software-inventory permissions.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-10960 Chrome version check
# Outputs 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
from pathlib import Path

TARGET_LINUX = (149, 0, 7827, 53)
TARGET_WIN_MAC = (149, 0, 7827, 53)  # .53/.54 are fixed; >= .53 is treated as patched


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 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 '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def find_windows_version():
    candidates = [
        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'),
    ]

    # Try registry first
    reg_queries = [
        ["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKCU\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
    ]
    for cmd in reg_queries:
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            return v, 'registry'

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

    return None, ''


def find_macos_version():
    app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    if os.path.exists(app):
        out = run_cmd([app, '--version'])
        v = parse_version(out)
        if v:
            return v, app

    plist = '/Applications/Google Chrome.app/Contents/Info.plist'
    if os.path.exists(plist):
        out = run_cmd(['/usr/bin/defaults', 'read', plist, 'CFBundleShortVersionString'])
        v = parse_version(out)
        if v:
            return v, plist

    return None, ''


def find_linux_version():
    bins = [
        'google-chrome',
        'google-chrome-stable',
        'chromium',
        'chromium-browser',
    ]
    for b in bins:
        path = shutil.which(b)
        if path:
            out = run_cmd([path, '--version'])
            v = parse_version(out)
            if v:
                return v, path

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

    return None, ''


def main():
    system = platform.system().lower()

    if 'windows' in system:
        version, source = find_windows_version()
        threshold = TARGET_WIN_MAC
    elif 'darwin' in system or 'mac' in system:
        version, source = find_macos_version()
        threshold = TARGET_WIN_MAC
    elif 'linux' in system:
        version, source = find_linux_version()
        threshold = TARGET_LINUX
    else:
        print('UNKNOWN: unsupported platform')
        sys.exit(2)

    if not version:
        print('UNKNOWN: Google Chrome version not found')
        sys.exit(2)

    if version_ge(version, threshold):
        print(f'PATCHED: detected version {".".join(map(str, version))} from {source}')
        sys.exit(0)
    else:
        print(f'VULNERABLE: detected version {".".join(map(str, version))} from {source}')
        sys.exit(1)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a normal browser patching item, not an all-hands fire drill. Because the reassessed verdict is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window for the actual patch, but in practice you should push Chrome 149.0.7827.53/.54+ through your next managed browser rollout and clean up update drift promptly. There is no active-exploitation override here, so do not preemptively disrupt operations with emergency controls; instead, validate auto-update health now, identify lagging cohorts, and complete patch adoption within the noisgate remediation SLA window while prioritizing high-risk user groups first.

Sources

  1. Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
  2. NVD entry for CVE-2026-10960
  3. Chromium issue 507258786 (restricted bug reference)
  4. Canadian Centre for Cyber Security advisory AV26-544
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS overview
  7. Shodan Internet Exposure Observatory
  8. Censys Search product 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.