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

Heap buffer overflow in Media in Google Chrome prior to 149

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

This is a booby-trapped video player, not an open front door

CVE-2026-10946 is a heap buffer overflow in Chrome's Media component affecting Google Chrome before 149.0.7827.53. Google’s desktop stable release notes tie the fix to 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS; Android 149.0.7827.59 carries the same desktop security fixes. The bug is reachable by a remote attacker via crafted web content, but the published description says the victim must be convinced to perform specific UI gestures, which matters a lot in real enterprise exposure.

Google’s HIGH 7.5 label is basically fair, but it slightly overstates immediate enterprise urgency if you read it like a server-side RCE. This is a client-side browser memory corruption bug with high attack complexity, user interaction, and an implied need for the attacker to reliably steer a fragile media path; that is meaningful friction. The counterweight is obvious: Chrome is everywhere, attacker delivery is cheap, and browser memory corruption remains a favored initial-access route, so this stays HIGH, just not drop-everything CRITICAL.

"Internet-reachable browser bug, but the specific UI-gesture requirement keeps this out of panic mode."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled content

The attacker uses a crafted HTML page with malicious media content as the weaponized delivery vehicle. Delivery can be email links, malicious ads, SEO-poisoned pages, chat links, or a compromised site; no authentication is required because the browser is the target surface.
Conditions required:
  • Victim uses Chrome earlier than 149.0.7827.53
  • Victim can be induced to browse attacker-controlled or attacker-influenced content
  • The relevant media parsing path is present on the victim platform/build
Where this breaks in practice:
  • Enterprise web filtering, Safe Browsing, ad blocking, and URL reputation can kill the campaign before the page loads
  • This is endpoint software, not a server daemon; attackers must still get a human in front of the page
Detection/coverage: Version-based scanners and EDR software inventory can identify vulnerable Chrome builds reliably; network IDS coverage is weak because the trigger is application-content-specific.
STEP 02

Trigger the vulnerable media path with a required UI gesture

The advisory language says the victim must perform specific UI gestures, so this is not a clean zero-click drive-by. In practice that means the attacker likely needs the user to click play, interact with media controls, accept a prompt, or otherwise exercise a less common execution path in the Media stack.
Conditions required:
  • Victim performs the required browser/media interaction
  • Browser policies do not block the interaction pattern
  • The crafted media asset survives decoding long enough to hit the bug
Where this breaks in practice:
  • Autoplay restrictions, click-to-play controls, and user hesitation reduce trigger reliability
  • Phishing kits that depend on extra interaction convert worse than one-click lure pages
Detection/coverage: Little direct runtime coverage. Browser crash telemetry, suspicious tab lifecycle events, and repeated chrome process faults are more realistic than signature-based exploit detection.
STEP 03

Corrupt heap memory in the Media process

Once the crafted content reaches the vulnerable parser/decoder path, the bug causes a heap buffer overflow. That can yield a clean crash, partial corruption, or a controllable primitive depending on allocator state, platform defenses, and how precisely the attacker shapes memory layout.
Conditions required:
  • The malformed media reaches the exact vulnerable code path
  • Attacker can make corruption reliable on the target OS/architecture
  • The browser build lacks the patched fix
Where this breaks in practice:
  • Modern browser hardening makes turning memory corruption into stable code execution materially harder than the CVSS impact field suggests
  • Many real attempts will degrade into renderer or GPU/media-process crashes instead of useful exploitation
Detection/coverage: Crash dumps, Windows Event Logs, macOS unified logs, and Linux desktop crash reporting can show repeated chrome faults. Nessus/Qualys/Rapid7-style version checks are better than exploit detection.
STEP 04

Convert corruption into meaningful compromise

To get from a heap overwrite to enterprise-relevant impact, the attacker must turn the bug into a reliable exploit and then live within or escape Chrome's sandbox. For full host compromise, this often means pairing the browser bug with a second primitive or leveraging data/session theft from the browser context if the initial corruption does not cross the sandbox boundary.
Conditions required:
  • A reliable exploitation strategy exists for the victim platform
  • The attacker can work around sandboxing and exploit mitigations
  • The targeted browser context contains useful enterprise data or sessions
