This is like finding a side gate around a fence, not a key to the building
CVE-2026-11264 is a policy bypass in Chrome's Content Security Policy handling affecting Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS. A remote attacker can deliver a crafted HTML page that bypasses CSP, which means the browser may fail to enforce a site's intended restrictions on where scripts or other active content can load from.
The vendor's MEDIUM 4.3 is already somewhat generous for enterprise patch triage. In real-world terms this is usually a chainable weakening of a defense-in-depth control, not a stand-alone foothold: it still needs user interaction, and meaningful damage typically depends on a second condition such as a site-side injection primitive or a workflow that trusted CSP as the last line of defense.
3 steps from start to impact.
Deliver a crafted HTML lure
- Target is running Chrome below 149.0.7827.53
- Attacker can get the victim to open attacker-controlled web content
- Normal web rendering and JavaScript are enabled
- Requires user interaction; this is not a server-side scan-and-hit issue
- Enterprise web filtering, email security, and browser isolation can block the lure before render
- No evidence of a turnkey public exploit kit lowers opportunistic abuse
Trigger the CSP bypass in the browser
- The specific browser code path for the CSP bypass is reachable
- Victim uses a vulnerable Chrome build
- The page structure matches the bug trigger
- CSP is a mitigation layer, so bypassing it does not automatically create a full exploit outcome
- Some targets will not rely on CSP for anything safety-critical
- Restricted bug details reduce commodity attacker replication
Chain the bypass into meaningful abuse
- Targeted site or workflow becomes exploitable when CSP is removed
- Attacker can execute or load content that the original CSP would have blocked
- Without a second bug or unsafe application behavior, the blast radius is often limited
- Modern web apps may have server-side output encoding, Trusted Types, or framework controls that still block abuse
- This does not inherently grant cross-origin data theft, sandbox escape, or host code execution
The supporting signals.
| In-the-wild status | No public exploitation signal found in reviewed primary sources; CISA KEV does not list this CVE. |
|---|---|
| Proof-of-concept availability | No public PoC repo or named researcher exploit surfaced in reviewed sources. Chromium bug details appear restricted, which slows copycat weaponization. |
| EPSS | User-supplied EPSS is 0.00026; that is effectively near-floor probability for next-30-day exploitation. Percentile was not independently verified from a per-CVE FIRST record during this review. |
| KEV status | Not KEV-listed as of the reviewed CISA catalog source. |
| CVSS vector reality check | AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N is directionally fair: remote, no auth, but user interaction required and only low integrity impact. The important practical nuance is that this is a policy bypass, not direct code execution. |
| Affected versions | Google states Chrome prior to 149.0.7827.53 is affected; the desktop stable rollout shipped 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). |
| Fixed versions | Fix landed in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS. Managed enterprise fleets should use their standard Chrome channel/update controls to confirm rollout. |
| Exposure / scanning reality | This is not an internet-scannable server exposure. Shodan/Censys-style counting is mostly irrelevant because the attack surface is the client browser fleet, and exploitation requires the victim to browse attacker-controlled content. |
| Disclosure timeline | Chrome release note date: 2026-06-02. NVD shows the CVE was received on 2026-06-04 and modified on 2026-06-05. |
| Reporter / origin | Chrome release notes list it as reported by Google on 2026-04-06. |
noisgate verdict.
The decisive downgrade factor is that this bug does not create a primary enterprise compromise path by itself; it removes a browser-side guardrail and usually needs a second web-app weakness to matter. Add the required user interaction and lack of exploitation evidence, and this falls below the patch-now crowd despite Chrome's huge footprint.
Why this verdict
- Start from the vendor 4.3 baseline: remote delivery and no authentication would normally keep this in play for a ubiquitous browser.
- Downward adjustment for user interaction: the attacker needs the victim to render attacker-controlled HTML, which cuts this out of the unauthenticated, wormable, or scan-to-own class.
- Downward adjustment for chain dependency: a CSP bypass usually weakens a defense layer rather than creating a self-sufficient exploit; meaningful abuse often needs an additional injection or unsafe app condition.
- Downward adjustment for narrow practical blast radius: this is a client-side browser issue, not a server service that exposes thousands of enterprise nodes to direct internet probing.
- Downward adjustment for threat intel: no KEV entry, no reviewed public exploitation reporting, and a near-floor EPSS all argue against emergency handling.
Why not higher?
If this were a sandbox escape, SOP bypass with clear data theft, or a drive-by RCE, the story would change immediately. But the current public description only supports policy bypass of CSP, which is usually an enabling condition inside a larger chain, not the chain itself.
Why not lower?
It is still a browser security boundary regression in one of the most widely deployed enterprise applications on earth. If an attacker already has a convincing lure and a compatible web-app weakness to pair with it, the bypass can remove a meaningful protective layer, so this is not pure paperwork.
What to do — in priority order.
- Accelerate managed browser auto-update — Make sure Chrome stable-channel auto-update is actually reaching endpoints, especially unmanaged laptops and VDI gold images. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene and fold it into the next normal browser rollout rather than launching an exception process.
- Reduce exposure to untrusted web content — Keep or tighten browser isolation, URL filtering, and attachment-to-browser detonation for high-risk user groups so fewer users ever render attacker-crafted HTML. Again, for LOW, there is no mitigation SLA; do this on your standard control-tuning cadence.
- Hunt for outdated Chrome pockets — Use EDR, software inventory, or Google Admin telemetry to find endpoints pinned below 149.0.7827.53 because those are where browser bugs linger longest. For LOW, handle during normal vulnerability hygiene work rather than interrupt-driven response.
- A network perimeter scanner will not tell you whether users can be exploited; this is a client-side browser issue, not an exposed listening service.
- MFA does nothing for the vulnerable code path; the attacker is targeting browser rendering logic, not account login.
- A WAF only helps for your own web apps and does not protect users browsing arbitrary external content.
- Assuming CSP alone saves you is exactly the wrong lesson here; this bug is about bypassing that policy layer.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR/RMM script runner to verify the locally installed Chrome/Chromium version. Invoke it as python3 check_cve_2026_11264.py on Linux/macOS or py check_cve_2026_11264.py on Windows; no admin rights are usually required, but local filesystem access to standard install paths is needed.
#!/usr/bin/env python3
# CVE-2026-11264 Chrome version check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from typing import List, Optional, Tuple
FIXED = (149, 0, 7827, 53)
def parse_version(text: str) -> Optional[Tuple[int, ...]]:
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_to_str(v: Tuple[int, ...]) -> str:
return '.'.join(str(x) for x in v)
def compare_versions(a: Tuple[int, ...], b: Tuple[int, ...]) -> int:
la = list(a)
lb = list(b)
maxlen = max(len(la), len(lb))
la += [0] * (maxlen - len(la))
lb += [0] * (maxlen - len(lb))
if la < lb:
return -1
if la > lb:
return 1
return 0
def run_and_get_version(cmd: List[str]) -> Optional[Tuple[int, ...]]:
try:
out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=5)
return parse_version(out.strip())
except Exception:
return None
def windows_candidates() -> List[List[str]]:
candidates = []
env_paths = [
os.environ.get('ProgramFiles'),
os.environ.get('ProgramFiles(x86)'),
os.environ.get('LocalAppData'),
]
suffixes = [
r'Google\Chrome\Application\chrome.exe',
r'Chromium\Application\chrome.exe',
]
for base in env_paths:
if not base:
continue
for suffix in suffixes:
full = os.path.join(base, suffix)
if os.path.exists(full):
candidates.append([full, '--version'])
return candidates
def mac_candidates() -> List[List[str]]:
paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
]
return [[p, '--version'] for p in paths if os.path.exists(p)]
def linux_candidates() -> List[List[str]]:
names = [
'google-chrome',
'google-chrome-stable',
'chromium',
'chromium-browser',
]
return [[n, '--version'] for n in names]
def collect_versions() -> List[Tuple[str, Tuple[int, ...]]]:
found = []
system = platform.system().lower()
if 'windows' in system:
cmds = windows_candidates()
elif 'darwin' in system:
cmds = mac_candidates()
else:
cmds = linux_candidates()
seen = set()
for cmd in cmds:
key = ' '.join(cmd)
if key in seen:
continue
seen.add(key)
version = run_and_get_version(cmd)
if version:
found.append((cmd[0], version))
return found
def main() -> int:
versions = collect_versions()
if not versions:
print('UNKNOWN: Chrome/Chromium not found or version not readable')
return 2
vulnerable = []
patched = []
for path, version in versions:
if compare_versions(version, FIXED) < 0:
vulnerable.append((path, version))
else:
patched.append((path, version))
for path, version in versions:
status = 'VULNERABLE' if compare_versions(version, FIXED) < 0 else 'PATCHED'
print(f'{status}: {path} -> {version_to_str(version)}')
if vulnerable:
print(f'VULNERABLE: one or more installed browsers are below fixed version {version_to_str(FIXED)}')
return 1
print(f'PATCHED: all detected browsers meet or exceed fixed version {version_to_str(FIXED)}')
return 0
if __name__ == '__main__':
sys.exit(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.