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

Use after free in V8 in Google Chrome prior to 149

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

This is a booby-trapped badge printer: dangerous only after someone lets the fake contractor into the building

CVE-2026-11185 is a use-after-free in V8 affecting Google Chrome before 149.0.7827.53. The described path is not classic drive-by web exploitation; the attacker must first convince a user to install a malicious Chrome extension, then trigger the memory corruption from that extension to get arbitrary code execution inside the browser sandbox.

The vendor's HIGH 8.1 score is technically understandable if you look only at memory corruption and code execution. In real fleets, though, the decisive fact is the attacker position requirement: this starts after extension installation, which sharply narrows reachable population in managed enterprises that use allowlists, block external extensions, or approval workflows. That makes the vendor label too hot for patch-priority purposes.

"V8 UAF is real, but needing a malicious extension first knocks this out of emergency patch territory."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Stage a malicious extension

The attacker needs a weaponized CRX / Chrome extension package with JavaScript that reaches the vulnerable V8 path. Delivery can be through a fake productivity add-on, a bundled installer, or a malicious/self-hosted extension flow documented for managed environments and Linux sideload scenarios.
Conditions required:
  • Attacker can socially engineer the target into installing an extension
  • Target uses Chrome on a vulnerable version prior to 149.0.7827.53
  • Extension installation is not fully locked down by enterprise policy
Where this breaks in practice:
  • Managed Chrome often uses ExtensionSettings, allowlists, or force-install-only models
  • Windows and macOS self-hosted installs are constrained to enterprise-policy paths
  • Store review and user prompts add visible friction
Detection/coverage: Network scanners will miss this entirely. Detect via browser-management telemetry, extension inventory, install events, and EDR correlation on chrome.exe plus new extension IDs.
STEP 02

Win the extension install

The victim must actually add the extension and grant its requested permissions. That is materially harder than getting a click on a web link because the user sees an install flow, and in mature fleets the browser may block or require approval for non-allowed extensions.
Conditions required:
  • User interaction occurs
  • User can install extensions in that profile/device state
  • No enterprise policy denies the extension ID or update URL
Where this breaks in practice:
  • User prompt fatigue is real, but many enterprises deny arbitrary extension installs outright
  • Security awareness, admin approval, and browser policy all interrupt the chain
  • Unmanaged BYOD/pop-up labs are more exposed than standard corporate builds
Detection/coverage: Chrome Enterprise policies and admin consoles can surface blocked requests, approved installs, and force-installed IDs. EDR can often log creation under Chrome extension directories.
STEP 03

Trigger the V8 use-after-free

Once installed, the extension runs the attacker-controlled JavaScript/DOM sequence needed to hit the vulnerable V8 lifetime bug. This is where the attacker uses a custom extension payload rather than a public weaponized framework; no credible public PoC was located in reviewed sources.
Conditions required:
  • Browser is still unpatched
  • Exploit chain is reliable enough for the target OS/build
  • Extension code can reach the vulnerable V8 behavior
Where this breaks in practice:
  • Memory corruption reliability varies by version, architecture, and heap state
  • Chrome's hardening and crash telemetry make one-shot exploitation noisy
  • No public PoC lowers opportunistic attacker reuse
Detection/coverage: Authenticated endpoint scanners can flag version only; they cannot prove exploitability. Browser crash spikes, unusual renderer failures, and extension-linked chrome.exe instability are your practical signals.
STEP 04

Land code execution inside the sandbox

Successful exploitation yields code execution inside the browser sandbox, not immediate OS-level compromise. To turn this into a bigger incident, the attacker still needs either extension permissions that already enable data theft or a second bug to escape the sandbox or pivot further.
Conditions required:
  • Exploit succeeds without browser crash
  • Attacker accepts sandboxed execution or has a follow-on chain
  • Valuable data is reachable from the browser context or extension permissions
Where this breaks in practice:
  • Sandbox containment caps blast radius versus a true system-level RCE
  • A second-stage escape is not provided by this CVE
  • EDR, browser isolation, and extension permission reviews can still reduce impact
