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

Object lifecycle issue in Dawn in Google Chrome prior to 149

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

This is a trapdoor in the browser’s GPU wing, not the front door to the whole building

CVE-2026-11152 is an object-lifecycle bug in Dawn, Chromium’s WebGPU implementation. A crafted web page can hit vulnerable code paths and potentially cross the Chrome sandbox boundary. The affected range is Chrome before 149.0.7827.53; Google’s June 2, 2026 stable rollout shipped 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS, with Android inheriting the same desktop security fixes in 149.0.7827.59 unless otherwise noted.

The published 9.6/CRITICAL framing overstates what defenders should do with this in a 10,000-host fleet. Yes, sandbox escape from a malicious page is a big deal, but this path still needs user interaction, depends on WebGPU/Dawn reachability and compatible GPU acceleration, has no KEV entry or confirmed in-the-wild exploitation, and lacks a public weaponized PoC. That makes it a real HIGH, not a universal emergency.

"Serious browser bug, but not a drop-everything 9.6: feature-gated drive-by sandbox escape with no wild exploit evidence."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on a crafted page

The attacker needs normal web delivery: phishing, malvertising, a compromised site, or a redirected SaaS help page. The payload is a custom JavaScript/WebGPU harness aimed at exercising Dawn object lifetime mistakes from untrusted page content.
Conditions required:
  • Victim browses to attacker-controlled or attacker-influenced content
  • Chrome version is below 149.0.7827.53
  • JavaScript execution is permitted
Where this breaks in practice:
  • This is UI:R; the user has to load the page
  • Email gateways, safe browsing, URL filtering, and browser isolation reduce reachability
  • No public exploit kit or broadly reused PoC was found
Detection/coverage: Network scanners do not see this. Detection lives in mail/web telemetry, secure web gateways, and browser-isolation logs for delivery events.
STEP 02

Reach the WebGPU/Dawn path

The malicious page then needs the browser to expose navigator.gpu and route work through Dawn. On Chrome, WebGPU availability depends on platform support and GPU acceleration state; Chrome documentation explicitly notes WebGPU is disabled when graphics acceleration is off and may also be blocklisted on unsupported adapters.
Conditions required:
  • WebGPU is available on the endpoint
  • Hardware acceleration is enabled or the adapter is otherwise usable
  • The GPU/platform combination is not blocklisted
Where this breaks in practice:
  • This narrows real exposure versus 'all Chrome users'
  • Some enterprise images disable graphics acceleration
  • Unsupported or blocklisted GPU setups break the chain before exploitation starts
Detection/coverage: Version-only scanners can flag vulnerable Chrome builds, but they usually cannot confirm WebGPU reachability remotely. Endpoint config/state telemetry is required.
STEP 03

Trigger the Dawn lifecycle flaw

The attacker abuses the object-lifecycle bug inside Dawn to corrupt state in a security-sensitive browser path. The stated impact is a potential sandbox escape, meaning the exploit aim is to cross from web content handling into a more privileged browser/GPU context.
Conditions required:
  • A compatible trigger sequence exists for the victim’s Chrome build and GPU stack
  • The exploit is reliable enough for the target platform
Where this breaks in practice:
  • GPU-path reliability is notoriously platform- and driver-sensitive
  • Chrome issue details are still restricted, which slows commodity weaponization
  • The official Chromium severity note says Medium, suggesting the vendor itself does not see this as a straight universal drive-by host compromise
Detection/coverage: Remote scanners cannot validate exploitability. Best coverage is browser crash telemetry, anomalous GPU-process instability, and EDR visibility into Chrome/browser-child behavior after page load.
STEP 04

Capitalize on the sandbox break

If the escape works, the attacker moves from web-origin code into a more privileged execution boundary, enabling follow-on actions such as data access, local staging, or chaining into OS-level execution. In practice, defenders should treat successful exploitation as a browser containment failure, not 'just another tab crash.'
Conditions required:
  • Exploit succeeds beyond mere crash
  • Post-escape primitives are usable on the target OS
Where this breaks in practice:
  • A sandbox escape alone is not automatically a full-domain event
  • EDR, application control, and privilege boundaries still matter after the break
  • Blast radius is endpoint-local unless chained with additional creds or lateral movement
