← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11198 · 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 booby-trapped video, not a worm ripping through your estate

CVE-2026-11198 is an input-validation flaw in Chrome's Codecs component that affects Chrome builds prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows and macOS. The public description says a remote attacker could *potentially* achieve a sandbox escape through a crafted video file, which makes this a client-side content-parsing issue rather than an always-reachable service flaw.

The supplied CRITICAL 9.6 label overstates operational risk for most enterprises. In the real world this requires a user to render attacker-controlled media, hits one endpoint at a time, has no KEV listing, no public exploit chain, a very low supplied EPSS, and even Chrome's own CNA text marks it as Chromium security severity: Medium.

"Looks nasty on paper, but this is a user-driven browser client bug with no exploitation signal and real chain friction"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a crafted video payload

The attacker needs to get a target to open a malicious site or file that causes Chrome to parse attacker-controlled video content. The practical delivery tooling is ordinary web content, malvertising, or phishing attachments rather than a public exploit kit tied to this CVE.
Conditions required:
  • Target uses Chrome below 149.0.7827.53/.54
  • Target renders attacker-controlled video content in Chrome
  • Attacker can reach the user through the web, chat, or email
Where this breaks in practice:
  • Requires user interaction (UI:R), so this is not self-propagating
  • Email filtering, Safe Browsing, URL filtering, and user habits cut delivery volume
  • Many enterprise users are already on auto-updating browser channels
Detection/coverage: Proxy, SWG, EDR browser telemetry, and phishing gateways can usually see the delivery stage, but they will not reliably fingerprint this specific CVE without a known signature.
STEP 02

Trigger the codec parser flaw

Chrome's media stack processes the crafted file and reaches the vulnerable validation path in Codecs. This is where a proof-of-concept would need tight format control and version specificity to turn a parsing weakness into reliable exploitation.
Conditions required:
  • Exact vulnerable build is present
  • The malicious media exercises the affected codec path
  • Chrome parses the content rather than blocking or failing early
Where this breaks in practice:
  • No public PoC was found
  • Codec bugs are often format- and platform-sensitive
  • Crash-to-code-exec reliability is usually much lower than CVSS implies
Detection/coverage: Crash telemetry, browser hangs, and abnormal renderer/media process terminations may surface in EDR or Chrome crash reporting, but scanner coverage for exploitability is limited.
STEP 03

Cross the sandbox boundary

The description says the attacker could *potentially perform a sandbox escape*, which is the critical impact amplifier if it works. But sandbox escapes are exactly where real-world exploit development gets expensive: the attacker needs a stable path from malformed media handling to execution beyond Chrome's containment controls.
Conditions required:
  • The vulnerability is actually reachable to a privileged boundary crossing
  • Exploit survives modern Chrome mitigations and OS hardening
  • Attacker has a working post-trigger chain, not just a crash
Where this breaks in practice:
  • This is the highest-friction stage in the chain
  • Chrome's own advisory categorizes this CVE as Medium, which is a strong downward signal
  • No in-the-wild evidence was found
Detection/coverage: EDR may catch child-process abuse, memory corruption aftermath, or unusual browser-to-OS behavior, but direct pre-exploitation detection is weak.
STEP 04

Operate on the compromised endpoint

If the sandbox escape succeeds, the attacker can run follow-on code in the context they achieved and pursue data theft, credential access, or local persistence on that host. The blast radius is endpoint-by-endpoint, not an estate-wide unauthenticated server compromise.
Conditions required:
  • Successful sandbox escape
  • Useful post-exploitation payload
  • Insufficient EDR or application control on the endpoint
Where this breaks in practice:
  • EDR, ASR, application control, and egress controls often break post-exploitation
  • Impact is bounded to the targeted user/device unless chained further
  • No evidence this CVE currently supports broad opportunistic campaigns