Detection/coverage: Most vulnerability scanners stop at version detection. Behaviorally, look for suspicious extension permissions, unusual extension update URLs, browser child-process anomalies, and post-exploitation activity tied to Chrome profiles.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in reviewed sources as of 2026-06-05; not KEV-listed.
Public PoC availabilityNo public PoC located in reviewed GitHub/web results; Vulners did not show exploit references for this CVE.
EPSS0.00015 (user-supplied), which is operationally very low. I could not independently retrieve the live FIRST percentile from an authoritative source during this check.
KEV statusAbsent from CISA KEV as of 2026-06-05.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N overstates enterprise reach because the practical first gate is malicious extension installation, not just ordinary web browsing.
Chromium internal severityA third-party NVD mirror shows Chromium security severity: Medium for this entry, which matches the real-world friction better than the vendor's HIGH 8.1.
Affected versionsGoogle Chrome before 149.0.7827.53. The release train shows 149.0.7827.53/.54 for Windows/macOS early stable and 149.0.7827.53 for Linux.
Fixed versions149.0.7827.53+ on Linux and 149.0.7827.53/.54+ on Windows/macOS. I found no authoritative distro-backport statement for this specific CVE, so do not assume older package lines are safe.
Scanning and exposureThis is not meaningfully Shodan/Censys/FOFA-addressable; exposure is endpoint-centric. Your real population is Chrome endpoints that still permit arbitrary extension installs.
Disclosure and attributionDisclosed 2026-06-04. I found no public researcher attribution in the reviewed sources.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.8/10)

The single factor that drives this down is the need to get a malicious extension installed first. In a managed enterprise, that prerequisite implies either failed extension governance or a narrow unmanaged subset, which cuts reachable population far more than the raw V8 bug class suggests.

HIGH Affected version range and fixed release line
MEDIUM Reassessment of exploitability in managed enterprise fleets
MEDIUM Lack of public PoC / exploitation evidence at time of review

Why this verdict

  • Big downward adjustment: requires malicious extension installation first. That is not unauthenticated remote reach in the way defenders hear AV:N; it implies successful social engineering plus a browser posture that still permits the install. In enterprises with extension governance, reachable population often drops from 'whole fleet' to 'exceptions and unmanaged edge cases'.
  • Another downward adjustment: execution is inside the browser sandbox. That's serious, but it is not the same as direct OS compromise, and the CVE text itself does not give you the sandbox escape.
  • More downward pressure: threat intel is cold. No KEV listing, no confirmed active exploitation, no public PoC found, and the supplied EPSS 0.00015 is near the noise floor.

Why not higher?

If this were a drive-by V8 RCE from a normal web page, or if there were KEV/active exploitation, this would sit much higher. But the chain begins only after a user installs attacker code as an extension, which is a compound prerequisite that many real fleets already suppress.

Why not lower?

This still involves memory corruption in V8, on an extremely common browser, with confidentiality and integrity impact inside a highly sensitive user application. Unmanaged laptops, developer workstations, contractors, and BYOD users who can install extensions are real exposure pockets, so this is not backlog fluff.

05 · Compensating Control

What to do — in priority order.

  1. Lock down extension installs — Use ExtensionSettings, allowlists, and ExtensionInstallBlocklist / BlockExternalExtensions so users cannot freely add arbitrary extensions. For a MEDIUM verdict there is no mitigation SLA, but this is the highest-value compensating control and should be applied in the next policy refresh cycle while you work through the patch.
  2. Inventory and review installed extension IDs — Pull fleet-wide extension inventory from Chrome management, EDR, or profile inspection and flag unapproved IDs, self-hosted update URLs, and recent installs. There is no mitigation SLA — go straight to the 365-day remediation window, but do this early because it tells you whether the vulnerable precondition even exists in your estate.
  3. Block external/self-hosted extension paths — Disable external extension installation and restrict self-hosted update URLs unless there is a documented business case. This matters because the described chain becomes materially easier when users or bundled software can land extensions outside the normal approval path.
  4. Monitor extension-install and Chrome crash telemetry — Create detections for new extension directories, registry/policy changes affecting extension install behavior, and abnormal Chrome/renderer crash clusters tied to recently installed extensions. For this MEDIUM finding there is no formal noisgate mitigation deadline, but these detections are cheap insurance while remediation runs.
What doesn't work
  • A WAF or email gateway alone does not solve this, because the decisive step is extension installation on the endpoint, not malformed network traffic to a server you control.
  • External perimeter scanning is mostly useless here; there is no internet-exposed listening service to fingerprint for this bug.
  • Assuming Chrome auto-update eventually handled it is not verification. Enterprises routinely have lagging channels, pinned versions, VDI gold images, and offline machines.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory/remote execution tooling. Invoke it as python3 check_cve_2026_11185.py on macOS/Linux or py check_cve_2026_11185.py on Windows; no admin rights are required for standard checks, though enterprise-managed installations may expose more paths if run elevated.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11185.py
