This is a peephole in the browser wall, not a kicked-in front door
CVE-2026-11153 is a side-channel information leak in Chrome Forms handling that affects Google Chrome versions earlier than 149.0.7827.53. A malicious page can abuse browser behavior to infer cross-origin data that should stay behind same-origin boundaries. The affected range is broad in the usual browser sense—any desktop Chrome build below the fixed release—with corresponding Android security fixes shipped in Chrome 149.0.7827.59.
The vendor-supplied 9.1/CRITICAL framing overstates the operational risk for enterprise patch triage. This is still a browser bug and Chrome is everywhere, but the real-world path is *user-driven web content to data leakage*, not *unauthenticated server-side compromise* and not *remote code execution on the endpoint*. Google’s own CNA text embeds Chromium security severity: Medium, which fits reality much better than the CVSS label.
4 steps from start to impact.
Land the victim on attacker-controlled web content
- Victim runs Chrome below
149.0.7827.53 - Victim visits attacker-controlled or attacker-influenced web content
- Browser-side script execution is allowed
- This is not a passive internet scan problem; the attacker needs browser execution on a real user session
- Secure web gateways, ad filtering, and phishing-resistant browsing workflows reduce reachable population
- Many enterprise Chrome fleets auto-update quickly, shrinking the vulnerable window
Abuse Forms side-channel behavior to probe cross-origin state
501779840, but the ticket is restricted, so exact primitives are not publicly documented.- The vulnerable browser behavior must still be present
- The target cross-origin application must expose measurable behavior differences
- Browser mitigations must not fully suppress the side channel
- Side-channel leaks are usually narrower and noisier than direct DOM read access
- Practical exploitation often depends on the victim also being logged into a target site of interest
- Data obtained may be inferential rather than raw, increasing attacker effort
Extract useful cross-origin information
- Victim is authenticated to a valuable cross-origin target
- The target data can be inferred with enough precision to matter
- The attacker can exfiltrate the inferred results
- Not every target site will expose a useful signal
- Leak impact is bounded by what the side channel can actually reveal
- This is materially less reliable than a clean same-origin bypass or renderer RCE
Operationalize the stolen browser-session data
- Leaked data is high-value enough to use
- The attacker has a follow-on path against the affected web application or user
- The bug does not itself deliver code execution or persistence on the endpoint
- Blast radius is usually limited to the victim browser session and whatever sites the user is signed into
The supporting signals.
| In-the-wild status | No active exploitation evidence in the reviewed sources. CISA ADP metadata for this CVE says Exploitation: none. |
|---|---|
| Public PoC status | No public PoC or exploit repo found. The linked Chromium issue 501779840 is restricted, which also limits defender visibility into exact exploit mechanics. |
| EPSS | User-supplied EPSS is 0.00035 (0.035%), which is *very low* and consistent with low observed exploitation pressure. Percentile was not available in the supplied intel. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N treats this like a no-interaction network bug. In practice, this is *browser content-driven* and effectively depends on a victim rendering attacker HTML, which makes the UI:N posture too generous. |
| Affected versions | Chrome before 149.0.7827.53 is affected per the CNA record. The flaw is described as being in Forms and enabling cross-origin data leakage from a crafted HTML page. |
| Fixed versions | Desktop stable shipped fixes in Chrome 149.0.7827.53/54 for Windows/Mac and 149.0.7827.53 for Linux. Android 149.0.7827.59 carries the same corresponding security fixes. |
| Vendor severity mismatch | Your intel says CRITICAL 9.1, but the Chrome CNA description itself appends Chromium security severity: Medium. For patch triage, that internal Chrome assessment is the more credible operational signal. |
| Exposure / scanning reality | This is *not* a server exposure problem, so Shodan/Censys-style census data is not meaningful. The exposure question is fleet version distribution across managed browsers, not internet-facing sockets. |
| Disclosure / attribution | Published by the Chrome CNA on 2026-06-04. The public record references the Chrome release advisory and Chromium issue 501779840; no external researcher credit was exposed in the reviewed public sources. |
noisgate verdict.
The single biggest downward pressure is that this bug lives behind a *victim browsing event* and yields *cross-origin data leakage*, not endpoint compromise. Even in a ubiquitous target like Chrome, that attacker-position requirement and the absence of exploitation evidence keep this out of the urgent patch-now bucket.
Why this verdict
- Start from the browser ubiquity baseline: Chrome is massively deployed and attacker-reachable through ordinary web traffic, so the vendor baseline is not crazy *in abstract*.
- First explicit downgrade — attacker position is really browser-content execution: the CVSS says
UI:N, but the practical prerequisite is getting a user to render a malicious page or ad. That is weaker than a passive network-reachable service bug and narrows real exposure immediately. - Second explicit downgrade — post-render, not post-host: successful exploitation leaks cross-origin browser data; it does not directly give shell, persistence, or sandbox escape on the endpoint. The blast radius is usually bounded to the victim session and the sites the victim is signed into.
- Third explicit downgrade — exploit economics are poor right now: no KEV entry, no public PoC found, and EPSS
0.00035all point to low observed attacker pressure. - Why it stays at MEDIUM instead of LOW: browsers are one of the few clients attackers can hit at scale, and same-origin boundary erosion can still matter for SSO-heavy enterprises and admin workflows.
Why not higher?
There is no evidence here of renderer compromise, sandbox escape, or host-level code execution. The chain also depends on user browsing plus a valuable authenticated browser context, which is materially more constrained than a true unauthenticated remote service exploit.
Why not lower?
Chrome is everywhere, and getting victims to render malicious web content is not hard. A same-origin boundary leak against users already logged into sensitive SaaS or internal web apps can still produce real business impact even without code execution.
What to do — in priority order.
- Enforce Chrome auto-update — Make sure enterprise policy is not pinning outdated Chrome builds and that update deferrals are short. For a
MEDIUMverdict there is no mitigation SLA — go straight to the 365-day remediation window, but browsers should normally move much faster than that through standard endpoint management. - Prioritize high-risk user rings — Push fixed Chrome builds first to admins, finance, help desk, and users with access to sensitive SaaS consoles, since browser-session leakage hurts most when the victim is already authenticated. For
MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window; use that window to clean up stragglers while fast-tracking high-value populations operationally. - Use remote browser isolation for risky browsing paths — If you already have RBI or equivalent web isolation, route untrusted links, email-click traffic, and unknown domains through it. This is a sensible exposure reducer while you patch, but for
MEDIUMthere is no mitigation SLA — go straight to the 365-day remediation window. - Inventory browser versions continuously — Treat this as an endpoint software inventory problem, not a perimeter scan problem. Query EDR, MDM, or browser management to find devices below
149.0.7827.53; forMEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.
- A WAF does not meaningfully help because the exploit executes in the client browser against browser behavior, not your web server.
- MFA does not stop leakage from an already authenticated browser session; it helps before login, not after a malicious page is running in the victim tab.
- Perimeter vulnerability scanners will not find this reliably because there is no internet-facing service banner to fingerprint; you need endpoint/browser inventory instead.
Crowdsourced verification payload.
Run this on the target endpoint or through EDR live response, not from an auditor workstation. Invoke it as python3 check_chrome_cve_2026_11153.py on macOS/Linux or py check_chrome_cve_2026_11153.py on Windows; no admin rights are normally required. It checks locally installed Chrome versions and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_cve_2026_11153.py
# Detects whether locally installed Google Chrome is below 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
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 cmp_ver(a, b):
return (a > b) - (a < b)
def get_windows_version():
candidates = [
r"C:\Program Files\Google\Chrome\Application\chrome.exe",
r"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe",
os.path.expandvars(r"%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe"),
]
for path in candidates:
if path and os.path.exists(path):
try:
cmd = [
'powershell', '-NoProfile', '-Command',
f"(Get-Item '{path}').VersionInfo.ProductVersion"
]
out = subprocess.check_output(cmd, stderr=subprocess.DEVNULL, text=True, timeout=10).strip()
ver = parse_version(out)
if ver:
return path, ver
except Exception:
continue
return None, None
def get_macos_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):
try:
out = subprocess.check_output([path, '--version'], stderr=subprocess.DEVNULL, text=True, timeout=10).strip()
ver = parse_version(out)
if ver:
return path, ver
except Exception:
continue
return None, None
def get_linux_version():
candidates = [
which('google-chrome'),
which('google-chrome-stable'),
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
]
seen = set()
for path in candidates:
if not path or path in seen:
continue
seen.add(path)
if os.path.exists(path):
try:
out = subprocess.check_output([path, '--version'], stderr=subprocess.DEVNULL, text=True, timeout=10).strip()
ver = parse_version(out)
if ver:
return path, ver
except Exception:
continue
return None, None
def main():
system = platform.system().lower()
if 'windows' in system:
path, ver = get_windows_version()
elif 'darwin' in system:
path, ver = get_macos_version()
elif 'linux' in system:
path, ver = get_linux_version()
else:
print('UNKNOWN: unsupported OS for this checker')
sys.exit(2)
if not ver:
print('UNKNOWN: Google Chrome not found or version unreadable')
sys.exit(2)
installed = '.'.join(map(str, ver))
fixed = '.'.join(map(str, THRESHOLD))
if cmp_ver(ver, THRESHOLD) < 0:
print(f'VULNERABLE: Chrome {installed} found at {path}; fixed version is {fixed} or later')
sys.exit(1)
else:
print(f'PATCHED: Chrome {installed} found at {path}; meets fixed version {fixed} or later')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, and make sure Chrome auto-update policy is not being artificially delayed. For this MEDIUM reassessment there is noisgate mitigation SLA to hit here—no mitigation SLA — go straight to the 365-day remediation window—but because this is Chrome, you should still clean up laggards through your normal browser update rings rather than treating it as backlog forever; the noisgate remediation SLA is <= 365 days.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.