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

Use after free in WebSockets in Google Chrome prior to 149

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

This is a burglar who can get into the mall but is still locked inside one store

CVE-2026-11068 is a CWE-416 use-after-free in Chrome's WebSockets handling. A malicious site can trigger memory corruption through crafted HTML/JavaScript and gain code execution inside Chrome's sandboxed renderer context, affecting Google Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS.

The vendor-style 8.8 HIGH CVSS is too hot for enterprise patch triage because it prices in full C:H/I:H/A:H impact, while Chromium's own security label is Medium and the NVD description explicitly says execution is *inside a sandbox*. In real fleets, that means this bug is dangerous as a chain component or phishing payload, but by itself it is usually not endpoint takeover.

"Real bug, real reach, but sandbox-only code exec plus no exploitation signal makes this a managed browser patch, not a fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker HTML

The attacker needs the victim to render a malicious page, ad, or embedded web content in Chrome. This is classic browser-exploit delivery: phishing, malvertising, or compromised legitimate sites can all carry the payload, but the exploit still needs a live browsing event.
Conditions required:
  • Victim is using affected Chrome build
  • Victim visits attacker-controlled or attacker-influenced content
  • JavaScript and WebSockets are available
Where this breaks in practice:
  • Requires UI:R, so no drive-by impact without user browsing activity
  • Email gateway, web filtering, DNS filtering, and browser isolation can break delivery
  • Enterprise users may browse through remote session, VDI, or hardened containerized browsers
Detection/coverage: Network and email tooling can sometimes catch the delivery stage, but vulnerability scanners will not see this through perimeter exposure checks because this is a client-side browser flaw.
STEP 02

Trigger the WebSocket state bug with a custom JS harness

A crafted page uses a JavaScript/WebSocket sequence to exercise the vulnerable lifecycle in Chrome networking. The public Chromium fix points to a sequencing-related use-after-free in WebSocketSpdyStreamAdapter, which implies exploit reliability depends on precise browser-state manipulation rather than a trivial one-packet bug.
Conditions required:
  • Attacker can run JavaScript in the victim tab
  • Target build still contains the vulnerable WebSockets code path
Where this breaks in practice:
  • No public turnkey PoC was found during this assessment
  • Memory-corruption reliability varies by platform, build, allocator state, and browser mitigations
  • Restricted bug details raise reverse-engineering cost for attackers
Detection/coverage: EDR usually will not identify the vulnerability trigger itself; browser crash telemetry, unusual tab crashes, and exploit-protection events are more realistic signals.
STEP 03

Achieve renderer code execution

If exploitation succeeds, the attacker gets arbitrary code execution in the renderer process. That is meaningful, because it gives script-level access plus native execution inside the browser sandbox, but it is not the same as code execution on the host with user privileges.
Conditions required:
  • Exploit successfully corrupts memory and controls execution flow
  • Platform mitigations are bypassed well enough to gain stable renderer execution
Where this breaks in practice:
  • Modern Chrome builds use strong exploit mitigations
  • Sandboxing contains the initial impact to the renderer
  • Crashy exploits are noisy and may self-burn before useful post-exploitation
Detection/coverage: Exploit guard, EDR memory-protection telemetry, repeated chrome child-process crashes, and sandbox violation alerts may expose this stage; generic Nessus/Qualys-style plugin coverage only identifies vulnerable versions.
STEP 04

Try to convert sandbox foothold into host impact

The attacker must either live inside the renderer's constrained sandbox or chain a second vulnerability, feature abuse, or user action to escape it. That extra hop is the decisive severity reducer: without a companion sandbox escape or privileged broker abuse, blast radius stays mostly inside the browsing session.
Conditions required:
  • Attacker needs a second bug, dangerous browser feature path, or user-assisted follow-on
  • Target environment must allow meaningful post-exploit actions from browser context
Where this breaks in practice:
  • Requires post-initial-exploit chaining to reach full workstation compromise
  • Application control, EDR, and browser sandbox architecture are built to stop exactly this step
  • No evidence tied this CVE to active chained exploitation