# Detects whether locally installed Google Chrome is vulnerable to CVE-2026-11185
# Affected: Google Chrome versions prior to 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys

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


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 check_binary(path):
    if not path or not os.path.exists(path):
        return None
    out = run_cmd([path, '--version'])
    v = parse_version(out)
    if v:
        return {'path': path, 'version': v, 'source': 'binary'}
    return None


def windows_checks():
    results = []
    candidates = [
        r'C:\Program Files\Google\Chrome\Application\chrome.exe',
        r'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe',
        os.path.expandvars(r'%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe'),
    ]
    for c in candidates:
        item = check_binary(c)
        if item:
            results.append(item)

    try:
        import winreg  # type: ignore
        reg_paths = [
            (winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon'),
            (winreg.HKEY_LOCAL_MACHINE, r'Software\Google\Chrome\BLBeacon'),
            (winreg.HKEY_LOCAL_MACHINE, r'Software\WOW6432Node\Google\Chrome\BLBeacon'),
        ]
        for hive, subkey in reg_paths:
            try:
                k = winreg.OpenKey(hive, subkey)
                val, _ = winreg.QueryValueEx(k, 'version')
                v = parse_version(val)
                if v:
                    results.append({'path': subkey, 'version': v, 'source': 'registry'})
            except OSError:
                pass
    except Exception:
        pass

    return results


def mac_checks():
    results = []
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for c in candidates:
        item = check_binary(c)
        if item:
            results.append(item)
    return results


def linux_checks():
    results = []
    commands = [
        'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser'
    ]
    for cmd in commands:
        full = shutil.which(cmd)
        if full:
            item = check_binary(full)
            if item:
                results.append(item)

    candidates = [
        '/opt/google/chrome/chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
    ]
    for c in candidates:
        item = check_binary(c)
        if item:
            results.append(item)
    return results


def dedupe(results):
    seen = set()
    out = []
    for r in results:
        key = (r['path'], r['version'], r['source'])
        if key not in seen:
            seen.add(key)
            out.append(r)
    return out


def main():
    system = platform.system().lower()
    results = []

    if 'windows' in system:
        results = windows_checks()
    elif 'darwin' in system or 'mac' in system:
        results = mac_checks()
    else:
        results = linux_checks()

    results = dedupe(results)

    if not results:
        print('UNKNOWN: Google Chrome not found or version could not be determined')
        sys.exit(2)

    vulnerable = []
    patched = []
    unknown = []

    for r in results:
        v = r.get('version')
        if not v:
            unknown.append(r)
        elif v < THRESHOLD:
            vulnerable.append(r)
        else:
            patched.append(r)

    if vulnerable:
        details = '; '.join([f"{x['path']}={version_str(x['version'])}" for x in vulnerable])
        print(f'VULNERABLE: installed Google Chrome version(s) below {version_str(THRESHOLD)} detected: {details}')
        sys.exit(1)

    if patched:
        details = '; '.join([f"{x['path']}={version_str(x['version'])}" for x in patched])
        print(f'PATCHED: detected installed Google Chrome version(s) at or above {version_str(THRESHOLD)}: {details}')
        sys.exit(0)

    print('UNKNOWN: Chrome found, but version state could not be classified')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning, do two things in parallel: query your fleet for Chrome versions below 149.0.7827.53 and identify where users can still install arbitrary extensions. This is a MEDIUM finding, so there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window, and the noisgate remediation SLA is patch within 365 days; practically, you should clean up unmanaged extension posture this quarter and fold the browser update into your normal workstation/browser servicing cycle rather than breaking glass for an all-hands emergency rollout.

Sources

  1. Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome Enterprise Policy - Extension Settings
  3. Chrome Enterprise Policy - Block External Extensions
  4. Chrome for Developers - Distribute your extension
  5. Chrome for Developers - Alternative extension installation methods
  6. CISA Known Exploited Vulnerabilities JSON feed
  7. Third-party CVE/NVD mirror showing CVE-2026-11185 summary and Chromium severity
  8. Vulners entry for CVE-2026-11185
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.