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

Insufficient validation of untrusted input in ANGLE in Google Chrome prior to 149

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

This is a sharp blade hidden inside a web page, not a grenade tossed through your firewall

CVE-2026-11066 is an improper input validation flaw in Chrome's ANGLE graphics layer that can let a remote attacker *potentially perform a sandbox escape* through a crafted HTML page. Affected desktop builds are Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows and macOS, based on Google's June 2026 release notes and NVD's affected CPE range.

The vendor-side scoring says CRITICAL 9.6, but the real-world shape is narrower: this is a client-side, user-driven browser exploit path, not an unauthenticated internet-facing service bug. Chromium itself labeled it Medium, there is no KEV entry, no public exploitation evidence surfaced in the sources reviewed, and the EPSS supplied is extremely low, so this deserves a downgrade from panic-tier to important-but-routine enterprise browser patching.

"Serious browser bug, but not a drop-everything critical: no KEV, no public PoC, and it still needs a user to hit the trap page."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Deliver a crafted web page

The attacker needs to get a user onto a malicious page that exercises ANGLE through browser-rendered content, most plausibly graphics-heavy HTML/JS paths. There is no indication from the sources reviewed that this is a drive-by at network edge scale; the entry point is still a browser session, not an exposed daemon. Reference: NVD, Chrome stable release.
Conditions required:
  • Target is running vulnerable Chrome desktop builds before 149.0.7827.53
  • User interaction occurs (UI:R) by opening or being redirected to the malicious page
  • ANGLE-reachable rendering path is available in the victim browser session
Where this breaks in practice:
  • Secure web gateways, browser isolation, URL filtering, and phishing-resistant user workflows cut reachability
  • This is endpoint-delivered; there is no broad internet scanning or mass exploit spray against a single TCP service
  • Chrome auto-update collapses exposure windows quickly in well-managed fleets
Detection/coverage: Traditional network vulnerability scanners generally miss this. Detection is primarily version/inventory based from endpoint management, EDR, or browser management telemetry.
STEP 02

Trigger the ANGLE validation flaw

Once the page is rendered, attacker-controlled content drives the vulnerable ANGLE code path. The published description says the outcome is *potential sandbox escape*, which means the exploit has to do more than just crash a tab; it must successfully cross Chrome's containment boundary. Reference: NVD, VulDB summary.
Conditions required:
  • Exploit reliably reaches the vulnerable ANGLE path
  • Victim environment is susceptible to the specific rendering conditions the exploit expects
Where this breaks in practice:
  • Browser sandbox escape chains are typically less reliable than ordinary renderer bugs
  • Hardware/driver/rendering differences can make real-world weaponization brittle
  • No public PoC was found in the sources reviewed, which usually slows copycat exploitation
Detection/coverage: Exploit-specific signatures are unlikely this early. EDR/browser crash telemetry, anomalous child-process behavior, and exploit mitigations are better bets than perimeter IDS.
STEP 03

Convert browser compromise into endpoint impact

If the sandbox escape works, the attacker moves from browser content execution toward host-level impact on that single endpoint. That is serious, but it is still one user, one browser session, one workstation at a time rather than an unauthenticated takeover of a server farm. Reference: CVSS vector in NVD.
Conditions required:
  • Successful sandbox escape, not just renderer compromise or denial of service
  • Victim endpoint has meaningful downstream access or data worth stealing
Where this breaks in practice:
  • EDR, application control, privilege management, and browser isolation can limit post-exploit follow-on actions
  • Blast radius is bounded to compromised endpoints; there is no inherent fleet-wide wormability in the CVE description
Detection/coverage: EDR should be the main control for follow-on behavior. Network scanners will not see post-browser exploitation unless it turns into observable command-and-control or lateral movement.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence of active exploitation was found in the reviewed sources, and the CVE is not in CISA KEV as of 2026-06-05.
Public PoC availabilityNo public GitHub or researcher PoC surfaced in the web review. That does not mean none exists privately, but there is no obvious copy-paste exploit signal yet.
EPSS0.00047 (~0.047% probability over 30 days, per user-supplied intel). Percentile was not authoritatively confirmed in the reviewed sources.
KEV status and datesNot KEV-listed. Reviewed against the CISA KEV catalog on 2026-06-05.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H means remote delivery with no auth, but it still needs user interaction and aims for cross-sandbox impact rather than a simple tab crash.
Vendor vs. Chromium severityNVD shows CISA-ADP 9.6 / CRITICAL, while the vulnerability description itself states Chromium security severity: Medium. That mismatch is the main clue to reassess rather than inherit the top-line score.
Affected versionsChrome prior to 149.0.7827.53 on Linux, and prior to 149.0.7827.53/.54 on Windows and macOS, per Google's stable release note and NVD.
Fixed versions / backportsFixed in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). No distro-specific backport details were identified in the reviewed sources.
Scanning / exposure dataThis is not meaningfully Shodan/Censys/FOFA-scannable because Chrome is endpoint software, not an internet-facing service. Exposure is determined by fleet versioning and user browsing, not open ports.
Disclosure / reporterDisclosed 2026-06-04 in NVD intake; Google's stable release notes say reported by Google on 2026-04-03 under bug 499124128.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (7.8/10)

The decisive downgrade factor is that this bug requires the user to browse into the exploit path; it is not a remotely reachable server flaw that an attacker can spray across the enterprise from the outside. It still lands in HIGH because Chrome is ubiquitous and the stated impact is a potential sandbox escape, which can turn a single web visit into endpoint compromise.

HIGH Affected version and fix-version mapping
MEDIUM Severity downgrade versus vendor/CISA-ADP score
MEDIUM Assessment that there is no public exploitation signal as of 2026-06-05