Detection/coverage: This is where defenders have the best shot: EDR, child-process controls, broker abuse detections, suspicious downloads, and browser-to-OS boundary telemetry matter more than web scanners.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in the sources reviewed. It is not listed in the current CISA KEV catalog.
PoC availabilityNo public PoC or weaponized repo was located during this assessment. The Chromium issue is restricted, and the visible primary technical breadcrumb is the fix commit for Fixed: 499194333 in Chromium source.
EPSSUser-supplied EPSS is 0.00071 (~0.071% 30-day exploitation probability). Percentile was not confirmed from a primary EPSS CVE response in this session, but the score itself is very low by patch-prioritization standards.
KEV statusNot KEV-listed as assessed against the current CISA KEV catalog. No CISA due date or emergency remediation signal exists for this CVE.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H overstates enterprise urgency because the description itself limits code execution to inside a sandbox. UI:R is real friction, and the host-impact assumptions only become true if attackers chain beyond the renderer.
Affected versionsGoogle Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS, per Chrome and Canadian Cyber Centre advisories.
Fixed versionsPatch to Chrome 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS. There are no meaningful distro backports to track here in the usual server-package sense; this is standard Chrome channel versioning.
Exposure and scanning realityShodan/Censys/FOFA-style internet exposure metrics are not useful here because this is a client-side browser bug, not an internet-facing service flaw. Your exposure is workforce install base and update lag, not open ports.
Disclosure timelineReported by Google on 2026-04-03 in Chrome's 2026 release archive, fixed in stable Chrome on 2026-06-02, published in NVD on 2026-06-04, and modified in NVD on 2026-06-05.
Researcher / root causeChrome's archive attributes the CVE to Google. The visible Chromium source fix by Andrew Paseltiner describes a *sequencing-related UAF* in WebSocketSpdyStreamAdapter, which supports the view that this is a browser-internal lifecycle bug rather than an easy external protocol smash.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.1/10)

The single decisive factor is that successful exploitation yields code execution inside Chrome's sandbox, not straightforward host-level compromise. That sharply narrows blast radius unless the attacker already has, or can pair, a second escape primitive.

HIGH Affected versions and patch floor
HIGH Sandbox-limited initial impact
MEDIUM Absence of public PoC or active exploitation evidence
MEDIUM Exact exploit reliability across platforms

Why this verdict

  • Sandboxed code exec cuts the score down: the NVD text says arbitrary code execution is *inside a sandbox*, and Chromium itself tags the bug Medium; that is materially less dangerous than workstation-level RCE.
  • UI:R is real friction: attackers need a browsing event to hostile content. That still scales via phishing and malvertising, but it is weaker than unauthenticated server-side exploitation and weaker than UI:N browser chains.
  • No exploitation signal: EPSS 0.00071, no KEV listing, and no public PoC found. With no evidence of operational attacker demand, this belongs in disciplined browser patching rather than emergency handling.

Why not higher?

There is no evidence this CVE alone breaks out of Chrome's sandbox, and that matters more than the raw CVSS math. No KEV entry, no active exploitation reporting, and no public exploit kit all argue against a HIGH or CRITICAL enterprise priority.

Why not lower?

This is still a memory-corruption bug in one of the most broadly deployed user applications in the enterprise. PR:N, AC:L, and browser-based delivery keep it above LOW even though the sandbox prevents us from treating it like direct endpoint compromise.

05 · Compensating Control

What to do — in priority order.

  1. Force Chrome auto-update and relaunch compliance — Use enterprise browser management to ensure endpoints actually move to 149.0.7827.53+ and relaunch, because stale browsers are the only meaningful exposure lever here. For a MEDIUM verdict there is no mitigation SLA; go straight to durable remediation inside the 365-day window, but do not let unmanaged update lag linger in high-risk user groups.
  2. Identify and remove unmanaged browser installs — Hunt for portable Chromium/Chrome binaries, developer-side alternate channels, and non-managed local installs that bypass your normal update ring. This is how browser risk quietly persists after central patch dashboards say you're green; again, MEDIUM means no separate mitigation clock, but cleanup should happen as part of the remediation program.
  3. Apply browser isolation to high-risk populations — Remote browser isolation or disposable browsing for finance, exec, help-desk, and threat-intel users reduces the chance that a renderer exploit touches a real workstation at all. Treat this as targeted risk reduction while normal remediation rolls out; there is no noisgate mitigation deadline for MEDIUM, but it is worth enabling where exposure is concentrated.
  4. Keep EDR browser exploit protections enabled — Memory-protection, child-process, and browser-hardening controls are most valuable at the post-exploit step where the attacker tries to convert renderer execution into host impact. They do not replace patching, but they are the main controls that meaningfully interfere with the highest-value follow-on stage.