Detection/coverage: Post-exploitation is where defenders have the best chance: EDR, process ancestry, network egress alerts, and credential-access detections all apply.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found, and not listed in CISA KEV as of 2026-06-06.
PoC availabilityNo public GitHub or researcher PoC located for CVE-2026-11198; bug details remain restricted in Chromium issue 504395300.
EPSSSupplied EPSS is 0.0009 (~0.09%), which is very low and consistent with weak near-term exploitation pressure.
KEV statusNo KEV listing found; no date added or federal due date applies.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H describes a severe client-side outcome on paper, but UI:R means the attack still depends on tricking users into rendering attacker content.
Affected versionsChrome before 149.0.7827.53 per the CVE record; Google's stable release notes map that to 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS.
Fixed versionsFixed in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS. Early stable for Windows/macOS began on 2026-05-29; broad stable promotion followed on 2026-06-02.
Disclosure timelineCVE record published 2026-06-04; Chrome stable desktop release containing the fix was posted 2026-06-02.
Reporter / advisory severityChrome's stable advisory says Google reported it on 2026-04-20, and the CNA text exposed via Vulnerability-Lookup labels it Chromium security severity: Medium.
Exposure realityInternet scanner data like Shodan/Censys is not very meaningful here because this is a desktop browser client bug, not a remotely discoverable service. Exposure should be measured from fleet inventory, and Chrome's huge install base still matters: StatCounter shows Chrome around 68% worldwide browser share.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.2/10)

The single decisive factor is chain friction at the sandbox-escape stage combined with required user interaction. This is a broad client population, but there is no exploitation evidence, no public PoC, and the impact lands one workstation at a time rather than exposing a server-side estate-wide entry point.

HIGH Version range and fixed release mapping
MEDIUM Assessment that practical exploitation risk is below the supplied `9.6` label
LOW Exact exploit reliability, because public bug details are restricted

Why this verdict

  • Down from 9.6 because UI:R is real friction — the attacker needs a user to open or render malicious media, which pushes this out of wormable/server-exposed territory and into phishing or web-lure tradecraft.
  • Down again because the hardest step is the one that matters — turning a codec parsing bug into a reliable *sandbox escape* is materially harder than crashing a browser process, and there is no public chain showing that reliability.
  • Down again because exploitation pressure is weak — no KEV entry, no public PoC found, and the supplied EPSS is only 0.0009.
  • Not lower because Chrome is everywhere — Chrome has enormous enterprise reach, so even a client-side bug with friction can still matter if your patch hygiene is poor.
  • Not lower because the stated outcome is serious if achieved — a successful sandbox escape on a user workstation is a meaningful endpoint compromise, just not the same operational class as an unauthenticated internet-facing server RCE.

Why not higher?

There is no evidence this is being exploited in the wild, no public weaponization, and the chain requires user-driven content rendering. Most importantly, the vulnerability's scariest word is *potentially*: the public description does not demonstrate a mature, reliable exploit path through Chrome's sandbox protections.

Why not lower?

This still sits in a massively deployed browser, and the affected component processes untrusted content from the internet by design. If an exploit chain emerges, the path to endpoint compromise is straightforward enough that this cannot be treated as mere backlog hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Verify browser auto-update health — Confirm managed Chrome update channels, version reporting, and stalled-updater exceptions across the fleet so vulnerable endpoints do not linger. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control should be validated in the next regular endpoint engineering cycle because browsers age badly.
  2. Reduce risky content delivery — Tighten web filtering, attachment detonation, and download reputation checks for unsolicited media payloads and newly registered lure domains. There is no mitigation SLA for MEDIUM, but use the normal remediation window to shrink exposure while patched browser versions propagate.
  3. Harden endpoint post-exploitation controls — Ensure EDR prevention, application control, and browser child-process restrictions are enabled so a successful browser escape does not become durable host compromise. For MEDIUM, fold this into standard hardening work rather than an emergency change.
  4. Inventory vulnerable versions — Use endpoint management, software inventory, or the verification script below to identify Chrome builds older than 149.0.7827.53/.54. With no mitigation SLA for MEDIUM, the priority is clean scoping and steady patch closure inside the remediation window.