Detection/coverage: Look for unusual child processes from Chrome, unexpected file writes or persistence after browsing, and EDR alerts tied to browser-originated execution.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation found in Google’s release note, and the CVE is not listed in CISA KEV in the reviewed catalog source.
PoC availabilityNo public, trustworthy exploit repo or weaponized PoC was found during this review. The Chromium issue remains the primary reference and detailed bug contents are not publicly useful yet.
EPSS0.00035 (~0.035%), which is very low and lines up with 'not currently a mass-exploitation favorite.' Percentile was not confirmed from a live FIRST query in the reviewed sources.
KEV statusNot KEV-listed. That matters because browser bugs with active abuse usually get pulled into KEV fast once exploitation evidence is solid.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — severe on paper because it models a remote browser-to-higher-privilege break, but it still includes user interaction and says nothing about feature gating or exploit reliability.
Affected versionsChrome <149.0.7827.53. Desktop stable rollout fixed Linux at 149.0.7827.53 and Windows/macOS at 149.0.7827.53/54.
Fixed versionsUpgrade to 149.0.7827.53+ on Linux and 149.0.7827.53/54+ on Windows/macOS. Chrome for Android 149.0.7827.59 carries the same desktop security fixes unless otherwise noted by Google.
Exposure population realityThis is a client-side browser flaw, not a service exposure. Shodan/Censys-style internet scanning does not meaningfully measure affected population here; your real exposure is whatever share of the fleet runs vulnerable Chrome with WebGPU reachable.
Feature gatingDawn is Chromium’s WebGPU implementation. WebGPU shipped by default on Chrome 113 for Windows/macOS/ChromeOS-capable devices, but Chrome docs also say it is disabled when graphics acceleration is off and may be blocklisted on some hardware.
Disclosure and reportingPublished 2026-06-04. Google’s stable update lists it as a Medium Chromium security severity issue and attributes the report to Google on 2026-04-11.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (8.4/10)

The decisive downgrade factor is that this is not a universal unauthenticated network service bug; it is a user-driven browser exploit path that also depends on WebGPU/Dawn being reachable on the endpoint. That still leaves a large enterprise population at risk, but it meaningfully narrows reachable exposure versus a true 9.6-style wormable or one-packet remote compromise.

HIGH Affected version range and fixed build mapping
MEDIUM Operational severity downgrade from 9.6 to HIGH
MEDIUM Assessment that WebGPU/hardware state materially limits real exploit population

Why this verdict

  • Downgrade from 9.6: the chain starts with user interaction. That immediately removes the 'internet can hit it directly at scale' property that justifies true emergency-critical server bugs.
  • Downgrade again: exploitation requires the Dawn/WebGPU path to be available. Chrome documentation shows WebGPU can be disabled by policy, unsupported hardware, blocklists, or disabled graphics acceleration, so the exposed population is smaller than 'every Chrome install.'
  • Hold at HIGH, not MEDIUM: if the bug is reachable, the impact is still a sandbox escape from malicious web content, which is exactly the kind of browser boundary failure attackers prize for drive-by chains.
  • No upward pressure from threat intel: no KEV, no public exploitation evidence, and a very low EPSS all argue against CRITICAL treatment right now.
  • Enterprise blast radius is still broad enough for HIGH: Chrome is everywhere, and web content is constant. Even with feature gating, a browser sandbox escape can touch privileged sessions, SSO cookies, and admin workflows on many endpoints.

Why not higher?

It is not higher because the path is constrained by UI:R and feature/hardware reachability. There is also no current evidence of active exploitation or broad public weaponization, which is the normal trigger for moving browser bugs into patch-immediately territory.

Why not lower?

It is not lower because a browser sandbox escape is a meaningful security-boundary failure, not a cosmetic or tenant-contained bug. On a large enterprise fleet, even a partially reachable drive-by path is operationally important because the browser sits next to identity, SaaS sessions, internal apps, and admin consoles.

05 · Compensating Control

What to do — in priority order.

  1. Force browser updates and relaunch — Push Chrome to 149.0.7827.53+ (149.0.7827.53/54+ on Windows/macOS) and enforce relaunch so the fixed code is actually loaded. For a HIGH verdict, deploy this under the noisgate mitigation window within 30 days, even if Chrome auto-update is already enabled.
  2. Disable hardware acceleration for high-risk cohorts — For admins, finance, developers with production access, and browser-isolation exceptions, set Chrome policy HardwareAccelerationModeEnabled=false where business impact is acceptable. This reduces WebGPU/Dawn reachability and should be in place within 30 days for exposed high-value populations.
  3. Route risky browsing through browser isolation — Put unmanaged internet browsing, webmail, ad-heavy content, and newly registered domains behind remote browser isolation or a hardened VDI profile. This cuts off the direct local exploit path and should be prioritized within 30 days for the riskiest user groups.
  4. Tighten web delivery controls — Use safe browsing, DNS/web filtering, phishing-resistant mail controls, and URL detonation to reduce initial page-load opportunities. These controls do not fix the bug, but they materially reduce the volume of exploit attempts landing on vulnerable endpoints within 30 days.
  5. Hunt for browser-origin post-exploitation — Add detections for unusual child processes from chrome.exe/Google Chrome, suspicious file writes after browsing sessions, and GPU-process crash clusters. Stand these detections up within 30 days to catch exploitation attempts before the full fleet is remediated.
