This is a peephole in the browser's apartment wall, not a master key to the whole building
CVE-2026-11182 is an information-disclosure flaw in Chrome's SVG handling that can let a malicious webpage read data that should stay isolated by the browser's same-origin boundary. Based on the vendor intel and reviewed release material, affected builds are Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS; *inference:* the reviewed sources do not show an Extended Stable backport yet, so managed 148.x fleets should be treated as potentially exposed until Google explicitly says otherwise.
Google's MEDIUM 6.5 label is about right in the real world. The exposure population is enormous because Chrome is everywhere and the attacker only needs a victim to render a crafted page, but the payload is still *confidentiality-only*, there is no known KEV entry or public exploitation evidence, and the likely blast radius is a user's browser session rather than host takeover.
4 steps from start to impact.
Land the victim on a malicious HTML/SVG page
- Unauthenticated remote attacker can get a user to open or render a webpage
- Victim is using a vulnerable Chrome build
- Browser can reach the attacker-controlled site
- Email security, DNS filtering, SWG, and browser reputation services block a meaningful chunk of first-contact URLs
- User interaction is still required
- Enterprise browser isolation deployments can kill the attack before local rendering
Trigger the vulnerable SVG code path
- Attacker can serve crafted SVG/HTML content tailored to the vulnerable build
- Victim browser allows the page to render the relevant SVG path
- No public proof-of-concept was found in the reviewed sources
- Chrome often restricts bug details until most users are updated, which slows opportunistic weaponization
- Minor build drift matters in browser exploitation
Read cross-origin data from the victim session
- Victim is logged into or has browser-accessible state for another origin worth stealing
- The specific data the attacker wants is exposed by the flawed path
- The prize is only as valuable as the victim's active browser state
- Modern web app hardening like SameSite cookies, CSP, token scoping, and short session lifetimes can limit payoff
- Some targets require victim-specific workflow timing
Exfiltrate via normal web requests
- Attacker can receive outbound web traffic from the victim browser
- Stolen data is small enough to exfiltrate through normal browser requests
- SWG, DLP, CASB, or browser isolation can reduce exfil paths
- Enterprise egress controls may block newly registered or low-reputation domains
The supporting signals.
| In-the-wild status | No public exploitation evidence found in the reviewed vendor and CISA material as of 2026-06-05; the CVE is not in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC located. Chrome release notes routinely state bug details may remain restricted until most users are patched, which is a real brake on immediate copycat weaponization. |
| EPSS | 0.00028 from the user-provided intel. That is extremely low; *percentile was not available in the reviewed source set*. |
| KEV status | Not KEV-listed. No CISA due date, no federal emergency signal, no evidence of observed exploitation. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — internet-reachable and easy to deliver, but still user-interaction dependent and confidentiality-only. |
| Affected versions | Per the provided vendor intel, Chrome before 149.0.7827.53 is affected. For desktop rollout nuance, Google published 149.0.7827.53/.54 first as an early stable release to a small percentage of Windows/macOS users. |
| Fixed versions | Reviewed sources show fixes at Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54. *Inference:* no explicit Extended Stable backport for this CVE was visible in the reviewed sources, so do not assume 148.x is safe. |
| Scanning / exposure reality | This is not an internet-scannable server bug. Shodan/Censys-style exposure counts are basically the wrong lens; the real exposure is your installed browser population and how many users can be lured to hostile content. |
| Disclosure date | 2026-06-04 from the supplied intel block. |
| Reporter / researcher | Not publicly attributed in the reviewed release material for this specific CVE. That is common for Chrome issues while details remain partially restricted. |
noisgate verdict.
The decisive factor is that this is a drive-by, confidentiality-only browser bug with no evidence of active exploitation. Chrome's install base keeps it relevant, but the lack of code execution, lack of KEV status, and dependence on a victim rendering a malicious page keep it out of the high-priority emergency lane.
Why this verdict
- Wide reach, limited outcome: attacker position is unauthenticated remote and the reachable population is huge because Chrome is everywhere, so the vendor baseline is not crazy.
- User interaction is real downward pressure: the chain still requires the victim to render attacker content, which means email security, DNS/SWG, and browser isolation can stop the first step in many enterprises.
- Confidentiality-only impact keeps it out of HIGH: this is a same-origin boundary failure, not host compromise, not sandbox escape, and not a persistence foothold.
- No exploitation pressure: no KEV listing, no public zero-day statement, no public PoC found, and EPSS is extremely low, so there is no evidence-based reason to upgrade severity.
- Population narrowing at step 3 matters: the attacker only wins valuable data when the victim also has useful cross-origin session state in that browser, which cuts down practical payoff versus the raw CVSS story.
Why not higher?
If this had active exploitation, a clean public PoC, or it chained directly to code execution or sandbox escape, the score would jump. But on the evidence available, this is still a browser data-leak issue that needs a victim session and a lure, not a fast-moving enterprise-breach primitive.
Why not lower?
I am not pushing this down to LOW because browser bugs ride on the most exposed attack surface you own: users opening web content all day. Even without code execution, a same-origin bypass can still steal tokens or sensitive app data from high-value users, so it deserves routine patch-cycle attention rather than backlog neglect.
What to do — in priority order.
- Force auto-update compliance — Verify Chrome is actually honoring your managed update channel and target version policy. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browser fleets should not drift; use this now to collapse exposure before stragglers accumulate.
- Harden web egress and click controls — Keep phishing protection, DNS filtering, SWG reputation blocking, and safe browsing controls tight because they interrupt the only mandatory first step: getting a user to render the hostile page. There is no mitigation SLA for MEDIUM here, so treat this as standing control hygiene while you roll the patch.
- Use browser isolation for risky user groups — Remote/browser isolation is one of the few controls that directly shrinks exploitability for client-side rendering bugs by moving page execution away from the endpoint. Prioritize execs, finance, admins, and internet-heavy users while you complete remediation in the normal window.
- Reduce session-value in the browser — Shorter session lifetimes, stronger token scoping, SameSite cookies, and re-authentication for sensitive actions reduce what a cross-origin leak can actually buy an attacker. This does not replace patching, but it caps blast radius for this class of browser confidentiality flaw.
- A WAF on your own apps does not fix a client-side browser parsing flaw; the malicious page can live anywhere on the internet.
- Perimeter vulnerability scanning is the wrong tool because this is not a listening service; the exposure is endpoint version sprawl, not open ports.
- MFA alone helps with account takeover after theft, but it does not stop cross-origin data disclosure inside an already authenticated browser session.
- Extension allowlisting alone is not a fix because the reported path is a crafted webpage/SVG render issue, not primarily a rogue-extension problem.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory agent. Invoke it with python3 chrome_cve_2026_11182_check.py on macOS/Linux or py chrome_cve_2026_11182_check.py on Windows; no admin rights are usually required, but Windows registry reads and some install paths may work more reliably in an elevated shell.
#!/usr/bin/env python3
# CVE-2026-11182 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
THRESHOLD = (149, 0, 7827, 53)
WIN_MAC_THRESHOLD = (149, 0, 7827, 53) # .54 is also patched; .53 and above are acceptable
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 ver_to_str(v):
return '.'.join(str(x) for x in v)
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 get_versions_windows():
found = []
candidates = [
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 exe in candidates:
if os.path.exists(exe):
out = run_cmd([exe, '--version'])
v = parse_version(out)
if v:
found.append((exe, v))
reg_paths = [
r'HKLM\Software\Google\Chrome\BLBeacon',
r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
r'HKCU\Software\Google\Chrome\BLBeacon',
]
for key in reg_paths:
out = run_cmd(['reg', 'query', key, '/v', 'version'])
v = parse_version(out)
if v:
found.append((key, v))
return dedupe(found)
def get_versions_macos():
found = []
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for exe in candidates:
if os.path.exists(exe):
out = run_cmd([exe, '--version'])
v = parse_version(out)
if v:
found.append((exe, v))
return dedupe(found)
def get_versions_linux():
found = []
commands = ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']
for cmd in commands:
path = which(cmd)
if path:
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
found.append((path, v))
return dedupe(found)
def dedupe(items):
seen = set()
out = []
for src, ver in items:
key = (src, ver)
if key not in seen:
seen.add(key)
out.append((src, ver))
return out
def is_patched(ver):
return ver >= THRESHOLD
def main():
system = platform.system().lower()
if 'windows' in system:
found = get_versions_windows()
elif 'darwin' in system:
found = get_versions_macos()
else:
found = get_versions_linux()
if not found:
print('UNKNOWN: Google Chrome version not found')
sys.exit(2)
vulnerable = []
patched = []
unknown = []
for src, ver in found:
if is_patched(ver):
patched.append((src, ver))
else:
vulnerable.append((src, ver))
if vulnerable:
print('VULNERABLE')
for src, ver in vulnerable:
print(f' source={src} version={ver_to_str(ver)} threshold={ver_to_str(THRESHOLD)}')
if patched:
for src, ver in patched:
print(f' patched_install={src} version={ver_to_str(ver)}')
sys.exit(1)
if patched:
print('PATCHED')
for src, ver in patched:
print(f' source={src} version={ver_to_str(ver)} threshold={ver_to_str(THRESHOLD)}')
sys.exit(0)
print('UNKNOWN: unable to determine vulnerability state')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
148.x and early 149.x holdouts, make sure your managed update channel is actually advancing them, and use click-protection/browser-isolation controls for high-risk users while rollout finishes. Because this reassessment is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice you should still fold it into your next normal endpoint/browser wave, and complete the actual vendor update well inside the noisgate remediation SLA of ≤365 days rather than burning emergency change capital on it.Sources
- Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome for Testing availability - stable 149.0.7827.53
- Chrome Enterprise - browser release channels
- Chrome Enterprise - manage Chrome updates
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS data and statistics
- FIRST EPSS API documentation
- Google Chrome stable release note showing restricted bug-detail practice
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.