This is a forged visitor badge at the browser front desk, not a master key to the building
CVE-2026-11186 is a Chrome CSS implementation flaw that can let a remote attacker inject arbitrary script or HTML via a crafted page. Affected builds are Chrome versions prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows and macOS; Android inherits the corresponding desktop security fixes in 149.0.7827.59 unless otherwise noted by Google.
Google scored it MEDIUM (6.1), and that is basically right. The amplifier is obvious: Chrome is everywhere, so a browser bug can touch a very large population fast. But the downward pressure matters more here: exploitation requires user interaction, impact is browser-session level rather than OS-level, there is no current KEV listing or public in-the-wild evidence, and the technical details are still partly restricted while the fix rolls out.
4 steps from start to impact.
Stage a lure with a crafted HTML/CSS payload
- Attacker can host or inject a malicious web page
- Victim uses a vulnerable Chrome build before
149.0.7827.53
- No public PoC was located in authoritative or mainstream security sources
- Exact bug details may still be embargoed/restricted while the fix propagates
Get the user to browse to it with phish / malvertising / compromised site
- User interaction: victim must visit or render attacker-controlled content
- Enterprise controls do not block the destination first
- Email security, DNS filtering, Secure Web Gateway, and browser reputation systems reduce click-through
- Users must actually load the page; this is not an unauthenticated server-side exploit
Trigger browser-origin confusion with the CSS exploit
- Victim reaches the vulnerable code path
- Chrome mitigations do not fully contain the impact for that case
- Chrome sandboxing and Site Isolation reduce what a single renderer-origin bug can typically reach
- The CVSS impact is low/low/none, which argues against broad system compromise
Monetize the browser session using credential theft or transaction tampering
- Victim has active sessions worth stealing or abusing
- Targeted application lacks additional session-binding or step-up controls
- MFA does not stop session reuse once tokens are stolen, but step-up auth and conditional access can limit high-risk actions
- Blast radius is usually bounded to the user and active browser context, not fleet-wide host compromise
149.0.7827.53 and isolate unmanaged exceptions such as lab hosts, offline laptops, gold images, and nonpersistent VDI templates. There is no mitigation SLA — go straight to the 365-day remediation window, so use regular hygiene processes rather than emergency change windows.- Relying on MFA alone does not solve browser-session theft; once a session cookie is stolen or an in-session action is performed, MFA may never be challenged again.
- A perimeter vulnerability scanner will not tell you much here because Chrome clients are not meaningfully Internet-fingerprintable for this flaw.
- Generic server-side WAF rules do little if the lure is a malicious page on the open web or a compromised third-party site rendered directly by the user.
The supporting signals.
| In-the-wild status | No current evidence of active exploitation found in Google release notes, and the CVE is not present in CISA KEV based on catalog checks. |
|---|---|
| Proof-of-concept availability | No public PoC located in authoritative sources reviewed as of 2026-06-05; treat that as an absence-of-evidence call, not proof none exists. |
| EPSS | 0.00026 (~0.026%), which is very low. That supports deprioritizing this below browser RCEs and KEV-listed Chrome bugs. |
| KEV status | Not KEV-listed as checked against the CISA Known Exploited Vulnerabilities Catalog. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N — remote and easy to trigger, but requires user interaction and does not score for availability impact. |
| Affected versions | Chrome prior to 149.0.7827.53; Google states fixed stable desktop builds are 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/Mac. |
| Fixed versions | Upgrade to 149.0.7827.53 or later on Linux, 149.0.7827.53/54 or later on Windows/macOS, and corresponding Android build 149.0.7827.59 carrying desktop security fixes. |
| Scanning / exposure reality | This is a client-side browser issue, so Shodan/Censys/FOFA are poor exposure gauges. Real exposure should be measured from EDR, software inventory, Chrome enterprise management, or package telemetry—not Internet scanning. |
| Disclosure timeline | Google published the stable desktop update on 2026-06-02; the CVE metadata in your intel block shows disclosed 2026-06-04. |
| Reporter | Google release notes attribute the bug as reported by Google on 2026-04-15. |
Sources.
Why this verdict
- Baseline holds: Google already placed this at MEDIUM 6.1, and the published vector says remote/no-privs but *user-interaction required* with only low confidentiality/integrity impact.
- User must browse attacker content: that implies phishing, malvertising, or a compromised site. Modern email gateways, SWGs, DNS filtering, and Safe Browsing add real-world drag before exploit code ever runs.
- Browser bug, not box-owning bug: this is script/HTML injection in Chrome CSS, not a memory-corruption path to native code execution. The blast radius is usually the user's active browser session and web apps, not the endpoint OS.
- No exploit pressure signals: no KEV entry, no public exploitation note from Google, and an EPSS of 0.00026 all push this down versus Chrome bugs that are already being used in the wild.
- Reachable population is broad but not uniformly exploitable: Chrome is ubiquitous, but only vulnerable unmanaged or not-yet-updated clients matter, and Chrome's auto-update materially shrinks the exposure window in managed fleets.
Why not higher?
This does not earn HIGH because the chain is not straight-through unauthenticated compromise of a service or endpoint. The attacker needs a user to render malicious content, and the published impact is low confidentiality/low integrity with no availability hit, which is a long way from reliable enterprise-wide compromise.
Why not lower?
This is not LOW because Chrome is one of the widest exposure surfaces in the enterprise, and a browser-origin break can still steal SaaS sessions or tamper with business workflows. Even without RCE, one-click client-side abuse against a heavily used browser deserves real patching attention.
Crowdsourced verification payload.
Run this on the target endpoint or through your fleet management tool. Invoke it as python3 chrome_cve_2026_11186_check.py on macOS/Linux or py chrome_cve_2026_11186_check.py on Windows; no admin rights are usually needed, though elevated access may help enumerate machine-wide install paths.
#!/usr/bin/env python3
# CVE-2026-11186 Chrome version check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
PATCH_LINUX = (149, 0, 7827, 53)
PATCH_WIN_MAC = (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 version_ge(a, b):
return 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 '') + ' ' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def detect_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 c and os.path.exists(c):
out = run_cmd([c, '--version'])
v = parse_version(out)
if v:
return ('Linux', c, v, out)
return None
def detect_macos():
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
]
for c in candidates:
if os.path.exists(c):
out = run_cmd([c, '--version'])
v = parse_version(out)
if v:
return ('macOS', c, v, out)
return None
def detect_windows():
exe_names = []
for base in filter(None, [
os.environ.get('ProgramFiles'),
os.environ.get('ProgramFiles(x86)'),
os.environ.get('LocalAppData')
]):
exe_names.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))
for c in exe_names:
if os.path.exists(c):
out = run_cmd([c, '--version'])
if not out:
ps = f"(Get-Item '{c}').VersionInfo.ProductVersion"
out = run_cmd(['powershell', '-NoProfile', '-Command', ps])
v = parse_version(out)
if v:
return ('Windows', c, v, out)
return None
def main():
system = platform.system().lower()
info = None
if 'linux' in system:
info = detect_linux()
elif 'darwin' in system:
info = detect_macos()
elif 'windows' in system:
info = detect_windows()
else:
print('UNKNOWN: unsupported platform')
sys.exit(2)
if not info:
print('UNKNOWN: Google Chrome not found or version unreadable')
sys.exit(2)
os_name, path, version, raw = info
patch = PATCH_LINUX if os_name == 'Linux' else PATCH_WIN_MAC
print(f'Detected platform: {os_name}')
print(f'Executable: {path}')
print(f'Raw version output: {raw}')
print(f'Parsed version: {".".join(map(str, version))}')
print(f'Patched threshold: {".".join(map(str, patch))}')
if version_ge(version, patch):
print('PATCHED')
sys.exit(0)
else:
print('VULNERABLE')
sys.exit(1)
if __name__ == '__main__':
main()