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

Insufficient policy enforcement in Blink in Google Chrome prior to 149

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

Like finding a side door around the bouncer rather than breaking into the vault

CVE-2026-11292 is a Blink content security policy (CSP) bypass in Google Chrome before 149.0.7827.53. An attacker can lure a user to a crafted HTML page and get Blink to misapply or bypass CSP restrictions that a site expected the browser to enforce. Affected builds are Chrome versions prior to 149.0.7827.53 on platforms that consume that Chromium code; distro packages may ship the fix as a backport rather than the exact upstream version string.

The vendor's MEDIUM 4.3 baseline is already conservative, and in enterprise reality I would push it down to LOW. The decisive friction is that this is not code execution, not sandbox escape, and not a direct data-theft primitive; it is a client-side policy bypass that still needs user interaction and usually only becomes materially dangerous when paired with a separate web-app weakness or a very specific site workflow that relies on CSP as the last guardrail.

"This is a browser-policy paper cut, not a workstation takeover path"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker HTML

The weaponized tool is just a crafted HTML page delivered by phishing, malvertising, or a compromised site. The attacker position is unauthenticated remote, but the chain starts only if the target user loads the page in a vulnerable Chrome build.
Conditions required:
  • Victim is running Chrome or Chromium-based package with vulnerable Blink code
  • Victim browses to attacker-controlled or attacker-influenced content
  • Chrome build is older than 149.0.7827.53 or lacks the backported fix
Where this breaks in practice:
  • Requires user interaction
  • Enterprise web filtering, Safe Browsing, email security, and link rewriting remove a lot of delivery volume
  • Browsers auto-update aggressively in managed fleets
Detection/coverage: Email and web gateways may catch delivery. Traditional vuln scanners have poor coverage for client-side reachability; version-based EDR or software inventory is the practical detection path.
STEP 02

Trigger Blink policy bypass

The page abuses the Blink flaw so CSP restrictions are not enforced the way the target site expects. The practical tool here is the browser engine itself; I found no public PoC repo or named exploit kit tied to this CVE as of 2026-06-05.
Conditions required:
  • Specific vulnerable rendering path is reachable from web content
  • Relevant CSP-protected action exists to be bypassed
Where this breaks in practice:
  • No public exploit code located
  • Many sites do not depend on CSP alone for critical trust decisions
  • Browser security features like Site Isolation do not disappear just because CSP is bypassed
Detection/coverage: Network scanners will not see this. Browser crash telemetry is not useful because this is a policy bypass, not a memory-corruption crash signature.
STEP 03

Convert policy bypass into site-level abuse

If the target workflow is right, the attacker can execute actions or content that a site's CSP would normally block, creating an XSS-like integrity failure inside the browser. This can enable script execution, UI manipulation, or policy-evading content loads within the browser context of the affected web interaction.
Conditions required:
  • The protected application actually relies on CSP to block the dangerous action
  • The attacker can meaningfully benefit from that bypass in the rendered page
Where this breaks in practice:
  • Often needs a second weakness or unsafe page design to become business-impacting
  • Impact is usually limited to web-session abuse, not host compromise
  • MFA, transaction signing, and server-side validation still block many end goals
Detection/coverage: Some CSP-violation logging may go quiet rather than light up, because the point is that enforcement failed. Detection is more likely from anomalous web-session behavior in app logs than from endpoint AV.
STEP 04

Impact stays inside the browser lane

The realistic outcome is low-integrity web abuse, not endpoint takeover. You are looking at phishing-style UI deception, script execution where CSP should have blocked it, or abuse of a web session—not a direct path to arbitrary code on the workstation.
Conditions required:
  • User session has value to the attacker
  • Business app permits meaningful actions from the browser session
Where this breaks in practice:
  • No sandbox escape or RCE claim in the advisory
  • No evidence of in-the-wild exploitation or KEV listing
  • Blast radius is normally per-user, per-session