What doesn't work
  • Perimeter vulnerability scanning doesn't help much, because this is not an externally exposed service with a detectable banner or port.
  • WAF rules don't solve the core problem; the exploit lands in the user's browser, not your web application edge.
  • MFA/SSO doesn't materially reduce exploitability, because the bug is triggered by rendering hostile content rather than by account compromise.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software distribution/EDR script runner. Invoke with python3 check_chrome_cve_2026_11068.py on macOS/Linux or py check_chrome_cve_2026_11068.py on Windows; standard user rights are usually enough because the script only reads version info from common install paths and the registry.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check Google Chrome version exposure for CVE-2026-11068
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import subprocess
import sys

FIXED = (149, 0, 7827, 53)


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 version_to_str(v):
    return '.'.join(str(x) for x in v)


def is_patched(v):
    return v >= FIXED


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        if p.returncode == 0:
            return p.stdout.strip() or p.stderr.strip()
    except Exception:
        pass
    return None


def check_windows():
    installs = []
    reg_queries = [
        ["reg", "query", r"HKLM\SOFTWARE\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKCU\SOFTWARE\Google\Chrome\BLBeacon", "/v", "version"],
    ]
    for q in reg_queries:
        out = run_cmd(q)
        if out:
            v = parse_version(out)
            if v:
                installs.append(("registry", v))

    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"),
    ]
    for path in paths:
        if path and os.path.exists(path):
            out = run_cmd([path, "--version"])
            if out:
                v = parse_version(out)
                if v:
                    installs.append((path, v))
    return installs


def check_macos():
    installs = []
    paths = [
        "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
        os.path.expanduser("~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
    ]
    for path in paths:
        if os.path.exists(path):
            out = run_cmd([path, "--version"])
            if out:
                v = parse_version(out)
                if v:
                    installs.append((path, v))
    return installs


def check_linux():
    installs = []
    cmds = [
        ["google-chrome", "--version"],
        ["google-chrome-stable", "--version"],
        ["chromium", "--version"],
        ["chromium-browser", "--version"],
    ]
    for cmd in cmds:
        out = run_cmd(cmd)
        if out:
            v = parse_version(out)
            if v:
                installs.append((' '.join(cmd), v))
    return installs


def main():
    system = platform.system().lower()
    if 'windows' in system:
        installs = check_windows()
    elif 'darwin' in system:
        installs = check_macos()
    else:
        installs = check_linux()

    if not installs:
        print("UNKNOWN - No Chrome/Chromium installation found in common locations")
        sys.exit(2)

    vulnerable = []
    patched = []
    for source, ver in installs:
        if is_patched(ver):
            patched.append((source, ver))
        else:
            vulnerable.append((source, ver))

    if vulnerable:
        details = '; '.join([f"{src}: {version_to_str(ver)}" for src, ver in vulnerable])
        print(f"VULNERABLE - Found version(s) below {version_to_str(FIXED)} :: {details}")
        sys.exit(1)

    details = '; '.join([f"{src}: {version_to_str(ver)}" for src, ver in patched])
    print(f"PATCHED - All discovered version(s) are >= {version_to_str(FIXED)} :: {details}")
    sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: treat this as a broad but contained browser bug. Push Chrome 149.0.7827.53+ through your normal endpoint ring, verify relaunch compliance, and inventory unmanaged browsers; for this MEDIUM verdict there is noisgate mitigation SLA — no mitigation SLA, go straight to the 365-day remediation window — and the noisgate remediation SLA is <= 365 days, though a sane enterprise should finish a browser rollout far sooner than that because Chrome is ubiquitous and low-friction to patch.

Sources

  1. NVD CVE-2026-11068
  2. Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
  3. Chrome Releases 2026 archive entry showing CVE-2026-11068 attribution
  4. Chromium fix commit for issue 499194333
  5. Canadian Centre for Cyber Security advisory AV26-544
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS documentation
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.