← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11264 · CWE-693 · Disclosed 2026-06-05

Policy bypass in Content Security Policy in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"This is a browser guardrail bypass, not a clean enterprise compromise path"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Deliver a crafted HTML lure

The attacker hosts or embeds a malicious HTML page designed to trigger the CSP enforcement flaw in Chrome. There is no public named weaponized kit tied to this CVE in the sources reviewed; current tradecraft would be a custom HTML/JS payload built around the browser bug and whatever follow-on web primitive the attacker wants to unlock.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Version-based vulnerability scanners can flag outdated Chrome builds. Content-level detection is weak because a crafted HTML page can look like ordinary web traffic.
STEP 02

Trigger the CSP bypass in the browser

Once rendered, the page abuses the Chrome CSP handling flaw so the browser does not fully enforce a policy the site expected to constrain script or resource execution. The practical value here is not 'the attacker gets code exec on the host'; it is 'the attacker removes a browser-side restriction that web defenders assumed was in place.'
Conditions required:
  • The specific browser code path for the CSP bypass is reachable
  • Victim uses a vulnerable Chrome build
  • The page structure matches the bug trigger
Where this breaks in practice:
  • 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
Detection/coverage: EDR usually will not label this step directly. Browser telemetry, crash data, or forensic reproduction are more realistic than signature detection.
STEP 03

Chain the bypass into meaningful abuse

For material impact, the attacker normally needs a second primitive: an injection point, trusted inline script path, unsafe DOM flow, or application behavior that becomes exploitable once CSP is gone. In other words, the bug is best understood as an amplifier for existing web weaknesses, not a complete compromise chain by itself.
Conditions required:
  • Targeted site or workflow becomes exploitable when CSP is removed
  • Attacker can execute or load content that the original CSP would have blocked
Where this breaks in practice:
  • 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
Detection/coverage: Application security testing and browser-side CSP violation telemetry may reveal the preconditions, but most infrastructure scanners will not prove exploitability end-to-end.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation signal found in reviewed primary sources; CISA KEV does not list this CVE.
Proof-of-concept availabilityNo public PoC repo or named researcher exploit surfaced in reviewed sources. Chromium bug details appear restricted, which slows copycat weaponization.
EPSSUser-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 statusNot KEV-listed as of the reviewed CISA catalog source.
CVSS vector reality checkAV: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 versionsGoogle 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 versionsFix 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 realityThis 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 timelineChrome release note date: 2026-06-02. NVD shows the CVE was received on 2026-06-04 and modified on 2026-06-05.
Reporter / originChrome release notes list it as reported by Google on 2026-04-06.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.7/10)

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.

HIGH Affected/fixed version identification
MEDIUM Real-world exploitability assessment from limited public bug details
HIGH No current KEV or public campaign evidence

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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())
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not burn an emergency change window on this one. For a LOW verdict, the noisgate mitigation SLA is no SLA (treat as backlog hygiene), so there is no mitigation SLA — go straight to normal browser update operations; the noisgate remediation SLA is likewise no SLA/backlog hygiene, which in practice means roll Chrome to 149.0.7827.53 or later in your next standard endpoint/browser wave, while using inventory to make sure no pinned or unmanaged endpoints stay behind indefinitely.

Sources

  1. NVD CVE record
  2. Chrome Releases stable desktop update
  3. Chromium issue reference
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS data and statistics
  6. FIRST EPSS model overview
  7. Chrome Enterprise policy reference based on Chrome 149
  8. GovCERT alert for Chrome 149 update
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.