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.
3 steps from start to impact.
Land the victim on a malicious page
- 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
- 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
Probe cross-origin state via CSS side effects
- 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
- 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
Exfiltrate inferred bits back to attacker infrastructure
- Attacker-controlled egress endpoint reachable from the browser
- Useful information successfully inferred in prior step
- 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
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the checked sources, and it is not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No 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. |
| EPSS | 0.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 status | Not present in the CISA Known Exploited Vulnerabilities Catalog. |
| CVSS vector | CVSS: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 versions | Google Chrome prior to 149.0.7827.53 according to the CVE/NVD record. |
| Fixed versions | Fixed 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 reality | This 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 coverage | Strong for version-based asset inventory, weak for exploitability validation. Network vuln scanners will largely miss this unless they ingest software inventory from the endpoint. |
| Disclosure | Disclosed 2026-06-04. Public bug metadata is still sparse; the referenced Chromium issue is present but not openly detailed yet. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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. - 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.
- 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.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.