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

Insufficient validation of untrusted input in Codecs in Google Chrome prior to 149

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

This is a weak hinge on an inner door, not a broken front gate

CVE-2026-10981 is an input-validation bug in Chrome's Codecs component. It affects Chrome versions before 149.0.7827.53 on Linux and the 149.0.7827.53/.54 stable train on Windows/macOS; the practical abuse case is a crafted video payload that helps an attacker cross Chrome's sandbox boundary.

paragraph 2: Google's MEDIUM 6.5 label is defensible in a lab, but it overstates the standalone operational risk for enterprise patch queues. The decisive real-world friction is that this is a *chain* bug: the attacker typically needs a separate renderer foothold plus user interaction with attacker-controlled media, and there is no KEV listing, no public exploit, and a very low EPSS signal.

"Useful only as a chain component: this is not your initial-access fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land attacker-controlled media

Tooling is a custom lure page or delivered video file; no public exploit kit is associated with this CVE. The victim has to browse to, open, or otherwise render attacker-supplied media so Chrome's codec stack processes it.
Conditions required:
  • Target is running a vulnerable Chrome build before 149.0.7827.53
  • Attacker can get the user to load attacker-controlled video content
Where this breaks in practice:
  • User interaction is required
  • Enterprise URL filtering, attachment detonation, and browser isolation reduce reach
  • This is a client-side bug, so internet-wide exposure scanners do not help attackers find targets
Detection/coverage: Version scanners can identify vulnerable Chrome builds; content-based detection is weak unless the delivery URL/file is already known malicious.
STEP 02

Gain a renderer foothold first

Operationally, this bug matters when paired with a separate renderer compromise or equivalent same-process foothold. That makes the attacker position *post-initial-browser-compromise*, not truly clean-sheet unauthenticated remote, even if the CVSS vector starts at AV:N/PR:N.
Conditions required:
  • A second bug or exploit primitive provides renderer-level code execution or control
  • The chain can be synchronized with media decoding
Where this breaks in practice:
  • This prerequisite compounds difficulty sharply
  • Modern browser hardening and exploit mitigations can break the first-stage foothold
  • No public PoC for this exact CVE lowers opportunistic attacker uptake
Detection/coverage: This step is usually inferred from browser crashes, exploit telemetry, or EDR/browser exploit protection rather than from a signature for CVE-2026-10981 itself.
STEP 03

Abuse codec validation to cross the sandbox

With the right preconditions, the crafted video exercises the codec validation flaw and attempts a sandbox escape. If successful, the attacker moves from a constrained browser context toward the broader browser or OS user context.
Conditions required:
  • The vulnerable codec path is reachable on the target platform
  • Attacker-controlled media is decoded in the expected way
  • The exploit chain survives Chrome's mitigation stack
Where this breaks in practice:
  • Bug details remain restricted, which usually means reproduction reliability is not commodity yet
  • Sandbox-escape chains are brittle across versions, platforms, and mitigations
Detection/coverage: Expect poor preventive signature coverage; detection is more likely via crash clusters, anomalous browser child processes, or broker/IPC abuse seen by EDR.
STEP 04

Operate outside the renderer cage

A successful chain can expose local browser data, session material, or enable follow-on payload delivery with the user's rights. The blast radius is the endpoint and user session, but only after the attacker already cleared multiple earlier hurdles.
Conditions required:
  • Sandbox escape succeeds
  • Post-escape payload execution is not blocked by endpoint controls
Where this breaks in practice:
  • EDR, application control, and local privilege boundaries still limit post-escape actions
  • The impact is serious *if chained*, but narrow as a standalone issue
Detection/coverage: EDR should see suspicious process spawn, memory-injection patterns, or abnormal access to credential stores and browser data paths.
03 · Intelligence Metadata

The supporting signals.