Where this breaks in practice:
  • A browser sandbox escape is a major practical hurdle and is not evidenced in the published advisory
  • EDR, browser isolation, and hardened host configurations reduce blast radius even when the browser is hit
Detection/coverage: Post-exploitation is where defenders regain visibility: child-process anomalies, token theft behavior, suspicious browser credential access, and EDR alerts around abnormal chrome descendants.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence located in the sources reviewed, and not listed in CISA KEV as of 2026-06-05.
PoC availabilityNo widely indexed public PoC found in reviewed searches across GitHub/Exploit-DB/Packet Storm terms for CVE-2026-10946; treat that as an absence of public indexing, not proof no private exploit exists.
EPSS0.00071 from the intel provided by the requester; that is very low modeled short-term exploitation probability. *Percentile was not confirmed from a primary source during this review.*
KEV statusNo. Not present in CISA’s Known Exploited Vulnerabilities catalog in the reviewed data.
CVSS vector readoutCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H = internet-deliverable with no auth, but high complexity and user interaction required. That is exactly why this is urgent patching, not emergency-war-room patching.
Affected versionsGoogle Chrome prior to 149.0.7827.53. Google’s desktop release notes show fixes landing in 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/macOS).
Fixed versions149.0.7827.53 (Linux), 149.0.7827.53/.54 (Windows/macOS), and 149.0.7827.59 (Android) with corresponding desktop security fixes.
Disclosure and reportingGoogle’s release channel and NVD-linked metadata show the issue was reported by Google on 2026-04-20 and publicly disclosed on 2026-06-04.
Researcher / orgGoogle is credited as the reporter in the stable channel bulletin.
Scanning / exposure realityShodan/Censys/FOFA/GreyNoise are a poor fit here because Chrome desktop is endpoint software, not an internet-listening service. Use EDR/MDM/browser inventory telemetry for exposure counts, not external internet census.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.1/10)

The decisive downward pressure is the specific UI-gesture requirement combined with high exploit complexity, which makes this materially less operationally useful than a one-click or zero-click browser bug. It stays HIGH because Chrome is a massively deployed initial-access surface and attacker delivery through normal web traffic is cheap even when the exploit chain itself is finicky.

HIGH Affected version floor and fixed release mapping
MEDIUM Assessment that public exploitation is not currently established
MEDIUM Real-world exploitability reduction from the UI-gesture requirement

Why this verdict

  • Baseline starts high: Chrome is ubiquitous, internet-facing by design, and memory corruption in the browser remains a proven initial-access class.
  • Friction adjustment down: the vendor vector already admits AC:H and UI:R, and the narrative adds specific UI gestures. That is a real conversion tax on attacker campaigns.
  • No exploitation amplifier: no KEV listing, no public exploitation evidence in reviewed sources, and a very low EPSS remove the main reasons to escalate this toward CRITICAL.

Why not higher?

There is no present evidence of active exploitation, and the trigger is not a simple one-click or zero-click web visit. Also, Chrome’s sandbox and modern exploit mitigations mean a media heap overflow does not automatically translate into dependable host compromise at enterprise scale.

Why not lower?

This is still a remote, attacker-controlled browser content path in one of the most common enterprise applications on earth. If an adversary wants an initial foothold, the browser is exactly where they shop, and memory corruption bugs with user interaction still get chained in real campaigns.

05 · Compensating Control

What to do — in priority order.

  1. Force auto-update — Push Chrome auto-update enforcement through GPO/MDM and verify clients are accepting the 149.0.7827.53+ train. For a HIGH verdict, deploy within 30 days if patching lags.
  2. Route risky users through browser isolation — Put internet-facing, high-click populations such as finance, HR, executives, and help desk behind remote browser isolation where available. This reduces host impact if the browser is hit; for a HIGH verdict, put the policy in place within 30 days.
  3. Harden media-heavy browsing paths — Use enterprise browser policy to restrict unnecessary media autoplay, limit risky consumer sites where business-justified, and keep Safe Browsing/web filtering at enforcement mode. These controls reduce the chance the required gesture path is reached; deploy within 30 days.
  4. Watch for Chrome crash clusters — Create a temporary hunt for repeated chrome crashes or abnormal browser child-process activity on vulnerable builds. This will not detect the exploit reliably, but it gives you a practical early-warning tripwire while patch coverage catches up; stand this up within 30 days.
