01 · The Real Story
Like peeking through a keyhole instead of kicking down the door
CVE-2026-11155 is a Chrome desktop CSS policy-enforcement flaw that can let a malicious website infer or leak *some* cross-origin data when a user visits attacker-controlled content. The affected population is Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS; Google shipped the fix in the June 2, 2026 stable release.
Google's MEDIUM label is basically right, and if anything slightly generous for enterprise patch triage. Yes, Chrome is everywhere and the attacker needs no auth, but this still requires user interaction, only yields confidentiality leakage rather than code execution, and lives inside a browser defense stack that already narrows what can be stolen and how reliably it can be exfiltrated.
"This is a browser privacy bug, not an enterprise fire drill: broad reach, but low-impact leakage and heavy user-dependence."
02 · The Attack Path
4 steps from start to impact.
STEP 01
Lure the victim into attacker HTML
The attacker hosts or injects a crafted page that exercises the vulnerable CSS behavior. Delivery is the usual web path: phishing link, ad-tech placement, compromised site, or chat-delivered URL. Weaponized tooling here is just a malicious webpage plus standard traffic-distribution infrastructure; no exploit kit evidence is public.
Conditions required:
- Victim must browse to attacker-controlled or attacker-influenced content
- Target must be using vulnerable Chrome build(s)
Where this breaks in practice:
- Requires user interaction (
UI:R), which cuts off fully wormable or opportunistic mass exploitation - Enterprise URL filtering, Safe Browsing, email security, and browser isolation can block the visit before exploit logic runs
Detection/coverage: Traditional network vuln scanners will miss this. Detection is mainly browser version inventory, web proxy telemetry, clickstream/email-link telemetry, and secure web gateway blocking of the delivery URL.
STEP 02
Abuse CSS policy enforcement edge case
Once the page is rendered, the exploit abuses a CSS implementation/policy-enforcement mistake to test or infer cross-origin state. Google has not published bug mechanics, so the exact primitive is withheld; the likely class is CSS-driven state probing or rendering side effects that expose limited cross-origin information. That is an inference from the description, not a published exploit recipe.
Conditions required:
- The targeted browser engine path must process the crafted CSS/HTML sequence
- The victim must load relevant cross-origin resources or already have useful browser state
Where this breaks in practice:
- Modern browser isolation features sharply constrain direct cross-origin reads
- Exploit reliability may vary by page structure, login state, cookies, and resource behavior
Detection/coverage: No dependable signature-based detection is public. Browser crash telemetry is unlikely to help because this is an info leak, not a memory-corruption crash class.
STEP 03
Extract low-grade cross-origin signals
The attacker can then recover small pieces of sensitive state or content-adjacent information from another origin. Think presence/absence tests, coarse data inference, or limited content leakage rather than arbitrary account takeover or system compromise. The weaponized output is browser-side JavaScript collecting the leaked signals and posting them back to attacker infrastructure.
Conditions required:
- Victim must have interesting authenticated sessions or accessible target content in-browser
- The leaked data must be useful enough to operationalize
Where this breaks in practice:
- Confidentiality impact is rated low, and that matches the likely output quality
- No integrity or availability impact means no direct foothold, persistence, or host compromise
Detection/coverage: DLP and CASB generally will not see subtle browser-side inference. EDR will usually see nothing beyond normal browser execution.
STEP 04
Operationalize the leaked data
Any stolen signal still has to matter: session-adjacent metadata, hidden token fragments, cross-site state, or other low-volume data that helps a later phishing or account-targeting step. This is where the chain usually dies in real enterprises, because limited leakage is not the same thing as remote code execution or a server-side breach.
Conditions required:
- The leaked material must map to a real follow-on attack objective
- The attacker must have a second-stage plan to exploit whatever was inferred
Where this breaks in practice:
- This is post-click *and* post-inference; each extra dependency compounds downward pressure on severity
- Most enterprises care more about browser RCEs and zero-click chains than low-yield cross-origin leaks
Detection/coverage: You may only see downstream abuse, not the original leak. Focus on suspicious identity events, reused tokens, or follow-on phishing against the same users.
03 · Intelligence Metadata
The supporting signals.
| In-the-wild status | No public active-exploitation statement from Google, no CISA KEV listing observed, and no public incident writeups tied to this CVE as of 2026-06-05. |
|---|---|
| PoC availability | No public PoC or exploit repo located. The Chromium issue exists at 501801823 but details are not public. |
| EPSS | 0.00035 from the user-supplied intel block; that is *extremely low*. Exact percentile was not independently pulled, but this score sits in the very low tail of current FIRST data. |
| KEV status | Not KEV-listed in the CISA KEV catalog as checked on 2026-06-05. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N = remote over the web, no auth, but user interaction required and confidentiality-only low impact. |
| Affected versions | Chrome desktop before 149.0.7827.53; Google release notes specify fixed stable builds 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/Mac. |
| Fixed versions | Upgrade to Chrome 149 stable or later: 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac). Enterprise-managed channels should verify policy has not pinned older builds. |
| Scanning / exposure reality | This is not an internet-exposed service problem, so Shodan/Censys/FOFA are basically irrelevant. Exposure is your managed browser fleet and unmanaged stragglers, which means EDR/software inventory is the right visibility layer. |
| Disclosure timing | Chrome/CVE publication landed on 2026-06-04; Google shipped the stable desktop fix on 2026-06-02. |
| Reporter | Google release notes attribute the bug as reported by Google on 2026-04-12, not an external researcher. |
04 · The Call
noisgate verdict.
Final Verdict
↓ DOWNGRADED to LOW (3.6/10)
The decisive factor is that this bug is a user-driven browser confidentiality leak, not a foothold or code-execution path. Even though Chrome is ubiquitous, the real-world blast radius is throttled by required victim browsing, limited impact, and the need for useful cross-origin state to already exist in the browser.
HIGH Attack preconditions and exposure model
MEDIUM Exact leakage mechanics and exploit reliability because Chromium bug details remain restricted
Why this verdict
- Downward adjustment: user interaction required — the attacker has to get a user onto a malicious page, which makes this materially less urgent than zero-click or passive network-reachable issues.
- Downward adjustment: confidentiality-only, low impact — the published vector says
C:L/I:N/A:N; there is no host compromise, persistence, privilege gain, or service disruption in the base case. - Downward adjustment: not an edge service — this is not an externally scannable server flaw hitting a few crown-jewel apps; it is a browser-side bug whose exploitation success varies with user behavior and session state.
- Downward adjustment: no exploitation signal — no KEV listing, no vendor warning of active exploitation, no public PoC, and an extremely low EPSS all argue against front-of-queue emergency handling.
- Upward pressure that keeps it above IGNORE — Chrome is extremely widespread, attackers need no credentials, and a malicious website can target many users cheaply if they can drive clicks.
Why not higher?
Because every meaningful step in the chain depends on the victim browsing attacker content and having useful in-browser state to steal. There is also no evidence of code execution, sandbox escape, privilege escalation, or active exploitation, so treating this like a high-priority enterprise incident would be over-scoring the actual risk.
Why not lower?
It is still a remotely triggerable browser security failure in one of the most deployed applications in the enterprise. Even limited cross-origin leakage matters for identity-heavy SaaS environments, so this belongs in normal browser hygiene rather than being dismissed outright.
05 · Compensating Control
What to do — in priority order.
- Enforce auto-update — Confirm Chrome stable auto-update is working and that no enterprise policy is pinning versions below
149.0.7827.53/54. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene and clean up lagging channels in the normal browser maintenance cycle. - Block risky web delivery paths — Use secure web gateway, DNS filtering, and email-link protection to reduce the chance users ever reach attacker HTML. This is the best temporary control for a click-required browser bug, and for a LOW verdict it should be folded into routine policy tuning rather than emergency change windows.
- Harden browser isolation for high-risk users — Apply remote browser isolation or stricter web isolation to executives, admins, finance, and helpdesk populations where even small token or session-state leakage has outsized value. Do this on the usual hardening schedule; again, LOW means no rush-SLA mitigation requirement.
- Inventory unmanaged browsers — Use EDR/software inventory to find non-standard Chrome installs, portable builds, VDI gold images, and developer workstations that lag the managed channel. The real operational risk here is forgotten endpoints, not mass exploitation pressure.
What doesn't work
- Perimeter firewall rules do not solve this; the exploit arrives over normal allowed web browsing.
- WAF rules do not help because the vulnerable component is the client browser, not your server.
- EDR alone is weak coverage here because there is no expected process injection, payload drop, or memory-corruption crash to catch.
06 · Verification
Crowdsourced verification payload.
Run this on the target endpoint or via your EDR live-response shell to check the locally installed Chrome version. Invoke with python3 chrome_cve_2026_11155_check.py; no admin rights are normally required, though some locked-down endpoints may require elevated access to read install metadata.
#!/usr/bin/env python3
# CVE-2026-11155 Chrome version check
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
FIXED_LINUX = (149, 0, 7827, 53)
FIXED_WIN_MAC = (149, 0, 7827, 53) # Google notes Windows/Mac 53/54; 53 is sufficient floor
def parse_version(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text 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 run_cmd(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def get_windows_version():
cmds = [
['reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'],
['reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'],
['powershell', '-NoProfile', '-Command', r"(Get-ItemProperty 'HKLM:\Software\Google\Chrome\BLBeacon' -ErrorAction SilentlyContinue).version"],
['powershell', '-NoProfile', '-Command', r"(Get-ItemProperty 'HKCU:\Software\Google\Chrome\BLBeacon' -ErrorAction SilentlyContinue).version"],
]
for cmd in cmds:
out = run_cmd(cmd)
ver = parse_version(out)
if ver:
return ver, 'registry'
paths = [
os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
]
for p in paths:
if p and os.path.exists(p):
out = run_cmd([p, '--version'])
ver = parse_version(out)
if ver:
return ver, p
return None, ''
def get_macos_version():
app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(app):
out = run_cmd([app, '--version'])
ver = parse_version(out)
if ver:
return ver, app
plist = '/Applications/Google Chrome.app/Contents/Info.plist'
if os.path.exists(plist):
out = run_cmd(['/usr/bin/defaults', 'read', plist, 'KSVersion'])
ver = parse_version(out)
if ver:
return ver, plist
return None, ''
def get_linux_version():
candidates = [
'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser',
'/opt/google/chrome/chrome', '/usr/bin/google-chrome', '/usr/bin/google-chrome-stable'
]
for c in candidates:
path = which(c) or (c if os.path.exists(c) else None)
if path:
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return ver, path
return None, ''
def main():
system = platform.system().lower()
if system == 'windows':
ver, source = get_windows_version()
fixed = FIXED_WIN_MAC
elif system == 'darwin':
ver, source = get_macos_version()
fixed = FIXED_WIN_MAC
elif system == 'linux':
ver, source = get_linux_version()
fixed = FIXED_LINUX
else:
print('UNKNOWN: unsupported platform {}'.format(platform.system()))
sys.exit(2)
if not ver:
print('UNKNOWN: Chrome/Chromium version not found')
sys.exit(2)
if cmp_ver(ver, fixed) < 0:
print('VULNERABLE: detected version {} from {} ; fixed version is {}.{}.{}.{} or later'.format(
'.'.join(map(str, ver)), source, *fixed
))
sys.exit(1)
else:
print('PATCHED: detected version {} from {} ; fixed floor is {}.{}.{}.{}'.format(
'.'.join(map(str, ver)), source, *fixed
))
sys.exit(0)
if __name__ == '__main__':
main()
07 · Bottom Line
If you remember one thing.
TL;DR
Monday morning: do not let this jump the queue ahead of browser RCEs, edge appliance bugs, or anything with KEV pressure. For a LOW noisgate verdict there is noisgate mitigation SLA and no emergency temporary-control deadline — treat it as backlog hygiene — and there is likewise no hard noisgate remediation SLA beyond your normal browser maintenance cadence; verify auto-update, sweep for pinned or unmanaged Chrome installs, and close out laggards in the routine patch cycle rather than a war room.
Sources
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.