This is a forged backstage pass, not a crowbar through the data-center door
CVE-2026-11142 is a Chrome client-side same-origin policy bypass in the Paint component. A victim has to browse to attacker-controlled HTML, and affected builds are Chrome versions before 149.0.7827.53; Google lists the fix in 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and Mac, with Android inheriting the same desktop security fixes in 149.0.7827.59.
Google's MEDIUM 6.5 baseline is close, but a little generous once you do the friction audit. This is not wormable, not unauthenticated service exposure, not code execution, and not a perimeter-scannable server bug; it is a user-driven browser trust-boundary break that matters because Chrome is everywhere, but the practical blast radius usually stays bounded to the victim's browser session and whatever web apps they are already logged into.
4 steps from start to impact.
Land the victim on malicious HTML
- Victim is using Chrome prior to 149.0.7827.53
- Victim browses to attacker-controlled or attacker-influenced content
- JavaScript and the relevant rendering path are reachable
- Requires user interaction (
UI:R) - Requires a viable lure or ad-delivery path
- Enterprise browser isolation or aggressive ad/script controls can suppress the page before exploit logic runs
Trigger Paint policy bypass
- The vulnerable Paint code path is actually hit by the crafted page
- The browser has not auto-updated yet
- Bug details are restricted, which slows reliable weaponization
- No public proof-of-concept or exploit repository was found
- Modern Chrome hardening reduces exploit reliability for many renderer-side logic bugs
Abuse the broken origin boundary
- Victim is concurrently authenticated to target web apps
- Target workflows depend on browser-enforced origin trust
- Application-side defenses do not independently block forged actions
- Impact is often limited to the victim's current sessions
- CSRF tokens, re-auth prompts, step-up MFA, and app-side origin checks can blunt downstream abuse
- Not every site exposes a meaningful action primitive even if origin handling is weakened
Translate browser abuse into enterprise impact
- Victim has access to sensitive enterprise web applications
- Those applications trust the browser session enough for meaningful state changes
- Per-user blast radius is smaller than RCE or sandbox escape
- No evidence of in-the-wild exploitation or KEV listing at disclosure
- This is harder to operationalize at scale than browser memory-corruption bugs with code execution upside
The supporting signals.
| In-the-wild status | No public active exploitation evidence found in the sources reviewed, and not listed in CISA KEV as of this reassessment. |
|---|---|
| Public PoC status | No public PoC or exploit repo found via web search. The Chromium issue is present but access is restricted, which slows copycat weaponization. |
| EPSS | 0.00016 (user-supplied intel), which is extremely low and consistent with a non-KEV, client-side logic bug without public weaponization. |
| KEV status | Not KEV-listed. CISA's catalog did not show CVE-2026-11142 during this review. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N — remote and low complexity, but requires user interaction and does not indicate code execution or availability impact. |
| Affected versions | Google describes Chrome prior to 149.0.7827.53 as affected. This is a broad client footprint problem because Chrome is ubiquitous, but it is still a browser-side exposure rather than an internet-facing service. |
| Fixed versions | Desktop fix lands in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac). Google also states Android 149.0.7827.59 includes the same corresponding desktop security fixes. |
| Scanner / exposure reality | Not internet-scannable in the Shodan/Censys/GreyNoise sense; those platforms will not tell you where vulnerable browsers sit. You need endpoint/browser inventory, MDM, EDR, or enterprise browser-management telemetry. |
| Disclosure timeline | Reported by Google on 2026-04-11 in the stable-channel fix list; publicly disclosed 2026-06-04 in the CVE/CNA record. |
| Researcher / reporter | The stable-channel advisory attributes the bug to Google rather than an external researcher, and the Chromium bug link is 501668745. |
noisgate verdict.
The decisive downward pressure is that this is a lure-dependent client-side browser bug, not an exposed server-side foothold. It can absolutely matter in a Chrome-heavy estate, but without RCE, KEV status, public weaponization, or broad blast radius beyond the victim's browser session, it stays in MEDIUM.
Why this verdict
- UI:R cuts the score down — the attacker needs the victim to load crafted web content, which is materially weaker than an internet-facing unauthenticated service exploit.
- Client-side only, not perimeter-reachable — this is a browser-session problem, so Shodan/Censys-style exposure scaling does not apply and SOC teams must already have endpoint/browser inventory to even find it.
- Integrity impact is real but bounded — the main consequence is cross-origin action abuse inside the victim's logged-in browser context, not host takeover or broad tenant compromise.
- No exploitation evidence — no KEV listing, no public PoC found, and Google kept bug details restricted, all of which reduce immediate operational risk.
- Chrome ubiquity keeps it from going LOW — unlike a niche plugin flaw, this sits in a massively deployed browser, so even a medium-grade trust-boundary bug can hit a large user population if version lag exists.
Why not higher?
There is no evidence here of sandbox escape, arbitrary code execution, wormability, or active exploitation. The attack still needs a victim browsing event and usually only buys the attacker whatever abuse they can squeeze from that user's active web sessions.
Why not lower?
A same-origin policy bypass is still a browser trust-boundary failure, not cosmetic noise. In a large enterprise with federated SaaS and always-on SSO sessions, per-user session abuse can translate into meaningful account actions, especially against internal admin portals and business apps.
What to do — in priority order.
- Force browser auto-update compliance — Use enterprise browser management, MDM, or endpoint tooling to drive Chrome to 149.0.7827.53/54 or later and measure drift. For a MEDIUM verdict there is no mitigation SLA, so keep this in normal change flow and close it inside the 365-day remediation window, though most teams should finish browser rollout much sooner because the operational cost is low.
- Tighten risky web content paths — Reduce exposure to malicious HTML delivery by hardening ad/script controls, disabling unnecessary extension sprawl, and using browser isolation for high-risk user groups. There is no mitigation SLA — go straight to the remediation window — but these controls are useful while patch compliance catches up.
- Watch for web-session abuse — Ask IAM and SaaS owners to review anomalous state-changing actions, suspicious origin/referrer patterns, and step-up authentication triggers from managed Chrome endpoints that remain below the fixed version. This is especially relevant for admin portals where a browser trust-boundary miss can still translate to real business impact.
- Prioritize exposed user populations — Front-load updates for admins, finance, HR, help desk, and developers who maintain long-lived authenticated browser sessions. Even without a formal mitigation deadline for MEDIUM, these cohorts carry more downstream blast radius if the browser session is abused.
- External vulnerability scanning doesn't help because vulnerable Chrome clients are not an internet-facing service surface.
- A WAF by itself will not reliably stop a browser-internal same-origin policy bypass once the victim loads attacker-controlled content.
- Rebooting browsers or hosts without updating does nothing durable; the vulnerable code path remains until the patched version is installed.
- Email-only controls are insufficient because delivery can come from web ads, compromised sites, chat links, docs, or any other browser lure path.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/EDR remote execution channel. Invoke with python3 chrome_cve_2026_11142_check.py; no admin rights are required for basic version detection, but broader path coverage on Windows/macOS/Linux is better with a standard managed-user context.
#!/usr/bin/env python3
# chrome_cve_2026_11142_check.py
# Check Google Chrome version against CVE-2026-11142 fixed builds.
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
TARGET = (149, 0, 7827, 53) # minimum fixed baseline
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()
return (p.stdout or p.stderr).strip()
except Exception:
return ''
def candidate_commands():
system = platform.system().lower()
cmds = []
if system == 'windows':
local = os.environ.get('LOCALAPPDATA', '')
programfiles = os.environ.get('ProgramFiles', '')
programfilesx86 = os.environ.get('ProgramFiles(x86)', '')
paths = [
os.path.join(programfiles, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(programfilesx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for p in paths:
if p and os.path.exists(p):
cmds.append([p, '--version'])
# Registry fallback via PowerShell
cmds.append(['powershell', '-NoProfile', '-Command', "(Get-Item 'HKLM:\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\chrome.exe').GetValue('')"])
cmds.append(['powershell', '-NoProfile', '-Command', "(Get-ItemProperty 'HKLM:\\Software\\Google\\Chrome\\BLBeacon' -ErrorAction SilentlyContinue).version"])
cmds.append(['powershell', '-NoProfile', '-Command', "(Get-ItemProperty 'HKCU:\\Software\\Google\\Chrome\\BLBeacon' -ErrorAction SilentlyContinue).version"])
elif system == 'darwin':
mac_paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for p in mac_paths:
if os.path.exists(p):
cmds.append([p, '--version'])
cmds.append(['mdls', '-name', 'kMDItemVersion', '/Applications/Google Chrome.app'])
else:
names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
for name in names:
path = shutil.which(name)
if path:
cmds.append([path, '--version'])
# Package manager fallbacks
cmds.append(['bash', '-lc', "dpkg-query -W -f='${Version}\n' google-chrome-stable 2>/dev/null"])
cmds.append(['bash', '-lc', "rpm -q --qf '%{VERSION}-%{RELEASE}\n' google-chrome-stable 2>/dev/null"])
return cmds
def get_version():
seen = []
for cmd in candidate_commands():
out = run_cmd(cmd)
if out:
seen.append(out)
ver = parse_version(out)
if ver:
return ver, out
return None, '\n'.join(seen)
def main():
ver, raw = get_version()
if not ver:
print('UNKNOWN: Google Chrome version not detected')
sys.exit(2)
# Windows/Mac may be 149.0.7827.54; Linux noted as 149.0.7827.53.
# Treat any version >= 149.0.7827.53 as patched for this CVE.
if cmp_ver(ver, TARGET) >= 0:
print(f'PATCHED: detected Chrome version {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]}')
sys.exit(0)
else:
print(f'VULNERABLE: detected Chrome version {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]}')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.