This is a cracked wall inside the vault, but the intruder still has to get through the front door first
CVE-2026-11240 is a Loader input-validation flaw in Google Chrome that affects versions before 149.0.7827.53. Per the CVE description, the attacker must already have compromised the renderer process and then use a crafted HTML page to bypass Site Isolation, Chrome's boundary meant to keep one site's data away from another even if the renderer is hostile.
Google's LOW / 3.1 label is basically right, and if anything a little generous for patch-priority purposes. The decisive friction is that this is not an initial-access bug and not even a standalone code-exec bug; it is a post-renderer-compromise boundary bypass that only matters when chained with another vulnerability, which sharply narrows the real exposed population despite Chrome's massive install base.
4 steps from start to impact.
Land the user on attacker-controlled content
- Victim uses Chrome before 149.0.7827.53
- Victim visits attacker-controlled or attacker-influenced web content
- User interaction is required
- Web filtering, Safe Browsing, email gateways, and link isolation reduce reach
Exploit a separate renderer-compromise bug
- A separate renderer exploit exists and works against the target build
- The victim's browser mitigations do not stop the initial renderer compromise
- This assumes a prior compromise stage
- Modern Chrome exploit mitigations, sandboxing, and exploit hardening raise the bar
- Most opportunistic attackers stop here unless they need cross-origin access
Use Loader to punch through Site Isolation
- Renderer is already compromised
- The crafted page state needed for the Loader path is reachable
- Attack complexity is high
- Site Isolation exists precisely to defend this boundary, so bypassing it is non-trivial
- Bug details are still restricted in Chromium issue tracking
Read cross-site data and exfiltrate
- Victim has valuable authenticated browsing context open
- Target data is present in reachable browser state
- Impact is limited to what the browser session exposes
- This is still a browser-context problem, not direct host takeover
- No evidence so far of public weaponization or KEV-level campaign use
The supporting signals.
| In-the-wild status | No confirmed exploitation found in reviewed sources, and Google did not flag this release item as exploited in the wild. |
|---|---|
| KEV status | Not listed in CISA KEV as of 2026-06-06. |
| Public PoC availability | No public PoC located in reviewed sources. The Chromium issue for this bug is present but access-restricted, which is normal for fresh Chrome security fixes. |
| EPSS | 0.00026 from the supplied intel; percentile not independently confirmed from a primary FIRST source during review. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N means remote but high complexity, requires user interaction, and yields only low confidentiality impact in the vendor model. |
| Affected versions | Chrome before 149.0.7827.53; Google's desktop stable bulletin shipped 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS) on 2026-06-02. |
| Fixed versions | Upgrade to at least 149.0.7827.53. On Windows/macOS, Google's stable rollout includes 149.0.7827.53/54; both are post-fix builds per the Chrome release bulletin. |
| Boundary at risk | This is a Site Isolation bypass. Chromium describes Site Isolation as a protection meant to keep sites separated even in the presence of renderer vulnerabilities, which is why this bug is only meaningful after that earlier compromise happens. |
| Exposure / scanability | Not internet-scannable in the normal Shodan/Censys/FOFA sense. This is client-side browser logic, not a server-side listening service; exposure is measured by endpoint version inventory, not open ports. *That is an inference from the product type and bug class.* |
| Disclosure / reporter | User-supplied disclosure date is 2026-06-05. Google's stable bulletin shows the bug was reported by Google on 2026-03-27. |
noisgate verdict.
The single biggest downward driver is that exploitation requires a prior renderer compromise, which means this is a post-initial-access browser-boundary bypass, not a standalone entry point. That prerequisite collapses the reachable population from 'every Chrome user' to 'only users already hit by another working Chrome exploit chain.'
Why this verdict
- Major friction: requires a compromised renderer first — attacker position is no longer simple unauthenticated remote; it implies an earlier successful exploit stage and sharply narrows real deployments that can reach this bug.
- High-complexity chain — the vendor vector already says
AC:HandUI:R, and this sits behind both a user visit and a separate exploit, so each prerequisite compounds downward pressure on patch priority. - Blast radius is browser-session confidentiality, not host takeover — the practical outcome is cross-site data exposure inside the browser boundary, not broad code execution on the endpoint.
Why not higher?
There is no evidence this bug is being exploited on its own, and there is no sign of KEV-level campaign use. More importantly, an attacker must first clear the much harder hurdle of renderer compromise, which means this CVE is a chain enhancer rather than the thing that gets them in.
Why not lower?
It still weakens a meaningful Chrome security boundary: Site Isolation exists specifically to contain hostile renderer processes. In a real exploit chain, bypassing that boundary can turn a contained renderer bug into cross-origin data theft, so this is not pure noise.
What to do — in priority order.
- Enforce browser auto-update — Make sure enterprise Chrome update policy is not pinned below the fixed build and that stalled channels are corrected. For a LOW verdict there is no mitigation SLA and no remediation SLA beyond backlog hygiene, so fold this into your normal browser maintenance cycle rather than interrupt work.
- Keep Site Isolation policy enabled — Verify admins have not weakened Chrome isolation settings for compatibility or memory-saving reasons. This does not fix the bug, but it preserves the broader architectural control and should remain enforced as standard baseline hygiene.
- Prioritize upstream renderer bugs higher — Because this CVE only pays off after renderer compromise, your real risk reducer is fast handling of renderer RCE / sandbox / V8 issues that can serve as the first stage. Treat this finding as chain-hardening and let the more dangerous first-stage Chrome bugs drive urgency.
- A WAF does not help; this is client-side browser logic, not a server request parser issue.
- Network IDS signatures are weak here because the meaningful action is post-compromise behavior inside the browser process, not a clean wire-pattern exploit.
- MFA is irrelevant to the vulnerability itself; it may reduce downstream account abuse, but it does not prevent the Site Isolation bypass.
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint management runner. Invoke it with python3 chrome_check.py or python chrome_check.py; no admin rights are usually needed as long as the Chrome binary is readable. It checks common Chrome install paths, runs --version, and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# chrome_check.py
# Check whether local Google Chrome is at or above the fixed version for CVE-2026-11240.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
FIXED_VERSION = (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 run_version_cmd(path):
try:
result = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=10)
output = (result.stdout or '') + ' ' + (result.stderr or '')
return parse_version(output.strip())
except Exception:
return None
def candidate_paths():
system = platform.system()
paths = []
if system == 'Windows':
env_paths = [
os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
paths.extend(env_paths)
elif system == 'Darwin':
paths.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chromium-browser', 'chromium']:
resolved = shutil.which(name)
if resolved:
paths.append(resolved)
paths.extend([
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
])
# Deduplicate while preserving order
seen = set()
uniq = []
for p in paths:
if p and p not in seen:
seen.add(p)
uniq.append(p)
return uniq
def main():
found = []
for path in candidate_paths():
if os.path.exists(path) or shutil.which(path):
version = run_version_cmd(path)
if version:
found.append((path, version))
if not found:
print('UNKNOWN - Google Chrome not found or version could not be determined')
sys.exit(2)
# Evaluate the highest version found
found.sort(key=lambda x: x[1], reverse=True)
path, version = found[0]
version_str = '.'.join(str(x) for x in version)
fixed_str = '.'.join(str(x) for x in FIXED_VERSION)
if version >= FIXED_VERSION:
print(f'PATCHED - {path} version {version_str} >= fixed {fixed_str}')
sys.exit(0)
else:
print(f'VULNERABLE - {path} version {version_str} < fixed {fixed_str}')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Google Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
- Canadian Centre for Cyber Security advisory AV26-544
- Chromium Site Isolation overview
- Chromium Site Isolation design document
- CISA Known Exploited Vulnerabilities Catalog
- Chromium issue tracker entry 497030032
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.