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

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

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

This is a cracked interior door, not the front gate

CVE-2026-11121 is an input-validation flaw in Chrome's Skia graphics component that affects Google Chrome versions earlier than 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS. Per the published CNA description, the bug lets an attacker who has already compromised the renderer process leak cross-origin data through a crafted HTML page.

Reality check: this is not an initial-access browser RCE, and it is not a sandbox escape. The decisive friction is the prerequisite attacker position: they must already own the renderer, which makes this a second-stage chain component with narrow standalone utility. Google's own Chromium severity label of *Medium* matches the operational reality.

"Post-renderer compromise only; useful in exploit chains, weak as a standalone patch fire drill"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker-controlled content

The attacker needs the target to render a crafted page that exercises a vulnerable Skia code path. On its own, that is not enough to exploit this CVE; it only sets up the later data-leak stage.
Conditions required:
  • Chrome version is earlier than 149.0.7827.53
  • Target user browses attacker-controlled or attacker-influenced content
  • The page reaches the affected Skia path
Where this breaks in practice:
  • This CVE does not produce impact from page load alone
  • Many enterprise users never hit the exact rendering path needed
  • Web filtering and URL isolation can reduce delivery opportunities
Detection/coverage: Weak standalone telemetry. Web proxy, DNS, and browser history may show delivery, but scanners will not reliably prove reachability of the vulnerable code path.
STEP 02

Compromise the renderer first with a separate bug or malicious extension

This CVE explicitly assumes the renderer process is already compromised. In practice that means chaining from another browser memory-corruption flaw, a malicious extension, or an equivalent same-host foothold that can act inside the renderer sandbox.
Conditions required:
  • Attacker has a working renderer-compromise primitive outside this CVE
  • That primitive survives modern Chrome hardening long enough to run follow-on logic
Where this breaks in practice:
  • This is the biggest downward pressure on severity: the attacker is already past the initial exploit hurdle
  • EDR, browser exploit mitigations, extension allowlisting, and rapid Chrome auto-update all raise the bar
Detection/coverage: Coverage is mostly on the precursor step, not this CVE. EDR, browser crash telemetry, and extension-control alerts are more likely to catch the chain here than network scanners.
STEP 03

Abuse Skia validation to break cross-origin isolation

With renderer control in hand, the attacker abuses the Skia validation weakness to read data that should remain isolated across origins. That shifts impact from 'attacker can run inside one renderer' to 'attacker can steal data from other web contexts visible to that browser session.'
Conditions required:
  • Renderer is already under attacker influence
  • Victim has interesting authenticated web content loaded or reachable in-session
Where this breaks in practice:
  • Impact is confined to data leakage, not arbitrary native code execution
  • The attacker still needs valuable browser-resident material to steal
Detection/coverage: No reliable signature-based scanner coverage. Detection is mainly behavioral: suspicious browser child-process activity, abnormal extension behavior, or session-token abuse after theft.
STEP 04

Exfiltrate session data and pivot to apps

The likely endgame is theft of cross-origin data such as authenticated content, tokens, or sensitive page material, followed by reuse against SaaS or internal apps. For enterprise defenders, the business risk comes from account/session abuse rather than host takeover.
Conditions required:
  • The browser session contains reusable secrets or sensitive data
  • Exfiltrated material is valuable enough to support follow-on access
Where this breaks in practice:
  • Many modern apps bind sessions to device posture, IP reputation, or re-auth triggers
  • Short-lived tokens and strong conditional access reduce replay value
Detection/coverage: Identity telemetry is your best shot: impossible travel, unusual token reuse, SaaS anomaly detection, and conditional-access failures after browser compromise.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence found that CVE-2026-11121 is in CISA KEV, and I found no vendor statement or credible reporting indicating active exploitation as of 2026-06-05.
Public PoC availabilityNo public exploit or proof-of-concept was found in the authoritative/vendor-facing sources reviewed. That fits the bug shape: it is a chain component, not a clean standalone exploit target.
EPSSUser-supplied EPSS is 0.00047, which is extremely low. I could not confirm an authoritative percentile from the sources reviewed, but this score is consistent with low standalone exploitation interest.
KEV statusNot KEV-listed. That matters because Chrome issues that become operational fire drills usually show either KEV inclusion, vendor zero-day language, or both.
Vendor severity baselineThere is no vendor CVSS score and no official CVSS vector published, but Chrome's release notes and CNA text label the flaw as Chromium security severity: Medium.
Affected versionsGoogle's CNA record marks Chrome < 149.0.7827.53 as affected. The desktop stable note shows 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS.
Fixed versionsUpgrade desktop Chrome to Linux 149.0.7827.53 or Windows/macOS 149.0.7827.53/.54 or later. This is a browser-binary fix; there is no distro-specific backport evidence in the sources reviewed.
Exposure and scanning realityInternet-wide exposure tools like *Shodan*, *Censys*, and *FOFA* are mostly irrelevant here because this is a client-side browser flaw, not a remotely enumerable network service. Your real exposure count is your managed endpoint fleet running pre-149 Chrome.
Disclosure and reporterThe CVE record was published on 2026-06-04. Google's stable release notes list the issue as reported by Google on 2026-04-10, issue 501483855.
Chain contextThis shipped in a Chrome 149 batch containing many Critical and High bugs, including initial-compromise browser flaws. That context matters: CVE-2026-11121 is more useful as a follow-on privacy bypass after another bug lands.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.7/10)

The single biggest scoring driver is the prerequisite attacker position: the adversary must already have compromised the renderer process before this bug does anything useful. That makes it a post-compromise browser-chain primitive with real confidentiality impact, but poor standalone exploit value and limited urgency compared with first-stage Chrome RCEs or sandbox escapes.

