This is a peephole drilled through Chrome’s privacy wall, not a front-door kick-in
CVE-2026-11139 is a Chrome client-side information disclosure issue in the Paint pipeline. A malicious site can reportedly abuse the flaw in Chrome versions prior to 149.0.7827.53 to leak *cross-origin* data via crafted web content, which means the prize is whatever the victim browser can already see or render from another origin during that session.
Google rated it MEDIUM at 6.5, and that is a little generous in enterprise terms. Same-origin-policy failures matter, but this one still requires user interaction, browser-side exploit reliability, and a victim who is simultaneously authenticated to something worth stealing; there is no evidence here of code execution, sandbox escape, KEV listing, or in-the-wild exploitation.
4 steps from start to impact.
Lure the victim into a hostile page
- Victim is running Chrome earlier than
149.0.7827.53 - Victim visits attacker-controlled or attacker-influenced web content
- JavaScript and normal web rendering are available
- Requires user interaction
- Enterprise URL filtering, email security, Safe Browsing, and web isolation can kill a large slice of delivery attempts
- Auto-update narrows the vulnerable population quickly for managed Chrome fleets
Abuse the Paint bug to cross an origin boundary
- The vulnerable rendering path in Paint is reachable from web content
- The victim browser is concurrently handling sensitive cross-origin content or state
- Exploit logic is compatible with the target platform/build
- Exploit reliability can be brittle across OS, GPU, and browser build variation
- The attacker only gets value if relevant cross-origin data is actually present and reachable in-session
- No public PoC located, which usually means more engineering cost for attackers
Steal session-bound data
- Victim is logged into a sensitive site
- The leaked data is enough to expose content or tokens worth stealing
- Outbound exfiltration from the browser is permitted
- Blast radius is usually tied to one user session, not the endpoint or domain
- Modern SaaS defenses like re-auth, token binding, and conditional access reduce follow-on value
- Leak scope may be partial or content-specific rather than universal account compromise
Turn browser data into account abuse
- Leaked data is actionable
- Targeted user has access to sensitive business apps
- The attacker can reuse or monetize the exposed information
- This is post-click and session-dependent, which sharply limits scale compared with RCE browser bugs
- MFA, device-bound sessions, and downstream detection can stop follow-on abuse
- Many victims will yield low-value consumer browsing data rather than privileged enterprise data
The supporting signals.
| In-the-wild status | No confirmed active exploitation found. Not present in CISA KEV as of the catalog pages reviewed. |
|---|---|
| Proof-of-concept availability | No public PoC located in primary or common secondary references reviewed. That does not make it safe, but it raises attacker effort versus bugs with copy-paste exploit code. |
| EPSS | 0.00035 (~0.035% next-30-day probability). The percentile was not directly verifiable from FIRST in this environment; based on comparable FIRST examples, this sits in the low tail, roughly low-teens percentile. |
| KEV status | No. No KEV listing date or due date because the CVE is not cataloged by CISA. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — remote, no auth, but user interaction required and impact is confidentiality-only. |
| Affected versions | Google Chrome prior to 149.0.7827.53; the early-stable desktop release references 149.0.7827.53/.54 for Windows/macOS, with Linux at 149.0.7827.53. |
| Fixed versions | Upgrade to 149.0.7827.53 or later on Linux, and 149.0.7827.53/.54 or later on Windows/macOS. Chrome auto-update and enterprise channel management are the practical delivery path; distro-packaged Chromium may backport fixes under different package version strings. |
| Exposure reality | Internet-wide scanners like Shodan/Censys are a poor fit because this is client browser exposure, not a server socket. The amplifier is product ubiquity: StatCounter showed Chrome at roughly 68% worldwide browser share across devices and over 73% desktop share in early 2026, so reachable victims are abundant even though direct scanner enumeration is not. |
| Disclosure date | 2026-06-04 from the user-supplied intel, consistent with the release timing around the Chrome 149 rollout. |
| Researcher / reporting | Specific reporting researcher was not identified in the sources reviewed. Also note: the user-supplied CWE-352 looks suspect for a cross-origin data leak; that CWE usually maps to CSRF rather than SOP/privacy-boundary failures. |
noisgate verdict.
The decisive downward pressure is that exploitation still depends on user interaction and a live victim browser session rather than exposed server software or host-level code execution. The upward pressure is Chrome's enormous installed base and the fact that same-origin boundary failures can expose real SaaS data from already-authenticated users.
Why this verdict
- User click required: the attacker is unauthenticated and remote, but they still need the victim to load hostile content, which is a real friction point in enterprise fleets.
- Confidentiality-only impact: the published vector is
C:H / I:N / A:N; this is data exposure, not endpoint takeover, persistence, or domain blast radius. - Session-dependent value: the bug only matters if the victim is already browsing sensitive cross-origin content that the exploit can actually reach during that session.
- No active exploitation signals: no KEV, no confirmed campaigns, and a very low EPSS score all push this below urgent browser-zero-day territory.
- Huge product footprint keeps it out of LOW: Chrome's massive deployment means even medium-grade client bugs can produce real incident volume when a campaign appears.
Why not higher?
This is not an unauthenticated server-side bug, not a pre-auth appliance bug, and not a browser RCE or sandbox escape. The chain is narrower: lure victim, hit a specific browser build, rely on in-session cross-origin value, and then monetize stolen data without a guaranteed host compromise.
Why not lower?
Breaking browser origin isolation is still meaningful because enterprise users spend their day inside authenticated SaaS sessions. Chrome is everywhere, so once delivery works, the reachable victim population is large enough that defenders should not write this off as mere nuisance.
What to do — in priority order.
- Enforce Chrome auto-update — Make sure managed browsers cannot sit below
149.0.7827.53for long. For aMEDIUMverdict there is no mitigation SLA, so treat this as exposure reduction while you work the patch through normal browser operations and complete remediation within the 365-day window. - Block unmanaged browsers from sensitive apps — Use IdP conditional access, device trust, or enterprise browser controls so high-value SaaS only accepts managed and compliant browser sessions. This reduces the payoff of browser-side data leaks while you patch; again, no mitigation SLA applies for MEDIUM, but it is worth doing where the business risk is high.
- Tighten web isolation for risky categories — Send newly registered domains, uncategorized sites, ads, and user-generated content through RBI/SWG isolation where available. That directly attacks step 1 of the chain by making hostile page delivery less likely to reach a vulnerable session before normal remediation is completed.
- Use least-privilege browser profiles — Separate admin workflows from general browsing and avoid keeping privileged sessions open in the same browser context users use for casual web activity. This does not fix the bug, but it reduces the data value available to a successful same-origin bypass.
- Endpoint AV alone — it may catch delivery infrastructure or follow-on malware, but it will not understand a browser-origin data leak happening inside normal renderer behavior.
- Network perimeter scanning — this is a client-side browser flaw, so there is no exposed listening service for your scanner to find.
- MFA by itself — MFA helps with follow-on account abuse, but it does not stop the initial cross-origin data exposure inside an already-authenticated browser session.
Crowdsourced verification payload.
Run this on the endpoint itself or via your software inventory agent, because you need the locally installed Chrome version. Invoke it with python3 check_chrome_cve_2026_11139.py on macOS/Linux or py check_chrome_cve_2026_11139.py on Windows; standard user rights are usually enough, but admin may be needed if Chrome is installed in a nonstandard location.
#!/usr/bin/env python3
# Check local Google Chrome version against CVE-2026-11139 fixed version.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from pathlib import Path
FIXED = (149, 0, 7827, 53)
def parse_version(s):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
if not m:
return None
return tuple(int(x) for x in m.groups())
def version_str(v):
return '.'.join(str(x) for x in v)
def get_version_from_command(cmd):
try:
out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
return parse_version(out.strip())
except Exception:
return None
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'),
]
ps = (
"$paths = @('C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe',"
"'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',"
"'$env:LOCALAPPDATA\\Google\\Chrome\\Application\\chrome.exe');"
"$found = $paths | Where-Object { Test-Path $_ } | Select-Object -First 1;"
"if ($found) { (Get-Item $found).VersionInfo.ProductVersion }"
)
v = get_version_from_command(["powershell", "-NoProfile", "-Command", ps])
if v:
return v
for path in candidates:
if os.path.exists(path):
try:
out = subprocess.check_output([
'powershell', '-NoProfile', '-Command',
f"(Get-Item '{path}').VersionInfo.ProductVersion"
], stderr=subprocess.STDOUT, text=True, timeout=10)
v = parse_version(out)
if v:
return v
except Exception:
pass
return None
def get_macos_version():
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for path in candidates:
if os.path.exists(path):
v = get_version_from_command([path, '--version'])
if v:
return v
return None
def get_linux_version():
commands = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium', '--version'],
['chromium-browser', '--version'],
]
for cmd in commands:
v = get_version_from_command(cmd)
if v:
return v
paths = [
'/opt/google/chrome/google-chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
]
for path in paths:
if os.path.exists(path):
v = get_version_from_command([path, '--version'])
if v:
return v
return None
def main():
system = platform.system().lower()
if 'windows' in system:
v = get_windows_version()
elif 'darwin' in system:
v = get_macos_version()
elif 'linux' in system:
v = get_linux_version()
else:
v = None
if not v:
print('UNKNOWN - Could not determine local Chrome/Chromium version')
sys.exit(2)
print(f'Detected version: {version_str(v)}')
print(f'Fixed version threshold: {version_str(FIXED)}')
if v < FIXED:
print('VULNERABLE')
sys.exit(1)
else:
print('PATCHED')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, push the update through your standard browser ring, and use conditional access or browser isolation only where high-value apps justify the extra friction. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA; in practice, because browser updates are low-friction and broadly deployed, most enterprises should clear this in the next normal browser maintenance cycle rather than letting it age for quarters.Sources
- Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome Releases blog homepage
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- FIRST EPSS data and fields
- Quanteta CVE tracker entry for CVE-2026-11139
- VulDB CVE index showing CVE-2026-11139
- StatCounter browser market share worldwide
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.