This is peeking through a keyhole, not kicking down the door
CVE-2026-11289 is a client-side side-channel leak in Chrome's Paint path. It affects Google Chrome before 149.0.7827.53 and requires a victim to load attacker-controlled web content, after which the page can try to infer cross-origin data through timing or rendering side effects rather than directly reading protected content.
The published 6.5 MEDIUM CVSS overstates what matters to an enterprise patch queue. In practice this is *not* unauthenticated internet-facing server compromise, *not* code execution, and *not* a turnkey data theft bug; it is a browser-side confidentiality issue with user-interaction, exploit-development friction, no KEV listing, no public exploitation evidence, and a very low EPSS signal.
3 steps from start to impact.
Land the victim on attacker-controlled content
- Victim uses Chrome older than
149.0.7827.53 - Victim browses to attacker-controlled or attacker-influenced content
- JavaScript and normal rendering behavior are available
- Requires *user interaction*; this is not a drive-by against your server estate
- Enterprise web filtering, Safe Browsing, email security, and browser isolation cut delivery volume
- Auto-update makes the vulnerable window short on well-managed fleets
Trigger the Paint side-channel
Paint behavior and measures indirect signals to infer cross-origin state or content characteristics. The weaponized tool here is simply in-browser JavaScript plus browser timing/rendering primitives rather than a standalone exploit kit.- Browser remains on a vulnerable build
- Attacker can induce measurable rendering differences
- Target data is present in a context where cross-origin state leaks are meaningful
- Side-channels are notoriously noisy and brittle across hardware, tabs, extensions, throttling, and scheduler behavior
- Site isolation and modern browser hardening reduce useful leakage paths
- Practical exploitation usually needs careful tuning, repeatability, and target-specific assumptions
Extract useful cross-origin information
- Victim is simultaneously authenticated to a valuable target or has sensitive cross-origin context loaded
- Leaked bits are actually actionable for the attacker
- Attacker can correlate timing/render output into usable conclusions
- Most enterprises need *both* a vulnerable browser and a high-value authenticated browsing session to the right target
- Leak quality may be too low for broad automation at scale
- Even successful leakage often yields partial inference, not full session takeover
The supporting signals.
| In-the-wild status | No active exploitation evidence found. Not listed in CISA KEV, and Google did not flag this issue as exploited in the release notes. |
|---|---|
| Public PoC availability | No public PoC found in this review. The Chromium issue reference 502239897 appears to remain restricted, which is normal until patch uptake improves. |
| EPSS | 0.00028 from the user-supplied intel — effectively background-noise territory for prioritization. I did not independently verify the percentile in this session. |
| KEV status | Not KEV-listed as of 2026-06-05; no CISA remediation due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — the score is driven by *confidentiality impact in theory*, but it still requires a victim to browse to hostile content. |
| Affected versions | Google Chrome before 149.0.7827.53; the desktop stable advisory covers Windows, macOS, and Linux builds in the 149 stable train. |
| Fixed versions | Patch to 149.0.7827.53 or later. The desktop advisory lists Linux 149.0.7827.53 and Windows/Mac 149.0.7827.53/.54; Android inherits the corresponding desktop security fixes in 149.0.7827.59. |
| Scanning / exposure data | Shodan/Censys/FOFA are basically irrelevant here. This is a client browser flaw, not an internet-exposed service; measure exposure through endpoint inventory and browser-version compliance, not external scanning. |
| Disclosure timeline | Reported by Google on 2026-04-13; fixed in the stable channel release published 2026-06-02, with public vulnerability disclosure surfacing by 2026-06-05. |
| Vendor severity context | Chrome's own release notes classify this bug as Low severity, while the provided CVSS/CNA view is Medium 6.5. For patch operations, the Chrome-internal rating tracks reality better than the abstract CVSS number here. |
noisgate verdict.
The decisive factor is that this is a *client-side, lure-dependent side-channel* with confidentiality-only impact and no evidence of exploitation. It narrows the reachable population to users who visit attacker-controlled content on lagging Chrome builds, which is a completely different risk class than a remotely reachable server bug with the same nominal CVSS mechanics.
Why this verdict
- Baseline starts at 6.5, then drops for delivery friction —
UI:Rmeans the attacker needs a human to browse to hostile content; that is materially weaker than a remotely reachable service flaw. - Drop again for attack surface reality — this is a browser client issue, not an internet-facing server you can mass-scan and hit on demand. Reachability depends on user behavior, browser lag, and the victim's browsing context.
- Drop again for exploit-development friction — side-channel leaks in rendering paths are noisy and environment-sensitive. Real-world reliability is usually much worse than the clean CVSS model implies.
- Drop again for threat intel — no KEV listing, no public exploitation signal found, and EPSS is extremely low (
0.00028). - Do not over-credit confidentiality impact in a vacuum — the CVSS
C:Hreflects potential sensitivity of leaked data, but the attacker still needs a workable inference channel and a valuable authenticated target context.
Why not higher?
There is no code execution, no sandbox escape, no privilege escalation, and no indication of active exploitation. The attack requires a victim browser session, attacker-controlled web content, and enough signal quality to turn rendering side effects into useful data — that's real friction, not paperwork friction.
Why not lower?
It still breaks origin boundaries, and browsers sit on every employee workstation. Even a partial cross-origin leak can matter in high-value browsing contexts, so this is not paperwork-only noise and should still be cleaned up through normal browser hygiene.
What to do — in priority order.
- Enforce browser auto-update — Make sure Chrome stable auto-update is enabled and relaunch enforcement is working across the fleet. For a LOW verdict there is no mitigation SLA; handle this as backlog hygiene and use normal endpoint compliance processes to drive all hosts to
149.0.7827.53+. - Isolate risky browsing roles — For admins, finance, and users who routinely access sensitive SaaS, prefer browser isolation or hardened browsing profiles to reduce the value of any cross-origin leak. Again, for LOW, do this through normal hardening cadence rather than emergency change windows.
- Hunt for version laggards — Query endpoint management and EDR inventory for Chrome versions below
149.0.7827.53and chase systems with disabled auto-update, stale VDI images, or relaunch debt. There is no mitigation SLA at this severity, but stale browser pockets are where low-grade bugs become operationally relevant.
- Perimeter vuln scanning doesn't tell you much here because the vulnerable component is a user browser, not a remotely fingerprintable service.
- WAF rules are the wrong control plane; this flaw lives in the client render path and is triggered by browsing content, not by inbound traffic to your servers.
- Password resets don't remediate the browser weakness and only help if you already know a specific session or token was exposed.
Crowdsourced verification payload.
Run this on the endpoint itself or through your fleet-management execution framework. Invoke with python3 check_chrome_cve_2026_11289.py on macOS/Linux or py check_chrome_cve_2026_11289.py on Windows; no admin rights are required if standard install paths are readable.
#!/usr/bin/env python3
# check_chrome_cve_2026_11289.py
# Detects whether local Google Chrome is vulnerable to CVE-2026-11289
# Outputs exactly one of: 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)
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, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
if p.returncode == 0:
return (p.stdout or p.stderr).strip()
except Exception:
pass
return None
def windows_paths():
candidates = []
for base in [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]:
if not base:
continue
candidates.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))
return candidates
def mac_paths():
return [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
def linux_paths():
paths = []
for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
p = which(name)
if p:
paths.append(p)
paths.extend([
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/opt/google/chrome/chrome',
'/snap/bin/chromium',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
])
# dedupe while preserving order
seen = set()
out = []
for p in paths:
if p not in seen:
seen.add(p)
out.append(p)
return out
def detect_version():
system = platform.system().lower()
candidates = []
if 'windows' in system:
candidates = windows_paths()
elif 'darwin' in system:
candidates = mac_paths()
else:
candidates = linux_paths()
for path in candidates:
if os.path.exists(path):
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return path, ver, out
# Fallback for Windows registry via PowerShell if binary path was not found
if 'windows' in system:
ps = which('powershell') or which('pwsh')
if ps:
script = r"""
$paths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe'
)
foreach ($p in $paths) {
try {
$item = Get-ItemProperty -Path $p -ErrorAction Stop
if ($item.'(default)') { Write-Output $item.'(default)'; break }
} catch {}
}
"""
chrome_path = run_cmd([ps, '-NoProfile', '-Command', script])
if chrome_path and os.path.exists(chrome_path.strip()):
out = run_cmd([chrome_path.strip(), '--version'])
ver = parse_version(out)
if ver:
return chrome_path.strip(), ver, out
return None, None, None
def main():
path, ver, raw = detect_version()
if not ver:
print('UNKNOWN')
sys.exit(2)
if cmp_ver(ver, THRESHOLD) < 0:
print('VULNERABLE')
sys.exit(1)
else:
print('PATCHED')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, with extra attention to privileged browsing populations and stale VDI/golden images.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.