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

Inappropriate implementation in CSS in Google Chrome prior to 149

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

This is a peephole cut into the same-origin wall, not a wrecking ball through it

CVE-2026-11156 is a Chrome CSS implementation flaw that lets a remote attacker use a crafted web page to leak *some* cross-origin data from the victim's browser. The affected range is Google Chrome versions *before* 149.0.7827.53; Google pushed the fix in the 149.0.7827.53/.54 early-stable train for desktop, with broader stable rollout following Chrome's normal channel cadence.

Google's MEDIUM 4.3 rating is technically fair in a vacuum, but for enterprise patch triage it's still a *downward-pressure* case: the attacker needs user interaction, the impact is confidentiality-only, the leak is constrained to what can be inferred from browser-side rendering behavior, and this is not an internet-facing server foothold. On a 10,000-host patch board, this is a browser hygiene item, not a fire drill.

"Real bug, but it needs a click and only buys a narrow browser-side data leak."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land the victim on a malicious page

The attacker hosts or injects a crafted HTML/CSS page and gets the target to render it in vulnerable Chrome. The practical weapon is just a custom web payload; no exploit kit is required from the public record so far.
Conditions required:
  • Victim uses Chrome older than 149.0.7827.53
  • Victim must browse to attacker-controlled content
  • Enterprise controls do not block the destination or embedded content
Where this breaks in practice:
  • Requires *user interaction* (UI:R), so this is not wormable or self-propagating
  • Web filtering, email link protection, browser isolation, and user behavior all cut reach
  • A lot of enterprise Chrome fleets auto-update quickly, shrinking the vulnerable population
Detection/coverage: Network scanners will miss this; coverage comes from browser version inventory, EDR/browser telemetry, URL filtering logs, and secure web gateway click data.
STEP 02

Probe cross-origin state via CSS side effects

Once rendered, the page abuses the CSS flaw to infer cross-origin data that should stay isolated by the browser's same-origin protections. Think side-channel-style leakage or state probing, not arbitrary read of a target site's full DOM or filesystem.
Conditions required:
  • Targeted cross-origin application data must be present in the victim browser context
  • The leak primitive must line up with attacker-controlled markup and the target's page structure/state
  • Victim may need to be logged into the target site for meaningful data exposure
Where this breaks in practice:
  • Leakability is highly data- and layout-dependent; many targets won't yield useful secrets
  • Modern browser protections and app-side anti-framing/content policies reduce reliability
  • This is typically low-bandwidth extraction, not bulk data theft
Detection/coverage: No commodity scanner will validate exploitability here. Detection is mostly indirect: anomalous browsing to suspicious domains, browser crash/diagnostic telemetry if the bug misbehaves, or threat hunting for lure infrastructure.
STEP 03

Exfiltrate inferred bits back to attacker infrastructure

The malicious page sends the inferred values out over normal browser egress such as fetch/XHR/beacon requests. Impact stays inside the victim's browser session and whatever data the CSS primitive can actually reveal.
Conditions required:
  • Attacker-controlled egress endpoint reachable from the browser
  • Useful information successfully inferred in prior step
Where this breaks in practice:
  • DLP, proxy inspection, and DNS/HTTP egress controls can catch or block sloppy exfil
  • Because the leak is narrow, attackers may need repeated probes to get meaningful value
Detection/coverage: Look for suspicious outbound requests from user browsers to low-reputation domains after lure clicks. Again, version inventory is your primary exposure signal.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in the checked sources, and it is not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC or GitHub exploit repo was located in a quick source check. The Chromium bug reference exists, but details are still restricted, which is normal shortly after release.
EPSS0.00035 (~0.035% probability over 30 days based on the user-supplied score), which is *very low* and consistent with a low-priority browser-side leak rather than a high-demand intrusion primitive.
KEV statusNot present in the CISA Known Exploited Vulnerabilities Catalog.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N = remote, no auth, but click-required and confidentiality-only with low impact.
Affected versionsGoogle Chrome prior to 149.0.7827.53 according to the CVE/NVD record.
Fixed versionsFixed in the Chrome 149.0.7827.53/.54 desktop early-stable train; use your platform's vendor-packaged build at or above that level.
Exposure realityThis is a client-side browser issue, not a listening service. Shodan/Censys/FOFA-style internet exposure counts are basically irrelevant; your true exposure is endpoint browser version sprawl plus user web activity.
Scanner coverageStrong for version-based asset inventory, weak for exploitability validation. Network vuln scanners will largely miss this unless they ingest software inventory from the endpoint.
DisclosureDisclosed 2026-06-04. Public bug metadata is still sparse; the referenced Chromium issue is present but not openly detailed yet.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.9/10)

The decisive factor is reachability friction: the attacker must get a user onto a malicious page and then successfully turn a CSS leak primitive into useful cross-origin disclosure. That makes this a post-click browser privacy failure with narrow blast radius, not a general-purpose enterprise compromise path.

