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

Use after free in Extensions in Google Chrome prior to 149

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

Like slipping a pick into the lobby, but still needing another key for the server room

CVE-2026-11230 is a use-after-free in Chrome's Extensions code affecting Google Chrome before 149.0.7827.53. A victim has to load attacker-controlled HTML, after which the attacker can gain arbitrary code execution inside Chrome's sandbox, not native code execution on the host outside the browser boundary. Based on the available public description, this is a client-side memory corruption issue with broad endpoint reach because Chrome is everywhere, but the affected range is straightforward: anything older than 149.0.7827.53.

The vendor/NVD-style 8.8 HIGH score is technically defensible if you grade only the bug primitive, but it overstates enterprise host risk. The decisive friction is the same one Google hints at with its own lower component severity: the code runs inside the sandbox. That means this is usually step one of a chain, not the full chain. No KEV entry, no public exploitation evidence, and a very low EPSS all push this down from emergency patch territory to routine-but-real browser patching.

"This is a browser foothold bug, not a turnkey workstation takeover"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker HTML

The attacker delivers a crafted page using a custom HTML/JS exploit page through phishing, malvertising, SEO poisoning, or a compromised site. The vulnerability is reachable remotely, but it still depends on user interaction because the target has to browse to the page in Chrome.
Conditions required:
  • Target uses Google Chrome older than 149.0.7827.53
  • Target visits attacker-controlled or attacker-influenced content
  • Exploit path is reachable from normal web content
Where this breaks in practice:
  • User interaction is mandatory
  • Email security, URL filtering, safe browsing, and ad blocking cut down delivery volume
  • Browsers auto-update quickly in many enterprises
Detection/coverage: Web scanners generally do not validate client-side renderer/extension memory corruption reliably. Detection is mostly indirect: phishing telemetry, web proxy logs, Safe Browsing alerts, and browser crash spikes.
STEP 02

Trigger the use-after-free in Extensions

The attacker uses a bespoke browser exploit to drive the vulnerable object lifecycle and achieve code execution in the sandboxed Chrome process. Public reporting currently shows no public PoC repo or named exploit framework, so this likely requires in-house exploit development rather than plug-and-play crimeware.
Conditions required:
  • Target build is vulnerable
  • Attacker has a reliable trigger for the bug
  • Chrome mitigations do not prevent exploitation in that build
Where this breaks in practice:
  • Memory corruption reliability varies across builds, hardware, and mitigations
  • No public exploit tooling is visible from the currently available sources
  • Crash-only behavior is common before a stable exploit exists
Detection/coverage: EDR may only see a browser crash or anomalous child-process behavior if exploitation destabilizes the tab. Browser crash telemetry and sandbox violation signals are more realistic than signature-based detection.
STEP 03

Operate inside the sandbox

Successful exploitation yields arbitrary code inside Chrome's sandbox, which can still matter for session hijacking, page-content theft, or follow-on exploitation in the browser context. This is meaningful for identity theft and in-browser data access, but it is not equivalent to host compromise.
Conditions required:
  • Exploit succeeds past renderer/browser mitigations
  • Attacker objective can be achieved from sandboxed execution
Where this breaks in practice:
  • Sandboxing sharply limits direct OS impact
  • Privilege escalation or sandbox escape would usually be needed for endpoint takeover
  • Enterprise session protections and re-auth controls reduce some post-exploit value
Detection/coverage: Look for suspicious browser token use, impossible-travel session reuse, unusual OAuth consent, or browser-originated credential abuse rather than expecting a clean exploit IOC.
STEP 04

Chain a second bug for full endpoint compromise

To turn this into a workstation-level incident, the attacker typically needs a separate sandbox escape or local privilege escalation. No public evidence in the reviewed sources ties CVE-2026-11230 to an active exploit chain, which is the main reason this does not make the CRITICAL/HIGH cut on its own.
Conditions required:
  • Attacker has a second exploit or a useful local post-exploitation path
  • The host lacks controls that catch the follow-on stage
Where this breaks in practice:
  • Requires additional exploit material beyond this CVE
  • EDR, application control, and OS exploit mitigations often stop the second stage
  • This is now post-browser foothold, not single-bug RCE
Detection/coverage: This is where EDR has the best shot: suspicious process spawn, injection, token theft, or kernel exploitation attempts after Chrome activity.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in the reviewed sources, and not listed in CISA KEV as of the current catalog view (CISA KEV)
Proof-of-concept availabilityNo public PoC identified from the reviewed sources; SynScan explicitly shows no exploit information and the Chromium bug details remain restricted (SynScan, Chromium issue)
EPSS0.0008 per the user-provided intel, which is directionally consistent with very low near-term exploitation probability under the FIRST EPSS model (FIRST EPSS, API docs)
KEV statusNot KEV-listed; no CISA due date exists because it is not in the catalog (CISA KEV)
CVSS vector readoutCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means remote, no auth, user interaction required. The score assumes high impact after code execution, but the public description says that execution is inside a sandbox, which materially lowers real endpoint risk.
Affected versionsChrome prior to 149.0.7827.53; the public description does not currently provide a more granular platform split for this CVE (CVE record reference via SynScan)
Fixed versionsUpdate to 149.0.7827.53 or later. Google also published an early stable desktop release 149.0.7827.53/.54 for Windows and Mac before broader rollout (Early Stable update)
Exposure / scanning realityThis is a client-side browser bug, so Shodan/Censys/FOFA-style internet exposure counts are not meaningful. The real exposure metric is managed Chrome install base, not externally reachable services.
Disclosure date2026-06-04 per the provided intel and mirrored third-party CVE aggregators (VulDB mirror, SynScan)
Researcher / reporting orgThe reviewed public sources do not name an external reporter for this exact CVE. The Chromium issue exists, but details are restricted, so attribution is currently unknown from public sources (Chromium issue)
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.4/10)

