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

Use after free in Media in Google Chrome prior to 149

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

This is a burglar getting into the building lobby, not the executive floor

CVE-2026-11144 is a use-after-free in Chrome's Media component affecting desktop Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. The bug is triggered when Chrome processes attacker-controlled media content; the public description specifically calls out a crafted video file and the outcome is arbitrary code execution inside the Chrome sandbox.

paragraphs

"Real bug, but it's sandbox-only browser RCE with user interaction and no exploitation signal"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a malicious video payload

The attacker needs a user to open a web page or file that feeds Chrome a crafted video object. In practice this is a drive-by page, malvertising placement, or lure link using a custom HTML5 <video> delivery page informed by the Chrome advisory.
Conditions required:
  • Victim runs vulnerable Chrome prior to 149.0.7827.53/54
  • Victim renders attacker-controlled media content
  • Attacker can get traffic past web filtering or user skepticism
Where this breaks in practice:
  • This is UI:R; no render, no bug
  • Enterprise URL filtering, browser isolation, and safe-browsing controls cut down delivery success
  • A crafted video file is noisier than a pure network daemon exploit because it depends on user browsing behavior
Detection/coverage: Network scanners do not meaningfully detect this. Coverage is mostly version-based asset inventory plus web gateway telemetry on suspicious lure domains and browser crash telemetry.
STEP 02

Trigger the Media use-after-free

Once the payload is processed, the attacker attempts to hit the freed object lifetime window in the Media pipeline. The weaponized component here is a custom crafted media sample against Chrome Media, with the public reference being the Chromium issue.
Conditions required:
  • Specific vulnerable code path is reachable on the victim build
  • The crafted media format survives any transcoding or content rewriting
Where this breaks in practice:
  • Memory-corruption reliability varies by platform, allocator state, and build flags
  • Chrome's hardening and frequent version churn make one-shot reliability worse than the CVSS headline suggests
Detection/coverage: Exploit prevention and browser crash reporting may see access violations, but signature coverage is weak without a public PoC.
STEP 03

Gain renderer code execution inside the sandbox

Successful exploitation yields code execution inside the renderer sandbox, not immediate host compromise. The attacker has code execution in a tightly constrained browser process, which is why Google's own internal severity tagging for this CVE is only Medium in the release notes.
Conditions required:
  • Exploit achieves stable code execution
  • Renderer sandbox remains the initial security boundary
Where this breaks in practice:
  • Sandbox confinement is the single biggest downward pressure on real-world impact
  • Without a second vulnerability, the attacker is usually limited to the compromised browsing context
Detection/coverage: EDR can sometimes observe anomalous Chrome child behavior or post-exploitation staging, but the initial renderer compromise may look like a browser crash.
STEP 04

Chain a second bug or settle for limited impact

To turn this into meaningful workstation takeover, the attacker usually needs a sandbox escape, broker abuse, credential theft opportunity, or user-assisted follow-on. No public evidence in the assessed sources shows CVE-2026-11144 being chained in the wild, and it is not KEV-listed.
Conditions required:
  • Attacker has a usable second-stage escape or post-sandbox objective
  • Defender tooling fails to block follow-on payload delivery
Where this breaks in practice:
  • This is where many real attacks die; the first bug is not the whole compromise
  • Modern EDR, application control, and browser site isolation raise the cost of chaining
Detection/coverage: Follow-on stages are more detectable than the initial renderer hit: suspicious child processes, token abuse, broker interaction anomalies, or outbound C2 from Chrome descendants.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in the reviewed authoritative sources; not listed in CISA KEV
PoC availabilityNo public PoC located in the reviewed sources; Chromium bug details are access-restricted pending rollout on the issue tracker
EPSS0.00038 from provided intel; that is a very low exploitation probability signal. Percentile was not independently confirmed from FIRST during this assessment; see EPSS and API docs
KEV statusNot KEV-listed as of this assessment; CISA's catalog is the authoritative reference for known exploitation
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H scores it like network-delivered code exec, but the public description says inside a sandbox. That is exactly why raw CVSS overstates defender urgency here
Affected versionsChrome desktop prior to 149.0.7827.53; Windows/macOS stable rollout references 149.0.7827.53/54, Linux 149.0.7827.53 per Chrome Releases and Cyber Centre advisory
Fixed versions149.0.7827.53 or later is the safe operational floor for fleet validation; Windows/macOS may show .54 depending on channel packaging. Chrome Extended Stable is a separate track and should not be assumed to carry M149 fixes unless Google says so
Exposure / scanning dataShodan/Censys/FOFA are not meaningful here because this is a client-side browser parsing bug, not an internet-facing service. GreyNoise-style internet scan telemetry is similarly low-value for direct exposure measurement
Disclosure date2026-06-04 in the CVE feed aggregation; Chrome stable release carrying the fix published 2026-06-02
ReporterListed as Reported by Google on 2026-04-11 in the Chrome 149 stable release notes archive
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.3/10)

The decisive factor is that the published impact is code execution inside Chrome's sandbox, not a clean workstation takeover. That turns an ugly memory bug into a chain starter rather than a one-bug enterprise compromise, and there is no KEV or public exploitation evidence to cancel out that friction.

HIGH Attack-chain friction: user interaction plus sandbox containment materially reduce real-world impact
MEDIUM Threat intel picture: no public PoC or exploitation evidence found, but restricted Chromium bugs limit external visibility

Why this verdict

  • Start from 8.8, then cut hard for sandbox-only impact: the public description ends at code execution *inside* the sandbox, so this is not a full host compromise on its own
  • UI:R matters in fleets: the attacker must get a user to render crafted media, which implies delivery infrastructure, lures, and a reachable browsing path rather than unauthenticated service exploitation
  • Threat signal is weak: no KEV listing, no reviewed public campaign evidence, and EPSS 0.00038 all push this below emergency-patching territory despite Chrome's huge install base