HIGH Affected/fixed version range and disclosure metadata
HIGH Assessment that this is post-initial-compromise rather than initial access
MEDIUM Operational severity score without an official CVSS baseline

Why this verdict

  • Major downward adjustment: requires a compromised renderer first. That implies the attacker is already past the hard part of the browser kill chain.
  • Impact is confidentiality only. The published description is cross-origin data leakage, not code execution, privilege escalation, or sandbox escape.
  • Exposure is broad but not directly reachable. Chrome is everywhere, but the reachable population for this exact bug is only the subset where an attacker can first land a renderer compromise and then chain successfully.

Why not higher?

It is not a higher-severity issue because it does not provide initial code execution, does not escape the sandbox, and does not require defenders to assume internet-reachable unauthenticated exploitation. The attacker position requirement compounds sharply: internal-to-browser post-compromise plus a data-theft-only outcome is not a patch-everything-now event.

Why not lower?

It is not lower because cross-origin data leakage inside a live enterprise browser session can still expose SSO-backed application data, tokens, and sensitive content. Chrome is widely deployed, and post-renderer chain components matter when paired with other browser bugs or malicious extensions.

05 · Compensating Control

What to do — in priority order.

  1. Enforce extension allowlisting — Reduce one of the realistic renderer-compromise on-ramps by blocking unapproved extensions and auditing sideloading. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, so do this in your normal browser-hardening cycle rather than as an emergency action.
  2. Prioritize risky user cohorts — Move admins, developers, finance, and high-travel users to the fixed Chrome build first because they are the most likely to combine browser exposure with valuable authenticated SaaS sessions. Again, no mitigation SLA — go straight to the 365-day remediation window, but use risk-based rings to close the gap faster.
  3. Watch for browser-to-identity pivoting — Tune detections for suspicious token reuse, abnormal SaaS access, and browser-driven child-process anomalies, because the likely enterprise pain is session theft after a chained exploit. For MEDIUM, treat this as monitoring hardening during the remediation campaign, not a stop-the-line control.
What doesn't work
  • Perimeter vulnerability scanning does not help much because there is no server-side listening service to fingerprint; this is an endpoint browser-version problem.
  • WAF rules do not materially stop a local browser renderer already under attacker influence from abusing the client-side flaw.
  • Password resets alone miss the likely impact path if the attacker steals active session data or cookies rather than credentials.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR live-response/remote script runner. Invoke it with python3 check_cve_2026_11121.py on macOS/Linux or py check_cve_2026_11121.py on Windows; no admin rights are usually required, but the script needs permission to read common install paths and execute the browser binary with --version.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11121.py
# Determine whether installed Chrome/Chromium builds are vulnerable to CVE-2026-11121.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path

FIXED = (149, 0, 7827, 53)

CANDIDATES = {
    'Windows': [
        r'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Users\\%USERNAME%\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Program Files\\Chromium\\Application\\chrome.exe',
        r'C:\\Program Files (x86)\\Chromium\\Application\\chrome.exe'
    ],
    'Darwin': [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        '/Applications/Chromium.app/Contents/MacOS/Chromium'
    ],
    'Linux': [
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/opt/google/chrome/chrome',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
        '/snap/bin/chromium'
    ]
}

EXE_FALLBACKS = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']


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 expand_win(path):
    return os.path.expandvars(path.replace('%USERNAME%', os.environ.get('USERNAME', '')))


def collect_paths():
    system = platform.system()
    paths = []
    for p in CANDIDATES.get(system, []):
        paths.append(expand_win(p) if system == 'Windows' else p)
    for name in EXE_FALLBACKS:
        resolved = shutil.which(name)
        if resolved:
            paths.append(resolved)
    seen = []
    for p in paths:
        if p and p not in seen:
            seen.append(p)
    return seen


def get_version(binary):
    try:
        proc = subprocess.run([binary, '--version'], capture_output=True, text=True, timeout=8)
        output = (proc.stdout or '') + ' ' + (proc.stderr or '')
        return parse_version(output)
    except Exception:
        return None


def main():
    found = []
    vulnerable = []
    patched = []

    for path in collect_paths():
        if os.path.isfile(path) or shutil.which(path):
            ver = get_version(path)
            if ver:
                found.append((path, ver))
                if version_lt(ver, FIXED):
                    vulnerable.append((path, ver))
                else:
                    patched.append((path, ver))

    if vulnerable:
        print('VULNERABLE')
        for path, ver in vulnerable:
            print(f'{path} -> {".".join(map(str, ver))} < {".".join(map(str, FIXED))}')
        sys.exit(1)

    if patched:
        print('PATCHED')
        for path, ver in patched:
            print(f'{path} -> {".".join(map(str, ver))}')
        sys.exit(0)

    print('UNKNOWN')
    print('No runnable Chrome/Chromium binary found in common locations, or version parsing failed.')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning: treat this as a browser-fleet hygiene item, not a sev-1 fire. Because this is MEDIUM and there is no KEV or active exploitation evidence, the noisgate mitigation SLA is no mitigation SLA — go straight to the 365-day remediation window; in practice, push Chrome to 149.0.7827.53/.54 or later in your next managed browser rollout, verify stragglers with endpoint inventory this month, and close the campaign well inside the noisgate remediation SLA of ≤365 days.

Sources

  1. Google Chrome stable desktop release 149
  2. Google Chrome early stable desktop release 149.0.7827.53/.54
  3. Vulnerability Lookup entry/search result containing CVE-2026-11121 CNA text
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS data and field definitions
  6. Chromium security page
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.