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

Use after free in ServiceWorker in Google Chrome prior to 149

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

This is a hidden trapdoor inside a fake maintenance badge, not a burglar kicking in the front door

CVE-2026-11201 is a use-after-free in Chrome ServiceWorker affecting Google Chrome versions before 149.0.7827.53. The published description matters: the attacker must convince a user to install a malicious Chrome extension, and that crafted extension then triggers the memory-corruption bug to reach arbitrary code execution in the browser context. Official Chrome release notes list it as Chromium security severity: Medium, even though downstream CVSS scoring shows 8.8 High.

The vendor-style CVSS is too generous for enterprise prioritization because it treats this like generic network-reachable browser RCE. In reality, the exploit chain begins with a malicious extension install prerequisite, which is a major friction point in managed fleets: extension allowlists, admin install policies, user awareness, Safe Browsing, and store vetting all narrow the reachable population before the bug is even in play.

"This is not a drive-by web RCE; it starts with getting a malicious extension installed."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a trojanized extension

The attacker needs a Chrome extension package that the victim will install. That can be a fake productivity add-on, a malicious update to an existing extension, or a sideloaded CRX delivered through social engineering. There is no public PoC or weaponized exploit kit tied to this CVE in the sources reviewed.
Conditions required:
  • Attacker can distribute or socially engineer installation of a malicious Chrome extension
  • Target users are allowed to install extensions or receive one through unmanaged channels
Where this breaks in practice:
  • Enterprise extension allowlists and force-install policies block most unsanctioned add-ons
  • Chrome Web Store vetting and Safe Browsing reduce casual delivery success
  • User must take an install action
Detection/coverage: Browser-management platforms, EDR, and extension inventory tools usually catch the extension install event, but not this CVE specifically.
STEP 02

Land on a vulnerable Chrome build

The extension only matters if the endpoint is running Chrome < 149.0.7827.53. Because Chrome is evergreen, many fleets self-heal quickly unless update deferrals or broken auto-update channels keep older builds alive. The bug is cross-platform in Chrome desktop release notes, covering Windows, macOS, and Linux stable builds before the fix.
Conditions required:
  • Chrome version earlier than 149.0.7827.53 is present
  • Auto-update is delayed, broken, or intentionally deferred
Where this breaks in practice:
  • Chrome updates fast in healthy fleets
  • Managed browsers are often pinned only briefly for compatibility testing
Detection/coverage: Excellent coverage from EDR, browser inventory, MDM, SCCM/Intune/Jamf, and config scanners that record the installed Chrome version.
STEP 03

Trigger the ServiceWorker use-after-free

The malicious extension abuses the vulnerable ServiceWorker code path to create a dangling-reference condition and execute attacker-controlled logic. This is memory corruption, so reliability depends on build, platform, allocator state, and exploit engineering quality. The Chromium bug is still access-restricted, which is normal for fresh browser memory-safety issues.
Conditions required:
  • Malicious extension can reach the affected ServiceWorker path
  • Exploit is stable enough for the target platform/build
Where this breaks in practice:
  • Memory-corruption exploitation is harder than policy-bypass bugs
  • Cross-version exploit reliability may be poor without tailored engineering
Detection/coverage: Signature-based scanners are weak here; runtime telemetry may only show browser crashes, odd child-process behavior, or suspicious extension activity.
STEP 04

Achieve browser-context code execution

The published impact is arbitrary code execution via a crafted Chrome Extension. That is serious, but the blast radius is still constrained by the earlier prerequisite: the attacker already had to get code accepted as an extension first. For enterprise risk, this looks more like extension-mediated post-delivery exploitation than mass internet-scale remote compromise.
Conditions required:
  • Exploit succeeds on the target build
  • Victim keeps the malicious extension installed long enough to trigger the chain
Where this breaks in practice:
  • Extension governance can remove the add-on before exploitation
  • EDR and browser hardening can still disrupt follow-on behavior
Detection/coverage: Post-exploitation is more detectable than initial trigger: watch for suspicious browser child processes, extension persistence, crash artifacts, and anomalous script/network behavior tied to the extension ID.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation in reviewed sources, and not listed in CISA KEV as of review time (CISA KEV).
Proof-of-concept availabilityNo public PoC found. SynScan currently shows "No technical information available" and the Chromium issue remains restricted (SynScan, Chromium issue).
EPSS0.009% (1st percentile) per the GitHub advisory, which is extremely low predicted exploitation probability for the next 30 days (GHSA-9pgr-9977-jg98).
KEV statusNot KEV-listed; no CISA due date applies (CISA KEV).
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H produces 8.8 High, but that model underweights the practical prerequisite of installing a malicious extension first (GHSA).
Affected versionsGoogle Chrome before 149.0.7827.53. CIRCL mirrors the CNA record showing < 149.0.7827.53 as affected (CIRCL).
Fixed versions149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS in the stable desktop rollout (Chrome Releases).
Exposure / scanning dataNot internet-scan-observable in any useful way. This is a client-side browser + malicious-extension chain, so Shodan/Censys/FOFA-style edge counts are the wrong lens; external scanning will not tell you your true exposure. *Inference based on product type and attack path.*
Disclosure date2026-06-04 in the CNA/CVE record; Chrome stable release notes were published 2026-06-02 (CIRCL, Chrome Releases).
ReporterReported by Weipeng Jiang (@Krace) of VRI on 2026-04-22 according to Chrome release notes (Chrome Releases).
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.4/10)

