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

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

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

This is a fake badge printer that only matters after the intruder is already inside the building

CVE-2026-11237 is an input-validation bug in Chrome's Media component affecting desktop Chrome versions before 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS. The documented impact is UI spoofing via a crafted HTML page, but only for an attacker who has already compromised the renderer process. That means this bug is not the initial break-in; it is a follow-on primitive inside an exploit chain.

The published 8.3/HIGH CVSS overstates real enterprise risk when this CVE is triaged as a standalone patching decision. Google/Chromium itself labels it Low, and that matches reality better: the hardest part of the attack is not this bug, it is first landing renderer compromise at all. For a fleet manager, this is a chain component with limited blast radius and no current evidence of KEV listing, public weaponization, or broad opportunistic abuse.

"This is a post-compromise UI spoofing primitive, not a frontline enterprise fire."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land renderer compromise first

The attacker needs a separate bug or chain that gives code execution or equivalent control inside Chrome's renderer process. In practice this means a prior browser exploit, malicious extension, or another already-successful client-side compromise. CVE-2026-11237 does not provide that initial foothold.
Conditions required:
  • Attacker can get the victim to browse attacker-controlled content
  • A separate renderer compromise exists and works against the target build
  • The target is running a vulnerable Chrome version before 149.0.7827.53
Where this breaks in practice:
  • This is a post-initial-compromise prerequisite
  • Modern Chrome sandboxing and exploit mitigations raise the cost of renderer compromise
  • No public PoC or named exploit chain is currently evident for this CVE itself
Detection/coverage: Version scanners can flag vulnerable Chrome builds, but scanners do not prove the renderer-compromise prerequisite is present.
STEP 02

Trigger the Media validation flaw

With renderer control already in hand, the attacker serves a crafted HTML page that exercises the vulnerable Media code path. The resulting effect is UI spoofing rather than sandbox escape or native code execution. Think of it as lying to the user through the browser chrome or trust cues, not taking over the endpoint directly.
Conditions required:
  • Renderer is already attacker-controlled
  • Victim reaches attacker-controlled HTML content
  • Relevant Media path is reachable in the victim's browsing session
Where this breaks in practice:
  • Impact is limited to spoofing, not direct OS-level execution
  • Browser UI conditions can be inconsistent across platforms and user workflows
  • Enterprise users behind hardened browser policies may see less useful spoofable surface
Detection/coverage: Network or mail security tools will not reliably see this. Browser telemetry may only show a page visit unless endpoint/browser instrumentation is very detailed.
STEP 03

Abuse spoofed UI for follow-on action

The practical value is in convincing the user to trust a fake prompt, fake origin indicator, or fake workflow and then hand over credentials, approve an action, or disclose data. This is a social-engineering amplifier attached to an already-compromised renderer. MFA, conditional access, and user verification flows can still break the payoff even if spoofing succeeds.
Conditions required:
  • User must interact with the spoofed content
  • The spoofed workflow must resemble something the user recognizes and trusts
  • Downstream controls must fail or be bypassable
Where this breaks in practice:
  • Requires user action
  • MFA and phishing-resistant auth reduce credential-harvest value
  • Blast radius is generally the current user session, not fleet-wide takeover
Detection/coverage: Very weak direct detection. Success is more likely found through identity telemetry, suspicious consent events, abnormal prompts, or user-reported phishing behavior.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo authoritative evidence found of active exploitation as of 2026-06-06; not present in the CISA KEV catalog.
Public PoC availabilityNo credible public PoC or named exploit repo surfaced in primary-source review. Current evidence points to no public weaponization.
EPSS0.00066 (~0.066% exploitation probability). That is consistent with a narrow, chain-dependent client-side bug rather than a spray-and-pray internet target.
KEV statusNot KEV-listed; no CISA date-added entry.
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H from CISA-ADP/NVD. In practice, the decisive hidden assumption is the description's extra prerequisite: attacker already compromised the renderer.
Affected versionsGoogle Chrome desktop before 149.0.7827.53; release notes indicate Chrome 149 stable on Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54.
Fixed versionsPatch level is Chrome 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS. For enterprise packaging, consume vendor-backed distro/browser channel backports where applicable rather than chasing source-level assumptions.
Exposure profileThis is a client-side browser issue, not an internet-exposed service. Shodan/Censys/FOFA-style host counts are largely not meaningful here; exposure is your managed Chrome fleet population, especially users allowed broad web access.
Disclosure datePublicly disclosed 2026-06-04; included in Chrome 149 stable channel update published 2026-06-02.
Reporting researcher / orgReported by Google on 2026-03-26 according to the Chrome release notes; no external researcher credit shown.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.8/10)

The single biggest severity reducer is the attacker-position requirement: this bug only matters after the renderer is already compromised. That makes it a narrow post-compromise spoofing primitive with limited standalone enterprise impact, despite the scary-looking CVSS math.

HIGH Attack-path prerequisite analysis
MEDIUM Population-wide enterprise risk estimate

Why this verdict

  • Requires prior compromise: the attacker must already control the renderer process, which means the chain has already cleared the hardest barrier.
  • User action still needed: the documented impact is UI spoofing, so the attacker still needs the victim to trust and act on the fake interface.
  • No current exploitation signal: no KEV entry, no authoritative in-the-wild reporting, and no credible public PoC materially reduce urgency.
  • Blast radius is narrow: this is session/user-context abuse, not a one-bug remote endpoint takeover.
  • Vendor score is inflated by generic impact assumptions: the CISA-ADP CVSS reflects theoretical downstream compromise, but not the real-world narrowing created by the renderer-compromise prerequisite.