The single biggest downgrade factor is sandboxed-only code execution. This bug can hand an attacker a browser foothold, but without a second-stage escape it usually stops short of the host-level impact that enterprise teams should reserve HIGH for.

HIGH Affected version floor and fixed version `149.0.7827.53`
MEDIUM Assessment that sandbox confinement materially lowers enterprise endpoint risk
LOW Exact exploitability mechanics while Chromium bug details remain restricted

Why this verdict

  • Downgrade: sandbox boundary matters — the public description says code execution is *inside a sandbox*, which means this is usually a browser foothold rather than full workstation compromise.
  • Downgrade: no live-fire evidence — no KEV listing, no public exploitation evidence, and a user-provided EPSS of 0.0008 all argue against emergency prioritization.
  • Downgrade: exploit delivery needs a humanUI:R means the attacker still needs page view traffic, which modern email/web controls suppress at scale.
  • Offsetting upward pressure: Chrome is ubiquitous — because Chrome is widely deployed, even a sandboxed browser bug can still produce meaningful identity/session risk across a large fleet.

Why not higher?

A higher rating would require either evidence of exploitation, a public reliable exploit, or impact outside the sandbox. We do not have that here. As currently described, this is not a one-bug domain-wide disaster; it is a client-side exploit primitive that still needs additional help to become an endpoint takeover.

Why not lower?

This is still remote, unauthenticated, and broadly reachable through normal browsing. Even sandboxed execution can expose sensitive in-browser data, sessions, and application activity. On a 10,000-host fleet, you do not ignore browser memory corruption just because it stops at the sandbox.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Verify policy enforcement so Chrome cannot lag behind the fixed build. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but for browsers you should still use your normal rapid update ring instead of letting drift accumulate.
  2. Tighten web filtering on untrusted categories — Reduce exposure to exploit delivery by blocking newly registered domains, known-malvertising sources, and uncategorized destinations. This is a useful risk reducer while patch rollout completes, even though there is no noisgate mitigation deadline for MEDIUM.
  3. Restrict extension sprawl — Use enterprise allowlisting and remove unnecessary extensions. The flaw sits in the Extensions area, and while the public details are sparse, reducing extension surface is sensible hardening during the remediation window.
  4. Watch for browser crash anomalies — Sudden Chrome crash clusters after exposure to the same sites can be an early sign of exploit development or failed attempts. Feed crash telemetry, proxy logs, and EDR browser events into hunting while you patch.
What doesn't work
  • A network IPS signature is not a dependable control here because client-side memory corruption is usually exploit-shape dependent and easy to morph.
  • MFA does not prevent exploitation of the browser bug itself; it only reduces some downstream session-abuse value.
  • Vulnerability scanners aimed at servers will not meaningfully measure exposure because this is a local browser version problem, not an internet-facing service fingerprint.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/remote-exec tooling. Invoke it with python3 chrome_cve_2026_11230_check.py; it needs only normal user rights because it reads local Chrome version information and compares it to the fixed build 149.0.7827.53.

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

import os
import platform
import re
import shutil
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 version_str(v):
    return '.'.join(str(x) for x in v)


def get_version_from_command(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return parse_version(out)
    except Exception:
        return None


def get_windows_version():
    candidates = [
        ["reg", "query", r"HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe", "/ve"],
        ["reg", "query", r"HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe", "/ve"],
    ]
    exe_path = None
    for cmd in candidates:
        try:
            p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
            data = (p.stdout or '') + (p.stderr or '')
            m = re.search(r'REG_SZ\s+(.*chrome\.exe)', data, re.IGNORECASE)
            if m:
                exe_path = m.group(1).strip()
                break
        except Exception:
            pass

    common_paths = [
        exe_path,
        r"C:\Program Files\Google\Chrome\Application\chrome.exe",
        r"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe",
    ]
    for path in common_paths:
        if path and os.path.exists(path):
            v = get_version_from_command([path, "--version"])
            if v:
                return v
    return None


def get_macos_version():
    path = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
    if os.path.exists(path):
        return get_version_from_command([path, "--version"])
    return None


def get_linux_version():
    for binary in ["google-chrome", "google-chrome-stable", "chromium", "chromium-browser"]:
        full = shutil.which(binary)
        if full:
            v = get_version_from_command([full, "--version"])
            if v:
                return v
    return None


def main():
    system = platform.system().lower()
    version = None

    if 'windows' in system:
        version = get_windows_version()
    elif 'darwin' in system:
        version = get_macos_version()
    elif 'linux' in system:
        version = get_linux_version()

    if version is None:
        print("UNKNOWN: Could not determine Chrome version on this host")
        sys.exit(2)

    if version < FIXED:
        print(f"VULNERABLE: Detected Chrome {version_str(version)} < {version_str(FIXED)}")
        sys.exit(1)
    else:
        print(f"PATCHED: Detected Chrome {version_str(version)} >= {version_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 managed browser patch, not an incident-response fire drill. Because the reassessed verdict is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice, push Chrome 149.0.7827.53 or newer through your normal browser ring now, verify update policy compliance this week, and complete fleet remediation within the noisgate remediation SLA of ≤365 days. Do not burn emergency change budget unless fresh exploitation evidence appears.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop
  2. Google Chrome Releases - Stable Channel Update for Desktop (May 12, 2026)
  3. Chromium issue tracker reference
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS API documentation
  7. CWE-416: Use After Free
  8. SynScan CVE mirror for CVE-2026-11230
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.