Detection/coverage: Browser version inventory will find exposure; behavioral detections depend on the downstream app abuse, not this CVE itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in reviewed sources, and not listed in CISA KEV as of 2026-06-05.
Proof-of-concept availabilityNo public PoC repo or named researcher release located in reviewed sources as of 2026-06-05.
EPSS0.00026 from the user-supplied intel, which is effectively floor-level exploit probability and consistent with a low-priority client-side bug.
KEV statusNot KEV-listed; CISA's catalog page reviewed with no indication this CVE is currently in the known-exploited set.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N = remote and easy to trigger once a user loads content, but impact is only low integrity with no confidentiality or availability claim.
Affected versionsGoogle Chrome prior to 149.0.7827.53; downstream Chromium consumers may inherit the bug until they pull or backport the fix.
Fixed versionsUpstream fix lands in 149.0.7827.53. openSUSE explicitly lists Chromium 149 (149.0.7827.53) as fixing CVE-2026-11292; other distros may backport without matching the upstream version string.
Exposure populationThis is a client-side browser bug, so Shodan/Censys/FOFA-style internet scans are not a meaningful exposure metric. The practical exposure amplifier is product prevalence: Statcounter shows Chrome holding about 59.63% U.S. desktop+tablet browser share in April 2026.
Disclosure timelineUser-supplied disclosure date is 2026-06-05. Google published the relevant 149.0.7827.53/.54 early stable desktop release on 2026-05-29.
Historical patternThis bug class is recurring but usually lands in the low-to-medium band. Similar Blink/CSP bypasses include CVE-2021-4321 and CVE-2022-0117, which reinforce that this is usually a web-session abuse issue, not an endpoint-compromise issue.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.1/10)

The single biggest downward force is that this is a client-side policy bypass with user interaction and low-impact outcome, not a host-compromise primitive. Even though Chrome is ubiquitous, the blast radius is usually confined to one browsing session and typically needs a second web-app weakness or risky workflow to matter.

HIGH Version range and fixed build
MEDIUM Real-world impact staying in the LOW bucket
MEDIUM Lack of public exploitation or PoC as of 2026-06-05

Why this verdict

  • User interaction cuts this down immediately: the attacker must get a user to open crafted web content, which means delivery controls and browser auto-update shrink reach.
  • Impact is narrow: the published vector is only I:L with C:N/A:N, so this is not an RCE, sandbox escape, credential dump, or workstation persistence path by itself.
  • Exploit economics are poor: EPSS is effectively negligible, there is no KEV listing, and I found no public PoC or campaign signal.
  • The prerequisite implies a browser-session attack, not initial compromise at scale: you need vulnerable client browsers and a web scenario where bypassing CSP actually changes the outcome.
  • Widespread Chrome deployment is the only real amplifier: if this were paired with a broadly exploitable web-app condition, prevalence would matter more, but the standalone CVE does not justify MEDIUM urgency across 10,000 hosts.

Why not higher?

A higher rating would require either endpoint compromise potential, credible evidence of active exploitation, or a downstream impact stronger than low-integrity web abuse. None of that is present here. This is a security-boundary weakening inside the browser, but it does not by itself hand over the machine or the enterprise.

Why not lower?

It is not IGNORE because CSP exists to contain exactly the kind of script and content abuse attackers want, and bypassing it can still matter for sensitive apps. Chrome is also massively deployed, so even a modest per-user issue can become noisy if patch hygiene is poor.

05 · Compensating Control

What to do — in priority order.

  1. Force browser evergreen compliance — Use your endpoint manager to verify Chrome and Chromium-family packages are auto-updating and restarting cleanly. For a LOW verdict there is no SLA (treat as backlog hygiene), but this is still the cleanest control because it removes the vulnerable engine rather than trying to detect a subtle policy bypass.
  2. Prioritize high-risk user groups — If you cannot patch uniformly, move admins, finance users, and users handling sensitive SaaS sessions to the fixed build first. There is no SLA (treat as backlog hygiene) for LOW, so use normal change windows, but do not leave privileged browsing tiers on stale versions.
  3. Use remote browser isolation where already deployed — For untrusted web destinations, RBI can reduce the chance that a crafted page reaches a vulnerable local rendering path. This is a containment measure, not a substitute for patching, and for LOW there is no SLA (treat as backlog hygiene).
  4. Watch managed-browser inventory, not network scanners — Track exposure through EDR, MDM, software inventory, or browser management consoles because this bug is on the endpoint, not on a listening port. For LOW, there is no SLA (treat as backlog hygiene), so use routine asset-hygiene reporting rather than an emergency hunt.
