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
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. |
noisgate verdict.
The decisive factor is user interaction plus browser-scoped impact: the attacker needs the victim to render malicious content, and the likely outcome is session abuse or web-origin compromise rather than direct host takeover. Chrome's huge install base keeps this relevant, but the lack of KEV/in-the-wild evidence and the absence of OS-level impact keep it out of HIGH.
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.
What to do — in priority order.
- Enforce Chrome auto-update — Verify policy-backed auto-update on all managed endpoints and browsers, especially VDI and kiosk pools. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but auto-update validation should happen in the normal browser operations cycle because it closes this and the other 428 fixes in the same release.
- Filter risky web delivery paths — Tighten Secure Web Gateway, DNS, and phishing controls around newly registered domains, ad-tech categories, and user-clicked external links. There is no mitigation SLA — go straight to the 365-day remediation window, but this is the best temporary drag on the required user-interaction step.
- Harden session abuse defenses — Use conditional access, step-up auth for sensitive actions, and shorter session/token lifetimes where business allows. There is no mitigation SLA — go straight to the 365-day remediation window, and these controls specifically reduce the value of any browser-session theft this class of bug could enable.
- Inventory stragglers aggressively — Query software inventory, EDR, or Chrome enterprise telemetry for versions below
149.0.7827.53and 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.
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()
If you remember one thing.
149.0.7827.53/149.0.7827.54, with special attention to VDI images, kiosks, and unmanaged exceptions where auto-update often fails silently. Because this is MEDIUM and there is no mitigation SLA — go straight to the 365-day remediation window under the noisgate mitigation SLA model; the practical plan is to validate browser-update policy now and clean up stragglers in your normal patch cycle, while the actual version upgrade must still land within 365 days under the noisgate remediation SLA.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.