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

Insufficient policy enforcement in CSS in Google Chrome prior to 149

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

This is a peephole in a skyscraper, not an unlocked front door

CVE-2026-11288 is a Chrome CSS policy-enforcement flaw that lets a remote attacker leak cross-origin data after luring a victim to a malicious page. The affected desktop branch is Chrome prior to 149.0.7827.53 on Linux and prior to the 149.0.7827.53/.54 desktop release train on Windows/macOS; downstream Chromium builds were fixed by vendors as they rebased to Chromium 149 or backported the change.

The vendor's 6.5 MEDIUM is close to reality, and if anything a touch generous for enterprise prioritization. Yes, Chrome is everywhere, but this is still a *browse-to-exploit confidentiality leak* with no public exploitation, no KEV listing, very low EPSS, and no direct host compromise path; those frictions keep it out of the urgent patch-now bucket.

"Broadly deployed browser bug, but it still needs a user to browse attacker content and only buys data leakage, not code exec."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get the victim onto attacker-controlled web content

The attacker needs a user to render a malicious HTML/CSS payload in a vulnerable Chrome build. In practice the weaponized tool is just a crafted web page delivered by phishing, ad traffic, SEO poisoning, or a compromised site; there is no network service to hit directly.
Conditions required:
  • Victim runs Chrome/Chromium build older than 149.0.7827.53
  • User visits or is redirected to attacker-controlled content
  • Enterprise policy does not block the destination before page load
Where this breaks in practice:
  • Requires *user interaction*; this is not a wormable socket bug
  • Email gateways, DNS filtering, SWG, browser isolation, and Safe Browsing can kill delivery before exploit code runs
  • Kiosk and managed enterprise browsers often auto-update quickly
Detection/coverage: Vulnerability scanners usually infer exposure from installed browser version, not from active exploit telemetry. Detection of the initial step is better in proxy, DNS, email, and browser telemetry than in host vuln scans.
STEP 02

Trigger the CSS policy bypass primitive

Once loaded, the malicious page abuses the CSS enforcement flaw to make protected cross-origin data observable when it should stay segregated by browser policy. The weaponized component is the browser rendering engine itself; exploitation is client-side and happens inside the browsing session.
Conditions required:
  • Vulnerable CSS code path is reachable in the victim's browser
  • Attacker can induce the relevant DOM/CSS state transitions
  • Targeted cross-origin resource is present or can be induced in-session
Where this breaks in practice:
  • Browser exploit reliability for logic bugs is usually lower than server-side request/response bugs
  • Site isolation, process isolation, and modern browser hardening reduce easy chaining
  • Exact exploit details were not public in the sources reviewed
Detection/coverage: EDR rarely sees this as a discrete signature unless the payload is already known. Web telemetry may only show a normal page load plus follow-on exfil traffic.
STEP 03

Read cross-origin information the page should not see

If the primitive is reliable, the attacker can infer or directly access sensitive cross-origin data in the browser context. The likely prize is session-adjacent content, page state, or resource-derived secrets—not host-level execution.
Conditions required:
  • Victim is simultaneously authenticated to an interesting target origin or handling sensitive content
  • The data sought is reachable through the flawed rendering/policy path
  • Attacker's page can serialize the leaked information
Where this breaks in practice:
  • Blast radius is bounded to what the user has in-browser at that moment
  • Many enterprise apps add their own anti-automation, CSRF, CSP, and re-auth friction
  • This is confidentiality impact only in the supplied CVSS model; no integrity or availability win
Detection/coverage: DLP, browser telemetry, and abnormal outbound beaconing may catch the exfil phase. Host-centric tools usually have poor visibility into cross-origin read primitives.
STEP 04

Exfiltrate via normal web channels

The stolen data can be sent out through standard browser mechanisms such as fetch, sendBeacon, image requests, or form posts. The weaponized tool here is ordinary browser networking, which blends into typical web traffic unless egress controls are strong.
Conditions required:
  • Outbound HTTPS/DNS to attacker infrastructure is allowed
  • The page remains open long enough to send results
Where this breaks in practice:
  • Egress filtering, proxy auth, TLS inspection, DLP, and browser isolation can break or expose exfil
  • The value of the leak depends heavily on what the victim already had open and authenticated