Why not higher?

If this were paired with a public sandbox escape, active exploitation, or a broadly reliable one-click exploit chain, it would move up fast. But on the facts available, this is a renderer compromise that still needs another break in the chain to become a host-level incident.

Why not lower?

It is still a real memory-corruption bug in ubiquitous software with remote delivery through routine browsing. Even sandboxed renderer RCE deserves disciplined patching because Chrome is everywhere and browser bugs are common chain components.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update compliance — Use enterprise browser management to verify desktops actually advance past 149.0.7827.53; for a MEDIUM verdict there is no mitigation SLA, so fold this into the normal remediation program and complete patching within the 365-day remediation window, though most shops should clear browser laggards much sooner.
  2. Route risky browsing through isolation or hardened profiles — If you already operate browser isolation, high-risk user web filtering, or hardened browsing profiles for exposed teams, keep those controls on because they reduce the chance users ever render attacker-hosted media. There is no mitigation SLA for a MEDIUM call, so this is a risk-reduction step rather than an emergency containment action.
  3. Hunt for outdated Chrome versions — Query your EDR, software inventory, or management platform for Chrome builds below 149.0.7827.53 and remediate exceptions. This matters most on unmanaged endpoints, VDI gold images, kiosk systems, and infrequently rebooted devices.
  4. Watch browser crash and child-process telemetry — Use EDR and crash-report telemetry to flag repeated Chrome faults in media-heavy browsing sessions or anomalous child behavior from Chrome. This will not prevent exploitation, but it is the most realistic detective control if someone tries to weaponize the bug before your laggards update.
What doesn't work
  • A server-side WAF does not solve this; the exploit target is the client browser parsing attacker-controlled media, not your web app.
  • MFA does nothing for the exploit itself; this is not an authentication problem.
  • Network segmentation has little value for the initial trigger because the delivery path is ordinary outbound web browsing.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software distribution/EDR script runner. Invoke it as python3 check_chrome_cve_2026_11144.py or python check_chrome_cve_2026_11144.py --path "C:\Program Files\Google\Chrome\Application\chrome.exe"; no admin rights are required unless your EDR wrapper enforces them.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11144.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import argparse
import os
import platform
import re
import shutil
import subprocess
import sys
from typing import List, Optional, Tuple

SAFE_FLOOR = (149, 0, 7827, 53)


def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
    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_to_str(v: Tuple[int, int, int, int]) -> str:
    return '.'.join(str(x) for x in v)


def candidate_paths() -> List[str]:
    system = platform.system().lower()
    paths = []

    if system == 'windows':
        envs = [
            os.environ.get('ProgramFiles'),
            os.environ.get('ProgramFiles(x86)'),
            os.environ.get('LocalAppData')
        ]
        suffixes = [
            r'Google\Chrome\Application\chrome.exe',
            r'Chromium\Application\chrome.exe'
        ]
        for base in envs:
            if base:
                for suf in suffixes:
                    paths.append(os.path.join(base, suf))
    elif system == 'darwin':
        paths.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            '/Applications/Chromium.app/Contents/MacOS/Chromium'
        ])
    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
            found = shutil.which(name)
            if found:
                paths.append(found)
        paths.extend([
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser',
            '/snap/bin/chromium'
        ])

    seen = []
    for p in paths:
        if p and p not in seen:
            seen.append(p)
    return seen


def get_version_from_binary(path: str) -> Optional[Tuple[int, int, int, int]]:
    if not os.path.exists(path):
        return None
    commands = [
        [path, '--version'],
        [path, '-version']
    ]
    for cmd in commands:
        try:
            out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
            v = parse_version(out)
            if v:
                return v
        except Exception:
            pass
    return None


def main() -> int:
    parser = argparse.ArgumentParser(description='Check Chrome version for CVE-2026-11144 exposure')
    parser.add_argument('--path', help='Explicit path to Chrome/Chromium binary')
    args = parser.parse_args()

    paths = [args.path] if args.path else candidate_paths()
    checked = []

    for path in paths:
        if not path:
            continue
        checked.append(path)
        v = get_version_from_binary(path)
        if v is None:
            continue

        if v >= SAFE_FLOOR:
            print(f'PATCHED: {path} version {version_to_str(v)} >= {version_to_str(SAFE_FLOOR)}')
            return 0
        else:
            print(f'VULNERABLE: {path} version {version_to_str(v)} < {version_to_str(SAFE_FLOOR)}')
            return 1

    if checked:
        print('UNKNOWN: Chrome binary found but version could not be determined from: ' + ', '.join(checked))
    else:
        print('UNKNOWN: No Chrome/Chromium binary found in common locations; supply --path to check a specific install')
    return 2


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

If you remember one thing.

TL;DR
Monday morning, do not treat this like an internet-fire emergency; treat it like a high-volume browser hygiene item with good version enforcement. For a MEDIUM verdict there is noisgate mitigation SLAno mitigation SLA — go straight to the 365-day remediation window — but because Chrome updates are operationally cheap, you should still sweep lagging desktops and gold images this browser cycle and have vulnerable builds cleared well before the noisgate remediation SLA limit of 365 days.

Sources

  1. Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Chrome Releases archive entry with CVE-2026-11144 listing
  3. Chromium issue 501676175
  4. CIRCL Vulnerability-Lookup entry for CVE-2026-11144
  5. Canadian Centre for Cyber Security advisory AV26-544
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS overview
  8. FIRST EPSS API 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.