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.
4 steps from start to impact.
Get the victim onto attacker-controlled web content
- 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
- 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
Trigger the CSS policy bypass primitive
- 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
- 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
Read cross-origin information the page should not see
- 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
- 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
Exfiltrate via normal web channels
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.- Outbound HTTPS/DNS to attacker infrastructure is allowed
- The page remains open long enough to send results
- 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
The supporting signals.
| In-the-wild status | No evidence found of active exploitation in the sources reviewed; not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC or exploit repo was identified during source review. Chrome bug details are typically restricted until the fix is widely deployed. |
| EPSS | User-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 status | No KEV listing as of the review date; no CISA due date applies. |
| CVSS vector | CVSS: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 versions | Google 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 versions | Upgrade 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 reality | This 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 date | Publicly disclosed on 2026-06-05 in the Chrome/NVD ecosystem. |
| Reporter | The public advisory reviewed does not name an external researcher for this specific CVE; attribution may remain withheld while bug details stay restricted. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
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
- Google Chrome Releases - Stable Channel Update for Desktop (June 2026 advisory URL referenced by NVD/CVE mirrors)
- Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54 rollout)
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS project
- openSUSE chromium security update listing CVE-2026-11288
- StatCounter desktop browser market share worldwide
- CVE Alert feed entry for CVE-2026-11288
- CVE.report mirror entry for Chrome 149 CVEs and advisory references
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.