Detection/coverage: Proxy, SWG, CASB, and DNS logs are your best shot. Vulnerability scanners do not validate this step; they only flag version exposure.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence found of active exploitation in the sources reviewed; not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC or exploit repo was identified during source review. Chrome bug details are typically restricted until the fix is widely deployed.
EPSSUser-supplied EPSS is 0.00036, which is effectively floor-level exploitation probability; percentile was not confirmed from a primary FIRST lookup in the reviewed sources.
KEV statusNo KEV listing as of the review date; no CISA due date applies.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — remote delivery and no auth help the attacker, but *user interaction required* and *confidentiality-only impact* materially cap urgency.
Affected versionsGoogle Chrome/Chromium builds before 149.0.7827.53 are affected; desktop release notes reference Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54 rollout.
Fixed versionsUpgrade to Chrome 149.0.7827.53 or later; openSUSE backported the fix in its Chromium 149 security update, which explicitly lists CVE-2026-11288: Policy bypass in CSS.
Exposure realityThis is not internet-scannable like a server CVE; Shodan/Censys/FOFA style exposure counts are largely irrelevant. Exposure is driven by endpoint inventory, and Chrome still holds roughly 71%+ worldwide desktop browser share, so vulnerable population can be large even though direct reachability is low.
Disclosure datePublicly disclosed on 2026-06-05 in the Chrome/NVD ecosystem.
ReporterThe public advisory reviewed does not name an external researcher for this specific CVE; attribution may remain withheld while bug details stay restricted.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.8/10)

The decisive drag on severity is that this is a *client-side browse-to-exploit data leak*, not an unauthenticated server-side foothold or a host-compromise primitive. Chrome's huge footprint keeps it relevant, but the required user visit plus the absence of exploitation evidence and the confidentiality-only outcome keep it in MEDIUM.

HIGH Version-based exposure and fixed-version mapping
MEDIUM Reassessed severity relative to vendor CVSS
MEDIUM No-known-exploitation judgment based on reviewed public sources

Why this verdict

  • User interaction required: the attacker needs the victim to render a malicious page, which means email security, SWG, DNS filtering, Safe Browsing, and browser isolation all get a chance to stop it before the bug matters.
  • No foothold amplification: there is no authentication bypass, no sandbox escape, and no code execution in the supplied impact model. That sharply limits blast radius compared with Chrome bugs that become immediate endpoint compromise.
  • Detection and control surface is decent: enterprises already have multiple layers that watch or broker web navigation. This is much easier to blunt operationally than a quietly exploitable service daemon.
  • Threat signal is weak: no KEV, no public PoC found, and an EPSS near zero are all downward pressure from the vendor baseline.
  • Population is still large: Chrome is ubiquitous on enterprise endpoints, so even a non-server browser bug can affect a lot of users. That is why this stays MEDIUM instead of sliding to LOW.

Why not higher?

There is no evidence here of active exploitation, no public exploit chain, and no direct system compromise outcome. The attack starts with getting a user to browse attacker content and ends with data leakage inside the browser session, which is a much narrower operational threat than RCE or sandbox escape.

Why not lower?

The browser is one of the most ubiquitous enterprise applications you run, and the flaw affects same-origin protections that defenders rely on for containment. If an attacker can reliably weaponize the primitive, confidential data in active browser sessions is in play at scale, so dismissing it as backlog-only would be too casual.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Use your endpoint manager or browser enterprise policy to ensure Chrome update services are enabled and stale installations are reported. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browsers are low-friction to update, so fold stragglers into the next managed browser wave rather than waiting.
  2. Tighten web delivery controls — Keep Secure Web Gateway, DNS filtering, and Safe Browsing enforcement on for unmanaged browsing destinations, especially on user workstations that handle SaaS admin sessions. This is a useful compensating layer while remediation proceeds; for MEDIUM, there is no separate mitigation deadline, only the remediation window.
  3. Use browser isolation for high-risk users — Place finance, identity-admin, helpdesk, and exec browsing behind remote browser isolation where feasible, because this class of flaw depends on the local browser processing attacker content. That meaningfully reduces exploitability without touching the vulnerable endpoint directly; with MEDIUM, deploy where practical rather than under an accelerated SLA.
  4. Hunt for stale Chrome rings — Query your fleet for versions below 149.0.7827.53, including VDI gold images, kiosk builds, and Chromium-based repacks that lag upstream. This is the real exposure set; scanners that only sample a subset of laptops will miss long-tail drift.
