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

Inappropriate implementation in Permissions in Google Chrome prior to 149

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

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.

"Wide browser footprint, but this is still a click-required policy bypass with narrow real-world payoff"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker HTML

The attacker needs to get a Chrome user to load a crafted page that exercises the flawed 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.
Conditions required:
  • Victim uses vulnerable Chrome or Chromium-based build
  • Victim opens attacker-controlled HTML content
Where this breaks in practice:
  • Email and web filtering routinely suppress initial lure delivery
  • Enterprise browser auto-update shrinks the vulnerable population quickly
  • User interaction is mandatory
Detection/coverage: No vuln scanner sees this from the network edge; detection is mostly browser version inventory plus web proxy/email telemetry for lure delivery.
STEP 02

Trigger the Permissions policy bypass

The crafted page abuses the vulnerable implementation path in 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.
Conditions required:
  • Specific vulnerable code path in Chrome Permissions is reachable
  • The target browsing flow relies on CSP or related browser enforcement for containment
Where this breaks in practice:
  • 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
Detection/coverage: Little to no direct detection coverage. Browser telemetry, crash data, or vendor bug details would be needed; public scanner signatures are unlikely.
STEP 03

Turn the bypass into a useful web attack

To get material impact, the attacker usually has to chain this policy bypass into a broader web objective such as script injection that CSP would otherwise block, UI manipulation, or abuse of a trusted page context. This is where most browser policy-bypass bugs die in the real world: the browser bug exists, but the app-side opportunity is missing.
Conditions required:
  • A target site or internal app is meaningfully protected by the defeated CSP behavior
  • The attacker can align victim browsing with that target context
Where this breaks in practice:
  • 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
Detection/coverage: Application logs and CSP violation telemetry may show odd behavior, but there is no broad commodity detection signature for this CVE alone.
STEP 04

Achieve limited integrity impact

The published impact is low-grade integrity loss, not data theft or system takeover. That lines up with a policy bypass whose practical blast radius is constrained to browser session behavior and only where the surrounding app design makes the bypass matter.
Conditions required:
  • Successful browser-side policy bypass
  • A target workflow where integrity manipulation is possible
Where this breaks in practice:
  • No confidentiality or availability impact is claimed in the vendor vector
  • No evidence of in-the-wild exploitation or KEV inclusion
Detection/coverage: Post-event investigation would rely on browser versioning, user web history, and target app telemetry rather than endpoint exploit artifacts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found; not listed in CISA KEV.
Proof-of-concept availabilityNo 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.
EPSS0.0002 from the user intel block, which is effectively floor-level exploit probability and consistent with a low-signal browser hardening bug.
KEV statusNo; no KEV date because the CVE is absent from the catalog.
CVSS vectorCVSS: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 versionsGoogle 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 versionsGoogle 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 realityNot 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 / reporterDisclosed 2026-06-05; Chrome release notes list it as reported by Google on 2026-04-03.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.3/10)

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.

HIGH Affected/fixed version range
MEDIUM Practical exploitability assessment
MEDIUM Absence of public exploitation or PoC

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:L with 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.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Use your browser-management stack to verify Chrome/Chromium clients converge to 149.0.7827.53+ promptly. For a LOW verdict there is no SLA-driven emergency mitigation, but this should be handled as backlog hygiene and closed during normal endpoint maintenance.
  2. 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.
  3. 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.
  4. Monitor version drift — Build a report for Chrome/Chromium versions older than 149.0.7827.53 across managed endpoints and VDI pools. For LOW, use standard patch hygiene cycles rather than an incident-style campaign.
What doesn't work
  • 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.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning: treat this as low-priority browser hygiene, not an emergency response item. There is no noisgate mitigation SLA for 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

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Google Chrome Releases - Early Stable Update for Desktop
  3. Google Chrome Releases - Chrome Beta for Desktop Update
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS API documentation
  7. openSUSE Chromium patchinfo for 149.0.7827.53 security fixes
  8. Canadian Centre for Cyber Security advisory for Chrome 149.0.7827.53/54
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.