Why this verdict

  • User interaction requirement pulls this down: UI:R means the attacker still needs a lure, redirect, or malicious site visit. That is a real choke point modern web filtering, isolation, and user workflow controls can disrupt.
  • Client-side delivery narrows exposed population: this is a browser-on-endpoints problem, not a public-facing appliance or server bug. There is no broad unauthenticated internet attack surface to sweep with scanners, which reduces operational exploitability at enterprise scale.
  • Exploit signal is weak so far: no KEV listing, no public PoC found, and the supplied EPSS of 0.00047 is extremely low. That combination argues against inheriting the full 9.6 panic score.
  • Chromium's own label matters: the CNA description explicitly says *Chromium security severity: Medium*. When the upstream product team and the CVSS math disagree this sharply, practitioners should trust the friction in the attack path, not the abstract impact ceiling.

Why not higher?

There is no current evidence of in-the-wild exploitation, no KEV listing, and no public exploit artifact in the reviewed sources. More importantly, the bug is still gated behind a user browsing event, which materially changes patch priority versus remotely reachable pre-auth server CVEs.

Why not lower?

A browser-to-endpoint sandbox escape is not hygiene fluff. Chrome is deployed everywhere, the attacker needs no credentials, and a successful hit can compromise a workstation with all the downstream identity and data access that implies.

05 · Compensating Control

What to do — in priority order.

  1. Force Chrome auto-update and restart compliance — Use Chrome Enterprise policy, MDM, or endpoint management to ensure browsers move to 149.0.7827.53/54 or later and actually relaunch. For a HIGH verdict, put this control in place within 30 days if your normal update ring is not already enforcing it.
  2. Restrict risky browsing paths for privileged users — Route admin, developer, and help-desk browsing through browser isolation or a stricter SWG policy, and block untrusted categories that commonly deliver exploit kits or lures. This reduces the only mandatory prerequisite—user exposure to a crafted page—and should be deployed within 30 days.
  3. Reduce unnecessary graphics attack surface on high-risk tiers — For hardened admin workstations, kiosks, and VDI pools, consider disabling or tightly controlling WebGL / GPU-accelerated browsing where business impact is acceptable. This is not universal advice for every employee desktop, but it is a practical risk reducer for sensitive tiers and should be evaluated within 30 days.
  4. Query fleet inventory for stale versions — Pull browser version telemetry from EDR, software inventory, or Chrome Browser Cloud Management and flag anything below the fixed builds. Because network scanners will not see this well, endpoint inventory is your primary compensating visibility control and should be active within 30 days.
What doesn't work
  • A perimeter vulnerability scan will not materially help; this is endpoint browser software, not an exposed network service.
  • MFA does not block the exploit path; it may help after compromise, but it does nothing to stop a malicious page from triggering the bug.
  • A classic WAF is mostly irrelevant because the vulnerable code executes in the browser, not in your inbound web stack.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software-distribution/EDR scripting channel. Invoke it with python3 chrome_cve_2026_11066_check.py; no administrator privileges are required, but the script needs permission to execute local binaries from standard install paths and read the macOS app bundle metadata if present.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11066 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 shutil import which

THRESHOLD = (149, 0, 7827, 53)


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def candidate_commands():
    system = platform.system()
    cmds = []

    if system == 'Windows':
        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'),
        ]
        for p in paths:
            if p and os.path.exists(p):
                cmds.append([p, '--version'])
    elif system == 'Darwin':
        app_bin = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
        if os.path.exists(app_bin):
            cmds.append([app_bin, '--version'])
        plist = '/Applications/Google Chrome.app/Contents/Info.plist'
        if os.path.exists(plist):
            cmds.append(['/usr/bin/defaults', 'read', plist, 'CFBundleShortVersionString'])
    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
            p = which(name)
            if p:
                cmds.append([p, '--version'])
        for p in ['/opt/google/chrome/chrome', '/usr/bin/google-chrome', '/usr/bin/google-chrome-stable']:
            if os.path.exists(p):
                cmds.append([p, '--version'])

    return cmds


def main():
    versions = []
    checked = []

    for cmd in candidate_commands():
        checked.append(' '.join(cmd))
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            versions.append((v, ' '.join(cmd), out.strip()))

    if not versions:
        print('UNKNOWN - could not determine Chrome version from common install paths')
        if checked:
            print('Checked:', '; '.join(checked))
        sys.exit(2)

    # Use highest discovered version if multiple installs exist.
    versions.sort(key=lambda x: x[0], reverse=True)
    version, source, raw = versions[0]

    if version < THRESHOLD:
        print(f'VULNERABLE - detected Chrome version {raw} via {source}; fixed version is >= 149.0.7827.53')
        sys.exit(1)
    else:
        print(f'PATCHED - detected Chrome version {raw} via {source}; fixed version threshold is >= 149.0.7827.53')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, pull a fleet query for Chrome versions below 149.0.7827.53, confirm your update rings are not stuck behind deferred restarts, and focus first on privileged users plus unmanaged or exception-based endpoints. For this HIGH call, the noisgate mitigation SLA is within 30 days for temporary risk reduction like enforced browser relaunch, stricter web filtering, or isolation for sensitive users, and the noisgate remediation SLA is within 180 days for the actual vendor fix—but because this is a browser with broad endpoint exposure, most enterprises should complete rollout far sooner through normal Chrome auto-update controls.

Sources

  1. NVD CVE-2026-11066
  2. Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
  3. Chrome Releases: Early Stable Update for Desktop / label page
  4. Chrome Enterprise: Manage Chrome updates (Windows)
  5. Chrome Enterprise: Manage the Chrome variations framework
  6. CISA Known Exploited Vulnerabilities Catalog
  7. VulDB entry for CVE-2026-11066
  8. SecurityWeek coverage of Chrome 149 security fixes
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.