What doesn't work
  • A perimeter firewall does not solve this; the exploit can arrive over perfectly normal outbound HTTPS to attacker-controlled web content.
  • MFA does not prevent trigger conditions; this is not an auth bug.
  • Traditional network vuln scanning has limited value beyond version inventory because there is no exposed service to probe from the outside.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/remote management tool as the logged-in user; no admin rights are required. Save as check_chrome_cve_2026_10946.py and run python3 check_chrome_cve_2026_10946.py on macOS/Linux or py check_chrome_cve_2026_10946.py on Windows. It checks common Chrome install paths, reads the local version, and prints VULNERABLE, PATCHED, or UNKNOWN.

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

import os
import platform
import re
import subprocess
import sys
from pathlib import Path

THRESHOLD = (149, 0, 7827, 53)

WINDOWS_PATHS = [
    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"),
]

MAC_PATHS = [
    "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
    str(Path.home() / "Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
]

LINUX_PATHS = [
    "/usr/bin/google-chrome",
    "/usr/bin/google-chrome-stable",
    "/opt/google/chrome/chrome",
    "/snap/bin/chromium",
]

VERSION_RE = re.compile(r"(\d+)\.(\d+)\.(\d+)\.(\d+)")


def parse_version(text):
    m = VERSION_RE.search(text or "")
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_ver(a, b):
    return (a > b) - (a < b)


def run_version(binary):
    try:
        proc = subprocess.run([binary, "--version"], capture_output=True, text=True, timeout=10)
        out = (proc.stdout or "") + " " + (proc.stderr or "")
        return parse_version(out)
    except Exception:
        return None


def powershell_file_version(path):
    cmd = [
        "powershell",
        "-NoProfile",
        "-Command",
        f"(Get-Item '{path}').VersionInfo.ProductVersion"
    ]
    try:
        proc = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (proc.stdout or "") + " " + (proc.stderr or "")
        return parse_version(out)
    except Exception:
        return None


def candidate_paths():
    system = platform.system().lower()
    if system == "windows":
        return WINDOWS_PATHS
    if system == "darwin":
        return MAC_PATHS
    return LINUX_PATHS


def discover_version():
    system = platform.system().lower()
    for p in candidate_paths():
        if p and os.path.exists(p):
            if system == "windows":
                v = powershell_file_version(p) or run_version(p)
            else:
                v = run_version(p)
            if v:
                return p, v
    return None, None


def main():
    path, version = discover_version()
    if not version:
        print("UNKNOWN: Google Chrome not found in common paths or version unreadable")
        sys.exit(2)

    if cmp_ver(version, THRESHOLD) < 0:
        print(f"VULNERABLE: Chrome version {'.'.join(map(str, version))} at {path} is older than 149.0.7827.53")
        sys.exit(1)
    else:
        print(f"PATCHED: Chrome version {'.'.join(map(str, version))} at {path} is 149.0.7827.53 or newer")
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a HIGH-priority endpoint/browser patching item, not an incident-response fire drill: use inventory to find Chrome builds below 149.0.7827.53, enforce compensating controls like browser isolation and policy hardening where patch rollout will lag, and complete those temporary protections within the noisgate mitigation SLA of 30 days. Then finish the actual browser update rollout within the noisgate remediation SLA of 180 days; because this is a browser memory-corruption bug on a ubiquitous client surface, most mature teams should realistically aim to beat that by a wide margin even without KEV or active-exploitation evidence.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop
  2. Chrome 149 release notes
  3. NVD record for CVE-2026-10946
  4. CISA Known Exploited Vulnerabilities catalog JSON
  5. FIRST EPSS API
  6. Canadian Centre for Cyber Security advisory AV26-544
  7. GovCERT.HK alert A26-06-08
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.