The decisive factor is the attacker position requirement: this chain starts with malicious extension installation, which dramatically narrows exposure in managed enterprise fleets. With no KEV listing, no public exploitation evidence, and a bottom-decile EPSS, this does not justify a HIGH queue placement for most organizations.

HIGH Affected version and fixed build mapping
HIGH Downward severity adjustment driven by extension-install prerequisite
MEDIUM Exact exploit reliability and post-exploitation reach because Chromium bug details remain restricted

Why this verdict

  • Major prerequisite discount: attacker needs the victim to install a malicious extension first; that is not the same thing as unauthenticated drive-by web exploitation.
  • Exposure discount: only endpoints running Chrome < 149.0.7827.53 *and* lacking strong extension governance are realistically reachable.
  • Threat-intel discount: no KEV, no public PoC, and 0.009% EPSS / 1st percentile all push this below a typical browser-RCE emergency.

Why not higher?

A higher rating would make sense for a pure drive-by browser bug with active exploitation or a reliable public exploit. This one is bottlenecked by the need to land a malicious extension first, which means many enterprises can eliminate most of the reachable population with policy alone.

Why not lower?

It is still a memory-corruption code-execution bug in Chrome, and Chrome is everywhere. If your fleet allows broad extension installs, or you have a history of users adopting unsanctioned add-ons, the reachable population grows quickly and the residual risk stays meaningful.

05 · Compensating Control

What to do — in priority order.

  1. Lock down extension installs — Enforce extension allowlists / blocklists in Chrome enterprise policy and remove user ability to install arbitrary add-ons where business-acceptable. For a MEDIUM verdict there is no mitigation SLA; use this as an immediate risk-reducer for high-risk user groups while completing remediation within 365 days.
  2. Inventory and review installed extensions — Pull extension inventories from browser management, EDR, or MDM, then flag rare, newly installed, sideloaded, or unapproved extension IDs. There is no mitigation SLA here; do the review now for unmanaged cohorts and keep it as an interim control until patched builds are universal within the 365-day remediation window.
  3. Verify Chrome auto-update health — Find systems pinned below 149.0.7827.53 because of broken update channels, VDI gold images, packaging lag, or deferred rings. There is no mitigation SLA for MEDIUM, but this materially shrinks exposure and should be folded into your normal browser maintenance program ahead of the 365-day remediation deadline.
  4. Monitor browser child-process anomalies — Use EDR detections for suspicious child processes spawned by Chrome, unusual PowerShell/cmd/bash launches, crash clusters, and extension-related persistence. This does not replace patching, but it gives you a chance to catch malicious-extension abuse while you remediate inside the 365-day window.
What doesn't work
  • A network perimeter scanner will not help much; this is not an internet-facing service vulnerability.
  • A WAF or edge IPS does not meaningfully reduce risk because the exploit chain is delivered through a browser extension, not a server-side HTTP endpoint.
  • MFA is mostly irrelevant to the core flaw; it may protect accounts, but it does not stop a malicious extension from landing or triggering the bug.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software-distribution/EDR scripting channel. Invoke it with python3 check_chrome_cve_2026_11201.py on macOS/Linux or py check_chrome_cve_2026_11201.py on Windows; no admin rights are required for version-only checks, though broader path visibility helps.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11201.py
# Detects whether local Google Chrome version is vulnerable to CVE-2026-11201.
# 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)
    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 '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def get_version_windows():
    candidates = [
        ["reg", "query", r"HKCU\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            return v, 'registry'

    exe_candidates = [
        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 exe_candidates:
        if path and os.path.exists(path):
            out = run_cmd([path, "--version"])
            v = parse_version(out)
            if v:
                return v, path
    return None, ''


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


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


def main():
    system = platform.system().lower()
    if 'windows' in system:
        version, source = get_version_windows()
    elif 'darwin' in system:
        version, source = get_version_macos()
    else:
        version, source = get_version_linux()

    if not version:
        print('UNKNOWN - Could not determine Google Chrome version on this host')
        sys.exit(2)

    version_str = '.'.join(str(x) for x in version)
    fixed_str = '.'.join(str(x) for x in FIXED)

    if version < FIXED:
        print(f'VULNERABLE - Detected Chrome {version_str} from {source}; fixed version is {fixed_str} or later')
        sys.exit(1)
    else:
        print(f'PATCHED - Detected Chrome {version_str} from {source}; fixed version threshold is {fixed_str}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, do not throw this into your emergency browser zero-day lane. Treat it as a managed-fleet browser hygiene issue with an extension-governance twist: confirm which endpoints are still below 149.0.7827.53, identify user groups allowed to install arbitrary extensions, and tighten extension policy where that control is weak. For a MEDIUM verdict there is noisgate mitigation SLA — go straight to the 365-day remediation window for the actual browser update, but high-risk unmanaged or extension-permissive cohorts should be cleaned up first so they do not sit exposed for the full noisgate remediation SLA.

Sources

  1. Chrome Releases - Stable Channel Update for Desktop
  2. Chromium issue 505068950
  3. GitHub Advisory Database - GHSA-9pgr-9977-jg98
  4. CIRCL Vulnerability Lookup - CVE-2026-11201
  5. CISA Known Exploited Vulnerabilities Catalog
  6. Chromium Security - Memory safety
  7. Chromium Security - Site Isolation
  8. SynScan - CVE-2026-11201
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.