This is a bad lock on the front door, not a hole in the basement wall
CVE-2026-11122 is a Chrome UXSS flaw in the Keyboard component. In plain English: a malicious web page can make Chrome treat attacker-controlled script or HTML as more trusted than it should, letting the attacker run content across origin boundaries inside the browser. Affected builds are Google Chrome prior to 149.0.7827.53; Google’s desktop stable release on June 2, 2026 shipped 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS.
Google tagged it Medium, and technically that is defensible because the published impact is script/HTML injection (UXSS) rather than sandbox escape or native code execution. But for enterprise defenders, that underrates the operational risk: this is a remote, drive-by, browser-reachable bug in one of the most ubiquitous apps in the fleet, and UXSS can turn active browser sessions into stolen data, stolen tokens, and cross-origin abuse without needing internal access or local execution. That pushes it above ordinary medium backlog material, even without evidence of active exploitation.
4 steps from start to impact.
Lure user to attacker-controlled page
- Victim runs Chrome older than 149.0.7827.53
- Victim browses to attacker-controlled or attacker-influenced content
- Attacker can deliver a crafted HTML page
- User still has to hit the page through phishing, malvertising, a poisoned document link, or a compromised site
- Browser isolation products can break the chain before the browser processes the page locally
- Fast Chrome auto-update sharply reduces dwell time for exposed endpoints
Trigger the Keyboard UXSS condition
- Specific vulnerable code path in Keyboard is reachable from web content
- Target browser has not yet received the June 2026 stable fix
- Exploit reliability for UXSS bugs is often version-sensitive and can break with minor Chrome changes
- Site Isolation and renderer hardening do not necessarily stop UXSS, but they can limit some follow-on abuse depending on the exact code path
- No public PoC or mass exploitation reporting was found at the time of assessment
Steal browser-resident data and act as the user
- Victim has valuable active sessions in the browser
- Target applications trust the browser session for sensitive actions
- HttpOnly cookies cannot be read directly, though UXSS can still abuse the session by making same-context requests
- Well-designed apps with re-auth for sensitive actions reduce blast radius
- Short-lived session tokens and device-bound session controls can limit persistence
Pivot into enterprise apps, not the OS
- Victim uses browser-based enterprise apps
- Those apps are reachable from the endpoint and already authenticated or easily re-driven
- This CVE does not claim sandbox escape or code execution on the endpoint
- Blast radius is heavily user-centric; it compromises what that browser session can reach, not the whole host by default
- Privileged impact depends on the victim’s role and current sessions
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found during this assessment. Not present in CISA KEV. |
|---|---|
| PoC availability | No reliable public PoC or Metasploit-style weaponization was found. The underlying Chromium issue is referenced as issue 501485453, but details may remain restricted while the fix rolls out. |
| EPSS | 0.00055 (user-supplied intel). Percentile was not independently verified from a primary data row during this assessment. |
| KEV status | No. CISA KEV catalog checked; CVE-2026-11122 was not listed at assessment time. |
| Vendor severity | Chromium labels it Medium in the Chrome stable release notes. |
| Technical impact | Published impact is UXSS / arbitrary script or HTML injection via crafted HTML. That usually means browser trust-boundary failure and cross-origin abuse, not host-level code execution. |
| Attack preconditions | Best case for the attacker is unauthenticated remote drive-by: deliver a crafted page to a user on a vulnerable Chrome build. No internal network access, no prior account, and no local privileges are stated. |
| Affected versions | Google Chrome before 149.0.7827.53. On desktop, fixed stable versions are 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS. |
| Scanning / exposure data | Shodan/Censys-style internet exposure counts are not applicable here because this is endpoint browser software, not a listening service. Real exposure is your installed Chrome population and how quickly auto-update/restart policies converge versions. |
| Disclosure / reporter | Publicly disclosed 2026-06-04 in CVE publication feeds; Chrome’s desktop stable bulletin published 2026-06-02. Chrome release notes credit the issue as Reported by Google on 2026-04-10. |
noisgate verdict.
The decisive amplifier is that this is a remote, browser-reachable, no-auth attack path against one of the most common applications in the enterprise. The decisive limiter is that the published outcome is UXSS in the browser context, not native code execution or sandbox escape, so the blast radius is primarily the user’s active web sessions rather than the whole endpoint.
Why this verdict
- Upward pressure: unauthenticated remote drive-by. The attacker position is just “can get a user to render a crafted page,” which is internet-scale and does not assume prior compromise, internal access, or valid credentials.
- Upward pressure: Chrome is everywhere. This is not a niche appliance; reachable population is whatever share of your fleet runs Chrome and has not yet updated, so exposure can be very broad even though there is no server-side listening surface.
- Downward pressure: impact is browser-context UXSS, not host takeover. The CVE describes arbitrary script/HTML injection and cross-origin abuse, which is serious for sessions and data, but it is still a step below sandbox escape or native RCE.
- Downward pressure: no KEV, no public active exploitation, very low EPSS. Those are meaningful reasons not to call this CRITICAL.
- Net result: = ASSESSED AT HIGH. Easy remote reachability and broad endpoint population push it above MEDIUM; limited published impact and absent exploitation evidence keep it below CRITICAL.
Why not higher?
There is no published evidence here of sandbox escape, native code execution, wormability, or active exploitation. The described outcome is browser trust-boundary failure and session abuse, which can be damaging, but it does not automatically become full endpoint compromise. That keeps this out of CRITICAL.
Why not lower?
Calling this MEDIUM would overweight the vendor’s technical label and underweight the fact that the attack path is external, unauthenticated, and user-reachable through normal browsing. In a large fleet, a browser UXSS bug is not a lab curiosity; it is a realistic route to SaaS session abuse and data theft at scale.
What to do — in priority order.
- Enforce browser isolation for risky cohorts — Route high-risk browsing populations such as admins, finance, executives, and helpdesk through remote browser isolation or equivalent protective browsing controls. This cuts off local exploit execution in the endpoint browser and should be deployed within 30 days for a HIGH verdict where immediate patching coverage is incomplete.
- Force rapid browser restart compliance — Chrome often auto-downloads the fix but does not fully remediate until the browser restarts. Use MDM, GPO, or enterprise browser management to enforce restart prompts and restart deadlines so patched binaries actually take effect within 30 days across lagging endpoints.
- Harden SaaS session abuse paths — Require step-up reauthentication for sensitive actions in IdP, admin portals, and high-value SaaS apps, and shorten session lifetimes where practical. This does not prevent UXSS, but it reduces the value of browser-context compromise and should be rolled out within 30 days for privileged user groups first.
- Prioritize privileged browsing personas — Separate browsing profiles or dedicated hardened browsers for administrators and other high-value users reduce blast radius when a browser-context bug is hit. Apply this as a compensating control within 30 days where patch lag or legacy operational constraints exist.
- MFA by itself does not solve this once the victim already has an authenticated browser session; UXSS can abuse the session after login.
- Perimeter vulnerability scans do not meaningfully measure exposure here because Chrome is endpoint software, not an internet-facing service.
- Generic EDR prevention is not a dependable stop for browser-only session abuse; there may be no dropped binary, no child process, and no obvious host IOC.
Crowdsourced verification payload.
Run this on the target endpoint or via your software-distribution/EDR live-response tooling. Invoke it with python3 check_chrome_cve_2026_11122.py or python check_chrome_cve_2026_11122.py; no admin rights are required for normal version checks, though some locked-down installations may need elevated access to query application paths.
#!/usr/bin/env python3
# check_chrome_cve_2026_11122.py
# Determine whether local Google Chrome is vulnerable to CVE-2026-11122
# Outputs exactly one of: VULNERABLE, PATCHED, UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
TARGET = (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 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 p.returncode, out.strip()
except Exception:
return None, ''
def check_linux():
candidates = [
shutil.which('google-chrome'),
shutil.which('google-chrome-stable'),
shutil.which('chromium-browser'),
shutil.which('chromium'),
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
]
for c in candidates:
if not c:
continue
rc, out = run_cmd([c, '--version'])
ver = parse_version(out)
if ver:
return c, ver
return None, None
def check_macos():
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for c in candidates:
if os.path.exists(c):
rc, out = run_cmd([c, '--version'])
ver = parse_version(out)
if ver:
return c, ver
return None, None
def check_windows():
powershell = shutil.which('powershell') or shutil.which('pwsh')
if not powershell:
return None, None
ps_script = r'''
$paths = @(
"$Env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"$Env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
"$Env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
)
foreach ($p in $paths) {
if (Test-Path $p) {
try {
$v = (Get-Item $p).VersionInfo.ProductVersion
Write-Output "$p|$v"
exit 0
} catch {}
}
}
exit 1
'''
rc, out = run_cmd([powershell, '-NoProfile', '-NonInteractive', '-Command', ps_script])
if rc == 0 and '|' in out:
path, ver_text = out.split('|', 1)
ver = parse_version(ver_text)
if ver:
return path.strip(), ver
return None, None
def main():
system = platform.system().lower()
path = None
ver = None
if 'linux' in system:
path, ver = check_linux()
elif 'darwin' in system:
path, ver = check_macos()
elif 'windows' in system:
path, ver = check_windows()
else:
print('UNKNOWN')
sys.exit(2)
if not ver:
print('UNKNOWN')
sys.exit(2)
# Chrome desktop stable release fixed version for this CVE is 149.0.7827.53 or later.
# Windows/macOS may also report .54; both are patched relative to this CVE.
if cmp_ver(ver, TARGET) >= 0:
print('PATCHED')
sys.exit(0)
else:
print('VULNERABLE')
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.