HIGH The flaw is confidentiality-only and requires user interaction
MEDIUM Real-world exploitability is lower than the vendor baseline because useful leakage is target- and state-dependent
MEDIUM No active exploitation evidence in checked public sources

Why this verdict

  • UI:R is real downward pressure: the attacker needs the victim to render attacker-controlled web content, which implies phishing, malvertising, or a compromised site instead of direct unauthenticated exploitation.
  • Browser-context only: even if successful, this leaks cross-origin data from the victim's session; it does not deliver code execution, persistence, lateral movement, or server-side footholds by itself.
  • Low-value exploit market signal: the supplied EPSS is extremely low and CISA KEV is empty, which lines up with a bug that defenders should patch but not overreact to.
  • Exposure is broad but shallow: Chrome is everywhere, but this kind of flaw is gated by click-through, target app state, and whether the page can extract anything useful at all.

Why not higher?

There is no evidence here of code execution, sandbox escape, privilege escalation, or active exploitation. The attack also compounds multiple frictions: user interaction, victim browser context, and the need for a leakable cross-origin target state, which sharply reduces operational usefulness compared with real intrusion-grade Chrome bugs.

Why not lower?

It is still a remotely triggerable browser flaw in a massively deployed product, and a successful attacker may be able to steal sensitive cross-origin state from authenticated sessions. If your users spend all day in high-value SaaS apps, even a low-bandwidth leak can matter, so this should not be ignored outright.

05 · Compensating Control

What to do — in priority order.

  1. Enforce auto-update — Make sure managed Chrome updates are not deferred unnecessarily and that endpoints converge on 149.0.7827.53+ through your normal browser maintenance motion. For a LOW verdict there is no fixed mitigation SLA; treat this as backlog hygiene and complete it in the normal browser update cycle.
  2. Block stale browser versions — Use device compliance, EDR posture, NAC, or browser management to identify and restrict endpoints that remain on old Chrome builds. This cuts the long tail of exception machines that keep client-side browser bugs alive.
  3. Harden web delivery paths — Keep secure web gateway, DNS filtering, and email link protection tuned for lure domains and newly registered infrastructure. These controls matter here because the exploit path starts with getting the user to a hostile page.
  4. Isolate high-risk browsing — For privileged admins and users handling sensitive internal apps, use browser isolation or stricter outbound browsing policy where practical. It reduces the value of browser-side data leak bugs even when patching lags.
What doesn't work
  • Perimeter vulnerability scanning doesn't help much because the flaw is in an endpoint browser, not a remotely fingerprintable service.
  • MFA does not stop the bug itself; if the victim already has an authenticated session in the browser, the leak can target that existing state.
  • Server patching on internal web apps is not a direct fix because the vulnerable component is the client browser.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory/remote execution tooling. Invoke it with python3 check_chrome_cve_2026_11156.py on Windows, macOS, or Linux; standard user rights are usually enough because it only reads version info from common install paths and the Windows registry.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11156.py
# Detects whether installed Google Chrome is older than 149.0.7827.53
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

THRESHOLD = (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:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def windows_version():
    cmds = [
        ['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 cmds:
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            return v, out
    return None, ''


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


def linux_version():
    candidates = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chrome', '--version'],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            return v, out
    return None, ''


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


def main():
    system = platform.system().lower()
    version = None
    raw = ''

    if 'windows' in system:
        version, raw = windows_version()
    elif 'darwin' in system:
        version, raw = mac_version()
    elif 'linux' in system:
        version, raw = linux_version()
    else:
        print('UNKNOWN')
        print('Unsupported platform: {}'.format(platform.system()))
        sys.exit(2)

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

    if compare_versions(version, THRESHOLD) < 0:
        print('VULNERABLE')
        print('Detected Chrome version {} from: {}'.format('.'.join(map(str, version)), raw))
        sys.exit(1)
    else:
        print('PATCHED')
        print('Detected Chrome version {} from: {}'.format('.'.join(map(str, version)), raw))
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: pull a version inventory for Chrome and clean up the outliers, but do not let this jump ahead of exploitable RCE, auth bypass, or KEV-listed work. For a LOW verdict there is no noisgate mitigation SLA and no remediation emergency; treat it as backlog hygiene, use your regular browser governance to converge on 149.0.7827.53+, and finish patching under the noisgate remediation SLA expectation for LOW issues: no fixed deadline, just close it in the normal maintenance stream rather than letting stale browser versions linger indefinitely.

Sources

  1. NVD CVE-2026-11156
  2. Chrome Releases: Early Stable Update for Desktop
  3. Chromium issue 501810226
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS data stats
  6. FIRST EPSS FAQ
  7. FIRST EPSS API documentation
  8. Chrome Enterprise release notes / previous release notes
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.