This is a cracked window latch, not an unlocked front door
CVE-2026-11260 is a Chrome Permissions policy-bypass bug that can let a remote attacker defeat Content Security Policy controls via a crafted HTML page. The affected range is Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows and macOS; downstream Chromium builds inherit the issue until their vendor ships the 149 fixes or backports them.
The vendor's MEDIUM 4.3 baseline is already conservative, and in enterprise reality I'd push it down another notch. The decisive friction is that this is *not* code execution, *not* sandbox escape, and *not* a direct origin compromise by itself; the attacker still needs a user to render attacker-controlled content and then needs a site or workflow where bypassing CSP actually changes the outcome.
4 steps from start to impact.
Land the victim on attacker HTML
Permissions behavior. This is standard browser-delivery tradecraft: phishing, malvertising, chat links, or a compromised site. No authentication or local foothold is required, but user interaction is.- Victim uses vulnerable Chrome or Chromium-based build
- Victim opens attacker-controlled HTML content
- Email and web filtering routinely suppress initial lure delivery
- Enterprise browser auto-update shrinks the vulnerable population quickly
- User interaction is mandatory
Trigger the Permissions policy bypass
Permissions to bypass a policy boundary tied to CSP behavior. The bug weakens a browser-side protection mechanism, but it does not inherently grant arbitrary script execution on every site; exploit value depends on the surrounding web application context.- Specific vulnerable code path in Chrome Permissions is reachable
- The target browsing flow relies on CSP or related browser enforcement for containment
- Many sites treat CSP as defense-in-depth rather than the sole control
- Modern apps often have additional server-side validation and origin checks
- Exact exploitability may be site-specific
Turn the bypass into a useful web attack
- A target site or internal app is meaningfully protected by the defeated CSP behavior
- The attacker can align victim browsing with that target context
- Requires a compatible target application pattern, not just a vulnerable browser
- Cross-origin and server-side controls may still block impact
- No public exploit chain was located
Achieve limited integrity impact
- Successful browser-side policy bypass
- A target workflow where integrity manipulation is possible
- No confidentiality or availability impact is claimed in the vendor vector
- No evidence of in-the-wild exploitation or KEV inclusion
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found; not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC or exploit repo located in quick-source review. That matters because browser policy-bypass bugs often stay non-weaponized unless they chain cleanly into a high-value web target. |
| EPSS | 0.0002 from the user intel block, which is effectively floor-level exploit probability and consistent with a low-signal browser hardening bug. |
| KEV status | No; no KEV date because the CVE is absent from the catalog. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N — remote and easy to reach, but requires user interaction and only yields low integrity impact. |
| Affected versions | Google Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows/macOS; Chromium downstreams are affected until they ship equivalent fixes or backports. |
| Fixed versions | Google fixed this in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). openSUSE also shipped Chromium security fixes for 149.0.7827.53, indicating downstream distro backport/adoption activity. |
| Scanning / exposure reality | Not meaningfully internet-scannable via Shodan/Censys/FOFA because this is a client-side browser flaw. Exposure measurement is endpoint inventory and browser-version telemetry, not edge attack-surface scanning. |
| Disclosure / reporter | Disclosed 2026-06-05; Chrome release notes list it as reported by Google on 2026-04-03. |
noisgate verdict.
The single most important downward pressure is that this bug only becomes valuable when a user loads attacker content *and* the target browsing scenario depends on CSP enforcement strongly enough that bypassing it changes the outcome. That makes it a real security defect, but not a fleet-wide fire drill for a 10,000-endpoint enterprise estate.
Why this verdict
- User interaction required: the chain starts with a victim opening attacker HTML, which is immediate downward pressure versus silent drive-by RCE.
- Impact is narrow: vendor vector shows only
I:Lwith no confidentiality or availability loss, so this is a browser-policy weakening issue, not host compromise. - App-context dependency: bypassing CSP only matters where the target site or workflow actually relies on CSP for meaningful containment; many real deployments have additional controls.
- No exploitation signal: no KEV listing, no public exploit reporting, and an EPSS value near zero all argue against urgent attacker interest.
- Exposure is broad but shallow: Chrome is everywhere, which keeps this from being
IGNORE, but browser ubiquity alone does not overcome the chain friction.
Why not higher?
If this were a renderer RCE, sandbox escape, same-origin bypass with data theft, or a KEV-listed browser 0-day, the call would move sharply upward. Here, the attacker gets a protection bypass with limited integrity impact and still needs a favorable web-app context, which is too much friction for MEDIUM or above in enterprise prioritization.
Why not lower?
I am not dropping this to IGNORE because browsers are high-frequency exposure points and a policy bypass can become useful when paired with weak web application design. Also, Chrome's install base means even a low-grade client-side bug can touch a very large victim population before auto-update converges.
What to do — in priority order.
- Force browser auto-update compliance — Use your browser-management stack to verify Chrome/Chromium clients converge to
149.0.7827.53+promptly. For aLOWverdict there is no SLA-driven emergency mitigation, but this should be handled as backlog hygiene and closed during normal endpoint maintenance. - Reduce untrusted web delivery — Tighten email-link detonation, safe browsing, and web filtering for newly registered domains and ad-tech heavy categories, because the exploit path begins with attacker HTML. Do this in normal operations; it reduces exposure even if some endpoints lag patching.
- Prefer strict site isolation and enterprise browsing controls — Maintain browser hardening baselines such as site isolation defaults, extension allowlisting, and risky-site isolation through your enterprise browser policy set. These do not 'fix' the bug, but they reduce the odds that a CSP bypass cleanly chains into meaningful business impact.
- Monitor version drift — Build a report for Chrome/Chromium versions older than
149.0.7827.53across managed endpoints and VDI pools. ForLOW, use standard patch hygiene cycles rather than an incident-style campaign.
- A network IDS signature for the CVE alone won't help much, because this is a client-side browser logic flaw with site-specific triggering rather than a stable wire signature.
- Perimeter vulnerability scanners won't find it, because the vulnerable asset is the endpoint browser, not an exposed server service.
- Relying on CSP headers from your own applications does not remediate the browser defect; the point of the bug is that browser-side enforcement can be bypassed.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR/live-response shell. Invoke it with python3 check_chrome_cve_2026_11260.py on Linux/macOS or py check_chrome_cve_2026_11260.py on Windows; no admin rights are normally required, though some managed install paths may need read access.
#!/usr/bin/env python3
# check_chrome_cve_2026_11260.py
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
PATCH_MIN = (149, 0, 7827, 53)
WIN_ALT_PATCH = (149, 0, 7827, 54) # Windows/macOS may report .54
def parse_version(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text or '')
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_version(a, b):
return (a > b) - (a < b)
def version_is_patched(v):
if v is None:
return None
return cmp_version(v, PATCH_MIN) >= 0
def run(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def get_version_from_command(cmd):
out = run(cmd)
return parse_version(out), out
def get_windows_file_version(path):
if not os.path.exists(path):
return None, ''
ps = [
'powershell', '-NoProfile', '-Command',
f"(Get-Item '{path}').VersionInfo.ProductVersion"
]
out = run(ps)
return parse_version(out), out
def collect_versions():
findings = []
system = platform.system().lower()
if system == 'windows':
paths = [
os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles%\Chromium\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Chromium\Application\chrome.exe'),
]
for p in paths:
v, raw = get_windows_file_version(p)
if v:
findings.append((p, v, raw))
else:
candidates = [
'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser',
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
'/usr/bin/google-chrome', '/usr/bin/google-chrome-stable',
'/usr/bin/chromium', '/usr/bin/chromium-browser',
'/snap/bin/chromium'
]
seen = set()
for c in candidates:
target = shutil.which(c) if not c.startswith('/') else (c if os.path.exists(c) else None)
if not target or target in seen:
continue
seen.add(target)
v, raw = get_version_from_command([target, '--version'])
if v:
findings.append((target, v, raw))
return findings
def main():
findings = collect_versions()
if not findings:
print('UNKNOWN - Could not identify a local Chrome/Chromium installation or parse its version.')
sys.exit(2)
vulnerable = []
patched = []
for path, version, raw in findings:
if version_is_patched(version):
patched.append((path, version))
else:
vulnerable.append((path, version))
if vulnerable:
details = ', '.join([f'{p}={".".join(map(str, v))}' for p, v in vulnerable])
print(f'VULNERABLE - Found Chrome/Chromium versions below 149.0.7827.53: {details}')
sys.exit(1)
details = ', '.join([f'{p}={".".join(map(str, v))}' for p, v in patched])
print(f'PATCHED - All detected Chrome/Chromium installations are at or above 149.0.7827.53: {details}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
LOW, so do not burn incident bandwidth on compensating controls beyond your normal browser hardening baseline; instead, move straight to normal patch governance and complete browser updates within the noisgate remediation SLA for LOW issues, which is no SLA — treat as backlog hygiene. In practice, that means verify auto-update health this week, sweep stragglers in the next routine endpoint cycle, and document any unmanaged Chromium forks that may lag Google's 149.0.7827.53 fix train.Sources
- Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
- Google Chrome Releases - Early Stable Update for Desktop
- Google Chrome Releases - Chrome Beta for Desktop Update
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS API documentation
- openSUSE Chromium patchinfo for 149.0.7827.53 security fixes
- Canadian Centre for Cyber Security advisory for Chrome 149.0.7827.53/54
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.