← Back to Feed CACHED · 2026-06-06 08:04:35 · CACHE_KEY CVE-2026-11066
CVE-2026-11066 · CWE-20 · Disclosed 2026-06-04

Google Chrome ANGLE improper input validation sandbox escape

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
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 · Compensating Control

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.
04 · 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.

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
05 · The Call

Final Verdict
↓ DOWNGRADED to HIGH (7.8/10)

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.

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()