What doesn't work
  • A perimeter WAF does nothing useful here because the target is a browser client rendering attacker content, not your web app.
  • Network vulnerability scanning is weak coverage for this class because it cannot reliably tell whether a user's browser process is parsing a vulnerable codec path.
  • Relying on users won't open weird files is not a control; drive-by pages, embedded media, and ad traffic make that assumption brittle.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management tool. Invoke it as python3 chrome_cve_2026_11198_check.py on Linux/macOS or py chrome_cve_2026_11198_check.py on Windows; no admin rights are normally required, though broader path/registry visibility on locked-down systems may help.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11198 Chrome version check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1=vulnerable, 0=patched, 2=unknown

import os
import platform
import re
import shutil
import subprocess
import sys

TARGET = (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 version_lt(a, b):
    return a < b


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=5)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def candidate_paths():
    system = platform.system().lower()
    paths = []

    if system == 'windows':
        local = os.environ.get('LOCALAPPDATA', '')
        program_files = os.environ.get('ProgramFiles', '')
        program_files_x86 = os.environ.get('ProgramFiles(x86)', '')
        paths.extend([
            os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(program_files, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(program_files_x86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        ])
    elif system == 'darwin':
        paths.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ])
    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
            p = shutil.which(name)
            if p:
                paths.append(p)
        paths.extend([
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/opt/google/chrome/chrome',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser',
        ])

    seen = []
    for p in paths:
        if p and p not in seen:
            seen.append(p)
    return seen


def get_windows_registry_version():
    try:
        import winreg
    except Exception:
        return None

    keys = [
        r'SOFTWARE\Google\Chrome\BLBeacon',
        r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
    ]
    hives = []
    try:
        hives.append(winreg.HKEY_CURRENT_USER)
        hives.append(winreg.HKEY_LOCAL_MACHINE)
    except Exception:
        return None

    for hive in hives:
        for key in keys:
            try:
                with winreg.OpenKey(hive, key) as k:
                    value, _ = winreg.QueryValueEx(k, 'version')
                    ver = parse_version(str(value))
                    if ver:
                        return ver
            except Exception:
                continue
    return None


def detect_versions():
    found = []

    if platform.system().lower() == 'windows':
        reg_ver = get_windows_registry_version()
        if reg_ver:
            found.append(('registry', reg_ver))

    for path in candidate_paths():
        if not os.path.exists(path):
            continue
        out = run_cmd([path, '--version'])
        ver = parse_version(out)
        if ver:
            found.append((path, ver))

    return found


def main():
    found = detect_versions()
    if not found:
        print('UNKNOWN: Google Chrome version could not be determined on this host')
        sys.exit(2)

    lowest = min(ver for _, ver in found)
    details = ', '.join([f'{src}={".".join(map(str, ver))}' for src, ver in found])

    if version_lt(lowest, TARGET):
        print(f'VULNERABLE: found Chrome version(s) below 149.0.7827.53 ({details})')
        sys.exit(1)
    else:
        print(f'PATCHED: found Chrome version(s) at or above 149.0.7827.53 ({details})')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: scope Chrome versions across the workstation fleet, confirm auto-update health, and roll patched builds through your normal browser maintenance process rather than declaring an emergency. Because this is MEDIUM and there is no KEV or active exploitation signal, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; your noisgate remediation SLA is <= 365 days, though a sensible enterprise should close a browser client bug like this in the next regular endpoint/browser release cycle, not at day 364.

Sources

  1. Chrome Releases - Stable Channel Update for Desktop
  2. Chrome Releases - Early Stable Update for Desktop
  3. Vulnerability-Lookup - CVE-2026-11198
  4. Chromium issue 504395300
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS API documentation
  7. StatCounter browser market share worldwide
  8. Canadian Centre for Cyber Security advisory AV26-544
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.