Identity checkThe user-supplied advisory details line up with Google's 2026-06-02 Chrome 149 stable bulletin entry for CVE-2026-10981 in Codecs; keep it distinct from similarly worded Chrome codec CVEs published the same week.
In-the-wild statusNo public statement from Google or CISA says this CVE is exploited in the wild as of 2026-06-05.
PoC availabilityNo public PoC or GitHub exploit repo found. The linked Chromium issue 513762354 is still restricted, which usually suppresses copy-paste exploitation.
EPSS0.00047 (~0.047%) from the supplied intel; that is a very low exploitation-probability signal.
KEV statusNot KEV-listed as of 2026-06-05; there is no CISA due date pressure.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N = remote delivery with user interaction, confidentiality impact only, and no direct integrity/availability claim. In practice, the chain requirement makes the raw vector look more reachable than it really is.
Affected versionsChrome before 149.0.7827.53 on Linux; Google and downstream advisories describe the desktop stable train as 149.0.7827.53/.54 for Windows/macOS.
Fixed versionsMove to Chrome 149.0.7827.53 or later on Linux and the patched 149.0.7827.53/.54 desktop stable builds on Windows/macOS. For enterprises, the key control is relaunch compliance so the browser actually leaves the vulnerable build.
Exposure realityThis is *not* Shodan/Censys/FOFA-style exposure. It is a client-side browser flaw, so external attack-surface platforms won't enumerate it; exposure tracks installed Chrome population, and StatCounter showed Chrome around 70.25% of worldwide desktop browser share in May 2026.
Disclosure and reporterReported by Google on 2026-05-16 in the Chrome bulletin; CVE record/public disclosure landed on 2026-06-04.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (4.3/10)

The single biggest reason this lands in LOW is that it behaves like a *sandbox-escape chain component*, not a clean initial-access bug. Without evidence of active exploitation or a public exploit, the renderer-compromise prerequisite crushes the real-world reachable population.

HIGH Affected-version and fixed-version mapping from Google's June 2, 2026 Chrome 149 bulletin
MEDIUM Standalone exploitability assessment, because the Chromium bug details remain restricted

Why this verdict

  • Baseline starts at vendor MEDIUM 6.5 because Chrome is ubiquitous and codec bugs live on a hostile content path
  • Renderer-compromise prerequisite drags it down hard: the attacker position is effectively *post-initial-browser-compromise*, which means this is not a front-door exploit for most enterprises
  • User interaction narrows reach further: the victim still has to render attacker-controlled media, so email/web filtering and user behavior matter
  • No exploitation heat: no KEV, no public PoC, and a supplied EPSS of 0.00047 all argue against urgent opportunistic abuse
  • Broad install base keeps it above IGNORE: Chrome is everywhere, and sandbox escapes remain strategically valuable when paired with another browser bug

Why not higher?

If this were a standalone renderer RCE with reliable remote trigger, the score would jump immediately. But a bug that is mainly valuable *after* another browser compromise is already a narrowed, multi-stage path, and that compounding friction matters more than the theoretical sandbox-escape impact.

Why not lower?

It is still a browser security-boundary issue in one of the most deployed client applications in the enterprise. If an attacker already has a renderer foothold, this kind of bug can turn a contained browser exploit into meaningful endpoint access, so it is not something to dismiss outright.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update and relaunch — Make sure managed Chrome channels actually move off vulnerable builds and that users relaunch so the patched binary is loaded. For a LOW noisgate verdict there is no mitigation SLA; treat this as backlog hygiene and verify compliance on the next standard browser-maintenance cycle.
  2. Prefer browser isolation for high-risk users — Use remote/browser isolation or hardened VDI for executives, admins, and click-prone populations that routinely touch untrusted media. For a LOW verdict there is no mitigation SLA, but this is a sensible standing control rather than a CVE-specific emergency move.
  3. Block unmanaged and portable browsers — The real risk in large fleets is drift: unmanaged Chrome installs, stale local profiles, and portable copies that miss enterprise update policy. For a LOW verdict there is no mitigation SLA, so fold this into normal endpoint hygiene and software control.
  4. Watch for browser exploit telemetry — Tune EDR and browser-protection telemetry for Chrome crash spikes, suspicious child processes, and abnormal access to browser data stores. There is no mitigation SLA for LOW, but telemetry gives you early warning if this bug starts appearing in chains.