Why not higher?

If this bug enabled initial renderer compromise, sandbox escape, or native code execution by itself, the score would jump fast. But it does none of those things on its own; it is a helper bug in a chain and the chain dependency crushes standalone severity.

Why not lower?

It is still a real security bug in a massively deployed browser, and UI spoofing inside a compromised renderer can meaningfully aid phishing, consent fraud, or trust-boundary confusion. Dismissing it entirely would ignore its value as a chain amplifier against high-value users.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure Chrome stable updates are forced through enterprise policy and your software deployment tooling. For a LOW noisgate verdict there is no SLA beyond backlog hygiene, but this is low-friction hygiene you should still complete in the normal browser-update cycle.
  2. Harden identity prompts — Use phishing-resistant MFA, conditional access, and verified login flows so spoofed browser UI has less payoff. This reduces the value of the attacker's likely endgame even if the spoofing step lands.
  3. Restrict untrusted extensions — Limit extension installation to approved publishers and enforce enterprise allowlists. While not a direct fix, it reduces alternate paths to renderer abuse and lowers chain-building options.
  4. Instrument browser version compliance — Use EDR, RMM, or asset inventory to continuously verify Chrome versions across the fleet and catch stragglers. For a LOW item, treat this as standard hygiene and close gaps during the next normal remediation wave.
What doesn't work
  • A WAF does not help; this is a client-side browser flaw triggered in the user's browser, not a server-side request filter problem.
  • Perimeter vulnerability scanning of internet-facing assets misses the real population because Chrome is endpoint software, not a remotely fingerprintable exposed service.
  • Password rotation alone is weak compensation; the more relevant protection is phishing-resistant MFA and session/consent monitoring.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or push it through your EDR/RMM script runner. Invoke it as python3 check_cve_2026_11237.py on Linux/macOS or py check_cve_2026_11237.py on Windows; no admin rights are required for basic detection because it only reads installed Chrome version data.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11237.py
# Detects whether installed Google Chrome is vulnerable to CVE-2026-11237
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

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

FIXED = (149, 0, 7827, 53)


def parse_version(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_ver(a, b):
    return (a > b) - (a < b)


def get_cmd_output(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        if p.returncode == 0:
            return (p.stdout or p.stderr).strip()
    except Exception:
        pass
    return None


def find_versions_windows():
    versions = []
    reg_paths = [
        r'HKLM\\SOFTWARE\\Google\\Chrome\\BLBeacon',
        r'HKLM\\SOFTWARE\\WOW6432Node\\Google\\Chrome\\BLBeacon',
        r'HKCU\\SOFTWARE\\Google\\Chrome\\BLBeacon',
    ]
    for reg in reg_paths:
        out = get_cmd_output(['reg', 'query', reg, '/v', 'version'])
        if out:
            v = parse_version(out)
            if v:
                versions.append((reg, v))
    exe_candidates = [
        os.path.join(os.environ.get('ProgramFiles', r'C:\\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
    ]
    for exe in exe_candidates:
        if exe and os.path.exists(exe):
            out = get_cmd_output([exe, '--version'])
            v = parse_version(out)
            if v:
                versions.append((exe, v))
    return versions


def find_versions_macos():
    versions = []
    app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    if os.path.exists(app):
        out = get_cmd_output([app, '--version'])
        v = parse_version(out)
        if v:
            versions.append((app, v))
    mdls_target = '/Applications/Google Chrome.app'
    if os.path.exists(mdls_target):
        out = get_cmd_output(['mdls', '-name', 'kMDItemVersion', mdls_target])
        v = parse_version(out)
        if v:
            versions.append((mdls_target, v))
    return versions


def find_versions_linux():
    versions = []
    candidates = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    for name in candidates:
        path = shutil.which(name)
        if path:
            out = get_cmd_output([path, '--version'])
            v = parse_version(out)
            if v:
                versions.append((path, v))
    return versions


def main():
    system = platform.system().lower()
    if 'windows' in system:
        found = find_versions_windows()
    elif 'darwin' in system:
        found = find_versions_macos()
    else:
        found = find_versions_linux()

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

    unique = []
    seen = set()
    for src, ver in found:
        key = (src, ver)
        if key not in seen:
            seen.add(key)
            unique.append((src, ver))

    vulnerable = []
    patched = []
    for src, ver in unique:
        if cmp_ver(ver, FIXED) < 0:
            vulnerable.append((src, ver))
        else:
            patched.append((src, ver))

    if vulnerable:
        details = '; '.join([f'{src}={".".join(map(str, ver))}' for src, ver in vulnerable])
        print(f'VULNERABLE - Chrome version(s) below 149.0.7827.53 detected: {details}')
        sys.exit(1)

    details = '; '.join([f'{src}={".".join(map(str, ver))}' for src, ver in patched])
    print(f'PATCHED - Chrome version(s) at or above 149.0.7827.53 detected: {details}')
    sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: treat this as backlog hygiene, not an interrupt-driven fire. There is no noisgate mitigation SLA for a LOW verdict, so do not burn emergency change windows on it; instead, verify fleet browser version coverage, let normal browser controls and identity hardening stand, and complete patching under the noisgate remediation SLA as ordinary hygiene in your next standard browser update cycle.

Sources

  1. NVD CVE-2026-11237
  2. Chrome Stable Channel Update for Desktop (June 2, 2026)
  3. Chromium issue 496617698
  4. Chrome Early Stable Update for Desktop (May 29, 2026)
  5. Chromium severity guidelines
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS API documentation
  8. SynScan CVE-2026-11237 summary
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.