This is the deadbolt behind a door the attacker already had to kick in
CVE-2026-11008 is a cross-origin data leak flaw in Chrome's WebAppInstalls component. Affected desktop builds are Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS, with the public description stating that a remote attacker who had already compromised the renderer process could leak cross-origin data via a crafted HTML page.
Reality is less urgent than the product ubiquity suggests. This is not an initial-access browser RCE by itself; it is a post-renderer-compromise boundary bypass / data exposure primitive. That prerequisite is the whole story: if the attacker must first land a separate renderer exploit, this CVE becomes a chain component, not a standalone enterprise fire.
4 steps from start to impact.
Land code in the renderer first
- Victim browses attacker-controlled content
- A separate renderer-compromise bug exists and is exploitable
- The victim is on a vulnerable Chrome build
- This CVE is not the initial exploit
- Modern Chrome sandboxing and exploit mitigations raise the bar for renderer compromise
- Exploit chains that start in the renderer are expensive and usually reserved for higher-value targets
Trigger the WebAppInstalls validation flaw
WebAppInstalls code path and abuses insufficient validation of untrusted input. The value here is breaking a browser trust boundary rather than getting native code execution.- Renderer process is already compromised
- Reachable
WebAppInstallscode path from attacker-controlled content
- Requires the right browser state and reachable feature path
- Bug details remain restricted, which usually means reliable weaponization is non-trivial
Bypass origin boundaries and read data
- Sensitive target data is present in browser context
- Browser isolation controls do not fully block the specific leak path
- Chrome Site Isolation reduces what a compromised renderer can see
- Impact is confidentiality-focused, not full host takeover
- The attacker still needs valuable target data to be resident and reachable
Exfiltrate the stolen data
- Recovered data is valuable enough to operationalize
- Outbound exfiltration path is available
- Least-privilege browsing profiles, short-lived sessions, and conditional access reduce value
- Network controls and browser isolation can limit follow-on usefulness
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the sources reviewed; Chrome's security advisory does not flag it as exploited, and CISA KEV does not list it. |
|---|---|
| Public PoC availability | No public PoC found. Google notes bug details may remain restricted until most users are patched, which usually suppresses early weaponized writeups. |
| EPSS | 0.00043. That is a *very* low modeled exploitation probability; VulDB shows the same score, and FIRST documents EPSS as a daily exploitation-likelihood estimate. |
| EPSS percentile | Not directly available from the source set for this exact CVE. By comparison to recent FIRST API examples, the score sits in the low tail, consistent with opportunistic exploitation being unlikely. |
| KEV status | Not KEV-listed as of 2026-06-05. This is an inference from the current CISA KEV catalog and search-filter views. |
| Affected versions | Chrome desktop prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows and macOS. |
| Fixed versions | Update to 149.0.7827.53+ on Linux and 149.0.7827.53/.54+ on Windows/macOS. Downstream Chromium-based browsers will need their own vendor rebuild cadence. |
| Attack precondition that matters | Requires prior renderer compromise. That implies this is post-initial-access inside the browser sandbox, not a click-and-own bug by itself. |
| Exposure / scanning reality | This is a client-side browser vulnerability, so Shodan/Censys-style internet exposure counts are mostly irrelevant. Your exposure is your managed endpoint fleet running vulnerable Chrome, not a public listening service. |
| Disclosure / reporter | Chrome stable update published 2026-06-02; the CVE was disclosed 2026-06-04/05 depending on feed timing. The advisory credits the report to Google on 2026-03-24. |
noisgate verdict.
The decisive limiter is the renderer-compromise prerequisite. Once a CVE only matters after the attacker already has code execution in a Chrome renderer, it stops being a frontline patch emergency and becomes a chain-hardening issue in a massively deployed product.
Why this verdict
- Downshift for attacker position: exploitation requires a remote attacker who had already compromised the renderer process. That is a separate exploit stage, so this CVE is not an entry bug.
- Downshift for exposure reality: Chrome is everywhere, but this specific weakness is not internet-reachable as a service and is only actionable inside a successful browser exploit chain.
- Downshift for defender controls: Chrome sandboxing and Site Isolation are designed to reduce exactly this class of cross-origin fallout from compromised renderers.
- Upward pressure from ubiquity: if an actor already has a Chrome renderer exploit, adding a browser-boundary bypass in such a widely deployed target still has operational value at scale.
- Upward pressure from impact type: the stated impact is cross-origin data leakage, which can expose session-bound or sensitive web data even without host-level compromise.
Why not higher?
There is no sign of KEV listing, no public exploitation evidence in the reviewed sources, and no public PoC. More importantly, the attacker must first clear the hardest step with a different bug: renderer compromise. That is major real-world friction and should materially suppress patch priority versus standalone browser RCEs.
Why not lower?
This is still a real browser security-boundary failure in a ubiquitous enterprise application. If paired with a renderer exploit, it can turn one compromised web context into cross-origin data access, which is meaningful even without native code execution or sandbox escape.
What to do — in priority order.
- Enforce rapid browser auto-update — Keep Chrome and Chromium-derived browsers on centralized update policy with version compliance reporting. For a MEDIUM noisgate verdict there is no mitigation SLA; use this as standard hygiene and complete actual patch rollout within the 365-day remediation window.
- Reduce high-risk browsing exposure — Apply hardened browsing profiles for admin users, privileged access workstations, and sensitive web apps so a renderer exploit chain has less useful data to steal. There is no mitigation SLA here; treat it as baseline hardening while patching inside the 365-day remediation window.
- Maintain exploit-prevention telemetry — Keep EDR, browser crash collection, and proxy/DLP monitoring tuned for exploit staging and unusual outbound exfiltration. This will not fix the bug, but it is the control most likely to catch the upstream renderer exploit this CVE depends on.
- Inventory Chromium forks separately — Track Chrome, Edge, Brave, Electron-embedded browsers, VDI golden images, and kiosk systems as distinct patch objects. This avoids the common failure mode where Chrome is patched but downstream Chromium consumers lag for months.
- A WAF does not help; this is a client-side browser flaw, not a server-side HTTP parser issue.
- Perimeter network scanning does not meaningfully measure exposure; browsers are endpoints, not internet-facing services.
- Relying on MFA alone misses the point; if cross-origin session data is exposed inside the browser, MFA has already been bypassed by possession of the in-session context.
Crowdsourced verification payload.
Run this on the target endpoint or in your software-inventory job on each workstation/server image. Invoke it as python3 check_cve_2026_11008.py on macOS/Linux or py check_cve_2026_11008.py on Windows; no admin rights are usually needed, but registry access on Windows and app bundle access on macOS must be permitted.
#!/usr/bin/env python3
# check_cve_2026_11008.py
# Detects whether locally installed Google Chrome appears vulnerable to CVE-2026-11008.
# Output: 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 get_version_from_command(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=5)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return parse_version(out.strip())
except Exception:
return None
def windows_candidates():
paths = []
for base in [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]:
if not base:
continue
paths.append(Path(base) / 'Google' / 'Chrome' / 'Application' / 'chrome.exe')
return [str(p) for p in paths if p.exists()]
def mac_candidates():
paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
str(Path.home() / 'Applications' / 'Google Chrome.app' / 'Contents' / 'MacOS' / 'Google Chrome'),
]
return [p for p in paths if Path(p).exists()]
def linux_candidates():
names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
found = []
for name in names:
p = shutil.which(name)
if p:
found.append(p)
return found
def get_installed_versions():
system = platform.system().lower()
versions = []
if 'windows' in system:
for exe in windows_candidates():
v = get_version_from_command([exe, '--version'])
if v:
versions.append(('Google Chrome', exe, v))
elif 'darwin' in system:
for exe in mac_candidates():
v = get_version_from_command([exe, '--version'])
if v:
versions.append(('Google Chrome', exe, v))
else:
for exe in linux_candidates():
v = get_version_from_command([exe, '--version'])
if v:
versions.append(('Chrome/Chromium', exe, v))
return versions
def compare(v1, v2):
return (v1 > v2) - (v1 < v2)
def main():
versions = get_installed_versions()
if not versions:
print('UNKNOWN: Chrome/Chromium executable not found or version unreadable')
sys.exit(2)
vulnerable = []
patched = []
for name, path, ver in versions:
if compare(ver, TARGET) < 0:
vulnerable.append((name, path, ver))
else:
patched.append((name, path, ver))
if vulnerable:
joined = '; '.join(f'{name} {".".join(map(str, ver))} at {path}' for name, path, ver in vulnerable)
print(f'VULNERABLE: {joined}')
sys.exit(1)
joined = '; '.join(f'{name} {".".join(map(str, ver))} at {path}' for name, path, ver in patched)
print(f'PATCHED: {joined}')
sys.exit(0)
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.