What doesn't work
  • A WAF does not help; the victim is the browser, not your server.
  • A network vulnerability scanner will only tell you Chrome version at best; it cannot prove whether the endpoint’s WebGPU/Dawn path is reachable or exploitable.
  • MFA does not prevent the initial exploit path. It helps after account theft, not during a browser memory-corruption event.
  • Relying on Chrome auto-update alone is not enough in enterprise fleets because stalled relaunches leave the vulnerable binary in memory.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/software-management agent. Invoke it as python3 check_cve_2026_11152.py or python3 check_cve_2026_11152.py --path "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"; no admin rights are required unless your tooling restricts access to installed application paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
"""
Check local Google Chrome version against CVE-2026-11152 fixed build.
Outputs one of: VULNERABLE / PATCHED / UNKNOWN
Exit codes:
  0 = PATCHED
  1 = VULNERABLE
  2 = UNKNOWN / error
"""

import argparse
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path

FIXED = (149, 0, 7827, 53)


def parse_version(text: str):
    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, b):
    return (a > b) - (a < b)


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (p.stdout or "") + "\n" + (p.stderr or "")
        return p.returncode, out.strip()
    except Exception:
        return 99, ""


def candidate_paths(user_path=None):
    cands = []
    if user_path:
        cands.append(user_path)

    system = platform.system().lower()

    if system == "windows":
        local = os.environ.get("LOCALAPPDATA", "")
        pf = os.environ.get("PROGRAMFILES", "")
        pfx86 = os.environ.get("PROGRAMFILES(X86)", "")
        cands += [
            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"),
        ]
    elif system == "darwin":
        cands += [
            "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
            str(Path.home() / "Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
        ]
    else:
        cands += [
            shutil.which("google-chrome") or "",
            shutil.which("google-chrome-stable") or "",
            "/usr/bin/google-chrome",
            "/usr/bin/google-chrome-stable",
            "/opt/google/chrome/chrome",
        ]

    seen = set()
    uniq = []
    for c in cands:
        if c and c not in seen:
            uniq.append(c)
            seen.add(c)
    return uniq


def get_version_from_executable(path):
    if not path or not os.path.exists(path):
        return None
    rc, out = run_cmd([path, "--version"])
    ver = parse_version(out)
    if ver:
        return ver
    return None


def get_version_windows_registry():
    rc, out = run_cmd([
        "reg",
        "query",
        r"HKLM\Software\Google\Chrome\BLBeacon",
        "/v",
        "version",
    ])
    ver = parse_version(out)
    if ver:
        return ver
    rc, out = run_cmd([
        "reg",
        "query",
        r"HKCU\Software\Google\Chrome\BLBeacon",
        "/v",
        "version",
    ])
    ver = parse_version(out)
    return ver


def main():
    ap = argparse.ArgumentParser(description="Check if installed Google Chrome is vulnerable to CVE-2026-11152")
    ap.add_argument("--path", help="Explicit path to Chrome executable", default=None)
    args = ap.parse_args()

    ver = None
    source = None

    if platform.system().lower() == "windows":
        ver = get_version_windows_registry()
        if ver:
            source = "registry"

    if not ver:
        for cand in candidate_paths(args.path):
            ver = get_version_from_executable(cand)
            if ver:
                source = cand
                break

    if not ver:
        print("UNKNOWN - Google Chrome version not found")
        sys.exit(2)

    if cmp_ver(ver, FIXED) < 0:
        print(f"VULNERABLE - Chrome version {'.'.join(map(str, ver))} detected via {source}; fixed is {'.'.join(map(str, FIXED))}+")
        sys.exit(1)
    else:
        print(f"PATCHED - Chrome version {'.'.join(map(str, ver))} detected via {source}; meets fixed baseline {'.'.join(map(str, FIXED))}+")
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a fleet browser hygiene priority with real exploit upside, not a panic-grade internet edge incident: inventory Chrome versions, force update/relaunch to 149.0.7827.53+ (149.0.7827.53/54+ on Windows/macOS), and apply temporary controls like disabling hardware acceleration/WebGPU for high-risk users or routing them into browser isolation within the noisgate mitigation SLA of 30 days. Then close the loop by getting the entire managed fleet onto the fixed build within the noisgate remediation SLA of 180 days; in practice, you should finish much sooner because this is a browser sandbox-boundary bug and straggler endpoints are where these get burned.

Sources

  1. Chrome Releases: Stable Channel Update for Desktop (Chrome 149)
  2. Chromium issue 501762953
  3. CIRCL Vulnerability Lookup for CVE-2026-11152
  4. Chrome for Developers: WebGPU Overview
  5. Chrome for Developers: WebGPU troubleshooting tips
  6. Dawn README
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST EPSS API
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.