What doesn't work
  • A WAF does not help; this is a client-side media parsing issue inside the browser, not a server-side HTTP attack surface.
  • Perimeter vulnerability scanning will not find exposure; Shodan-style discovery is irrelevant because the risk is installed browser version, not an open service.
  • MFA does not stop exploitation of the browser process itself; it may reduce downstream account abuse, but it does not break the codec-trigger path.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/EDR script runner. Invoke it with python3 chrome_cve_2026_10981_check.py; it needs only standard user rights and prints VULNERABLE, PATCHED, or UNKNOWN based on the installed Google Chrome version.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check local Google Chrome version against the fixed build for CVE-2026-10981
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

FIXED = (149, 0, 7827, 53)


def parse_version(text):
    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:
        out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True)
        return out.strip()
    except Exception:
        return None


def get_windows_version():
    reg_paths = [
        ["reg", "query", r"HKLM\SOFTWARE\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKCU\SOFTWARE\Google\Chrome\BLBeacon", "/v", "version"],
    ]
    for cmd in reg_paths:
        out = run_cmd(cmd)
        if out:
            v = parse_version(out)
            if v:
                return v, out
    default_paths = [
        r"C:\Program Files\Google\Chrome\Application\chrome.exe",
        r"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe",
    ]
    for p in default_paths:
        if os.path.exists(p):
            ps = [
                "powershell",
                "-NoProfile",
                "-Command",
                f"(Get-Item '{p}').VersionInfo.ProductVersion"
            ]
            out = run_cmd(ps)
            if out:
                v = parse_version(out)
                if v:
                    return v, out
    return None, None


def get_macos_version():
    candidates = [
        "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
        os.path.expanduser("~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
    ]
    for c in candidates:
        if os.path.exists(c):
            out = run_cmd([c, "--version"])
            if out:
                v = parse_version(out)
                if v:
                    return v, out
    return None, None


def get_linux_version():
    candidates = [
        ["google-chrome", "--version"],
        ["google-chrome-stable", "--version"],
        ["/usr/bin/google-chrome", "--version"],
        ["/usr/bin/google-chrome-stable", "--version"],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        if out:
            v = parse_version(out)
            if v:
                return v, out
    return None, None


def main():
    system = platform.system()
    if system == "Windows":
        version, raw = get_windows_version()
    elif system == "Darwin":
        version, raw = get_macos_version()
    elif system == "Linux":
        version, raw = get_linux_version()
    else:
        print(f"UNKNOWN: unsupported platform '{system}'")
        sys.exit(2)

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

    version_str = ".".join(str(x) for x in version)
    fixed_str = ".".join(str(x) for x in FIXED)

    if version < FIXED:
        print(f"VULNERABLE: installed Chrome {version_str} is older than fixed {fixed_str}")
        sys.exit(1)
    else:
        print(f"PATCHED: installed Chrome {version_str} is at or above fixed {fixed_str}")
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, do not let this jump ahead of remotely reachable initial-access bugs. Verify Chrome auto-update and relaunch compliance, identify endpoints still below 149.0.7827.53/.54, and clear them in your normal browser-maintenance workflow; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene, so fold the vendor patch into the next standard browser cycle and document any unmanaged-browser exceptions.

Sources

  1. Google Chrome Stable Channel Update for Desktop (Chrome 149)
  2. Google Chrome Early Stable Update for Desktop
  3. Chromium issue 513762354
  4. Canadian Centre for Cyber Security advisory AV26-544
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS model documentation
  7. StatCounter desktop browser market share worldwide
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.