What doesn't work
  • Perimeter firewalling doesn't solve a browse-to-exploit client bug; the attacker comes in through normal HTTPS to a page the user loads.
  • MFA is not a control for the vulnerability itself. It may reduce downstream account abuse, but it does not prevent the browser from leaking cross-origin data once the malicious page runs.
  • Server-side WAF rules are mostly irrelevant because the weakness lives in the client browser's CSS policy handling, not in your internet-facing web stack.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory agent. Invoke it with python3 check_chrome_cve_2026_11288.py or point at a specific binary with python3 check_chrome_cve_2026_11288.py --path "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"; no admin rights are required unless your EDR restricts process execution from managed scripts.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11288.py
# Determine whether the locally installed Chrome/Chromium build is vulnerable to CVE-2026-11288.
# Outputs one of: VULNERABLE, PATCHED, UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

THRESHOLD = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')


def parse_version(text):
    m = VERSION_RE.search(text or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def get_candidate_paths(user_path=None):
    candidates = []
    if user_path:
        candidates.append(user_path)

    system = platform.system()

    if system == 'Windows':
        local = os.environ.get('LOCALAPPDATA', '')
        pf = os.environ.get('ProgramFiles', '')
        pfx86 = os.environ.get('ProgramFiles(x86)', '')
        candidates.extend([
            os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(pfx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(pf, 'Chromium', 'Application', 'chrome.exe'),
            os.path.join(pfx86, 'Chromium', 'Application', 'chrome.exe'),
        ])
    elif system == 'Darwin':
        candidates.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            '/Applications/Chromium.app/Contents/MacOS/Chromium',
        ])
    else:
        candidates.extend([
            shutil.which('google-chrome') or '',
            shutil.which('google-chrome-stable') or '',
            shutil.which('chromium') or '',
            shutil.which('chromium-browser') or '',
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser',
            '/snap/bin/chromium',
        ])

    seen = set()
    ordered = []
    for p in candidates:
        if p and p not in seen:
            seen.add(p)
            ordered.append(p)
    return ordered


def run_version(binary):
    try:
        cp = subprocess.run([binary, '--version'], capture_output=True, text=True, timeout=10)
        out = (cp.stdout or '') + ' ' + (cp.stderr or '')
        ver = parse_version(out)
        return ver, out.strip()
    except Exception:
        return None, ''


def compare(v1, v2):
    return (v1 > v2) - (v1 < v2)


def main():
    user_path = None
    args = sys.argv[1:]
    if '--path' in args:
        idx = args.index('--path')
        try:
            user_path = args[idx + 1]
        except IndexError:
            print('UNKNOWN - --path provided without a value')
            sys.exit(2)

    for binary in get_candidate_paths(user_path):
        if not os.path.exists(binary):
            continue
        version, raw = run_version(binary)
        if not version:
            continue

        version_str = '.'.join(str(x) for x in version)
        threshold_str = '.'.join(str(x) for x in THRESHOLD)

        if compare(version, THRESHOLD) < 0:
            print(f'VULNERABLE - {binary} version {version_str} is older than fixed threshold {threshold_str}')
            sys.exit(1)
        else:
            print(f'PATCHED - {binary} version {version_str} is at or above fixed threshold {threshold_str}')
            sys.exit(0)

    print('UNKNOWN - Chrome/Chromium binary not found or version could not be parsed')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning, pull an endpoint inventory for Chrome/Chromium builds below 149.0.7827.53, with special attention to VDI images, kiosks, and unmanaged long-tail laptops. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but because browser updates are cheap and centrally manageable, you should still roll this into your next browser update ring and clean up stragglers well before the noisgate remediation SLA of ≤365 days rather than treating it as indefinite backlog.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2026 advisory URL referenced by NVD/CVE mirrors)
  2. Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54 rollout)
  3. CISA Known Exploited Vulnerabilities Catalog
  4. FIRST EPSS project
  5. openSUSE chromium security update listing CVE-2026-11288
  6. StatCounter desktop browser market share worldwide
  7. CVE Alert feed entry for CVE-2026-11288
  8. CVE.report mirror entry for Chrome 149 CVEs and advisory references
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.