What doesn't work
  • A WAF does not fix a browser engine enforcement flaw on the client side.
  • Tweaking server-side CSP headers alone does not help if the vulnerable browser is the thing failing to enforce them.
  • External attack-surface scanners are mostly useless here because this is not an internet-facing service vulnerability.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software-inventory agent anywhere Python 3 is available. Invoke it as python3 chrome_cve_2026_11292_check.py; it needs only normal user privileges and checks common Chrome/Chromium install locations on Windows, macOS, and Linux, then reports VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check exposure to CVE-2026-11292 (Chrome/Blink CSP bypass)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from typing import Optional, List, Tuple

FIXED = (149, 0, 7827, 53)


def parse_version(text: str) -> Optional[Tuple[int, int, int, 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 cmp_ver(a: Tuple[int, int, int, int], b: Tuple[int, int, int, int]) -> int:
    return (a > b) - (a < b)


def run_cmd(cmd: List[str]) -> Optional[str]:
    try:
        out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
        return out.strip()
    except Exception:
        return None


def windows_candidates() -> List[List[str]]:
    cmds = []
    local = os.environ.get('LOCALAPPDATA', '')
    pf = os.environ.get('PROGRAMFILES', '')
    pfx86 = os.environ.get('PROGRAMFILES(X86)', '')
    paths = [
        os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(pfx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(local, 'Chromium', 'Application', 'chrome.exe'),
        os.path.join(pf, 'Chromium', 'Application', 'chrome.exe'),
        os.path.join(pfx86, 'Chromium', 'Application', 'chrome.exe'),
        os.path.join(pf, 'Microsoft', 'Edge', 'Application', 'msedge.exe'),
        os.path.join(pfx86, 'Microsoft', 'Edge', 'Application', 'msedge.exe'),
    ]
    for p in paths:
        if p and os.path.exists(p):
            cmds.append([p, '--version'])
    return cmds


def unix_candidates() -> List[List[str]]:
    bins = [
        'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser',
        'microsoft-edge', 'microsoft-edge-stable',
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
        '/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge',
    ]
    cmds = []
    for b in bins:
        if os.path.isabs(b):
            if os.path.exists(b):
                cmds.append([b, '--version'])
        else:
            p = shutil.which(b)
            if p:
                cmds.append([p, '--version'])
    return cmds


def main() -> int:
    system = platform.system().lower()
    candidates = windows_candidates() if system == 'windows' else unix_candidates()

    if not candidates:
        print('UNKNOWN - No Chrome/Chromium-based browser executable found in common locations')
        return 2

    found = []
    for cmd in candidates:
        out = run_cmd(cmd)
        if not out:
            continue
        ver = parse_version(out)
        if ver:
            found.append((' '.join(cmd[:-1]), ver, out))

    if not found:
        print('UNKNOWN - Browser found but version could not be determined')
        return 2

    # Report the lowest discovered Chromium-family version; if any are vulnerable, call host vulnerable.
    vulnerable = []
    patched = []
    for name, ver, raw in found:
        if cmp_ver(ver, FIXED) < 0:
            vulnerable.append((name, ver, raw))
        else:
            patched.append((name, ver, raw))

    def fmt(v):
        return '.'.join(str(x) for x in v)

    if vulnerable:
        details = '; '.join(f'{name}={fmt(ver)}' for name, ver, _ in vulnerable)
        print(f'VULNERABLE - Found Chromium-family browser(s) below fixed version {fmt(FIXED)}: {details}')
        return 1

    details = '; '.join(f'{name}={fmt(ver)}' for name, ver, _ in patched)
    print(f'PATCHED - All discovered Chromium-family browser(s) are at or above fixed version {fmt(FIXED)}: {details}')
    return 0


if __name__ == '__main__':
    sys.exit(main())
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat this like an emergency Chrome fire drill. Because the reassessed severity is LOW, there is no noisgate mitigation SLA and no noisgate remediation SLA—treat it as backlog hygiene and fold it into your normal evergreen browser maintenance cycle, with extra attention to privileged-user tiers and any Chromium packages that lag vendor auto-update behavior.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. openSUSE patchinfo - Chromium 149 security fixes including CVE-2026-11292
  3. CISA Known Exploited Vulnerabilities Catalog
  4. FIRST EPSS overview
  5. FIRST EPSS API documentation
  6. Statcounter U.S. desktop and tablet browser market share
  7. NVD - CVE-2021-4321 similar Blink CSP bypass
  8. NVD - CVE-2022-0117 similar Blink policy bypass
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.