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

Use after free in Network in Google Chrome prior to 149

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

This is a cracked steering link in a company car fleet: one bad webpage can jerk the browser into memory corruption

CVE-2026-10882 is a use-after-free in Chrome's Network stack. Google fixed it in the Chrome 149 stable release posted on June 2, 2026, covering Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. The linked fix commit for bug 503420443 points at a lifetime bug in net/spdy, where a stream object could be destroyed during window-update handling and then touched again; that makes crafted page + attacker-controlled traffic shaping a credible trigger path, though some technical details remain restricted.

Vendor scoring lands at HIGH 8.8, and that is directionally fair for enterprise patching. Google’s release notes actually label this bug Critical in Chromium’s internal severity taxonomy, but in real fleets this still lands as HIGH, not CRITICAL, because there is no KEV listing, no public exploit, and no evidence of active exploitation, while modern Chrome mitigations like sandboxing, process isolation, and site isolation add real friction between a memory bug and full endpoint compromise.

"Dangerous browser bug, but not a fleet-panic zero-day: treat it as a high-priority Chrome update, not an emergency host takeover"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure the user into rendering attacker content

The attacker needs the victim to open a webpage under attacker control or to hit attacker-influenced web content such as a malvertising chain. The weaponized tooling here is usually a custom HTML/JavaScript heap groomer plus an attacker-controlled web server delivering protocol behavior that exercises Chrome networking paths.
Conditions required:
  • Victim runs vulnerable Chrome
  • Victim browses to attacker-controlled or attacker-influenced content
  • JavaScript and normal browser networking are allowed
Where this breaks in practice:
  • This is UI:R, so it is not wormable and not zero-click
  • Enterprise web filtering, DNS filtering, and browser isolation can cut reachability
  • Awareness training is weak protection here, but safe browsing controls do matter
Detection/coverage: Network scanners do not find this well; exposure is best measured by endpoint version inventory and browser telemetry.
STEP 02

Trigger the Network lifetime bug

Based on the public Chromium fix for bug 503420443, the vulnerable path appears tied to SPDY/HTTP2 stream window-update handling in the net stack. The likely weaponized tool is a malicious HTTP/2 server that shapes responses so Chrome hits the destroyed-object path and turns a stale pointer into memory corruption. This mapping from fix commit to exploit path is an inference from the public patch, because the bug tracker details remain restricted.
Conditions required:
  • Attacker can control response behavior from the remote server
  • Victim browser negotiates the relevant network path
  • Heap state is favorable enough to convert crash into corruption
Where this breaks in practice:
  • Turning a patch diff into a reliable trigger still takes real exploit engineering
  • Protocol-specific conditions narrow the path compared with a generic DOM bug
  • Some victims will only see a crash, not exploitability
Detection/coverage: Crash telemetry, browser hang/crash spikes, and EDR collection of repeated chrome faults are your best clues.
STEP 03

Stabilize memory corruption into code execution

The attacker then needs a second-stage exploit primitive: heap shaping, object replacement, and a control-flow win that survives modern browser hardening. Typical weaponized tooling here is a custom ROP/JOP stage or exploit chain tuned to the exact Chrome build and platform. Chrome’s allocator hardening, ASLR, CFI-style defenses, and sandbox boundaries are the big reasons this is not an automatic host compromise.
Conditions required:
  • Reliable memory corruption primitive
  • Target-specific exploit chain for the victim platform/build
  • Ability to bypass or survive modern browser mitigations
Where this breaks in practice:
  • Exploit reliability is materially harder on fully patched modern desktops
  • Different OS builds and channel versions break exploit portability
  • A lot of public browser bugs never graduate from crash to stable RCE
Detection/coverage: EDR can sometimes catch shellcode-like behavior, suspicious memory patterns, or exploit guard events, but coverage is inconsistent.
STEP 04

Escape the browser blast radius

If execution lands only in a constrained Chrome process, the attacker may still need a separate sandbox escape or privilege step for durable host impact. The weaponized tool here is usually a chained browser exploit, not a single CVE. That is the biggest downward pressure on severity versus the scary theoretical impact line in CVSS.
Conditions required:
  • Initial code execution lands in a sandboxed or low-privilege browser context
  • Attacker has a second bug or abuse path for broader host control
  • Target security stack fails to stop post-exploitation activity
Where this breaks in practice:
  • Chrome sandboxing and site isolation can contain one-bug chains
  • EDR, application control, and browser child-process monitoring raise attacker cost
  • No public evidence currently shows this CVE chained in the wild
Detection/coverage: Look for abnormal child processes from chrome.exe, unsigned payload drops, browser crash-then-spawn behavior, and exploit protection alerts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation evidence found in Google release notes, and not listed in CISA KEV as of 2026-06-05.
Public PoC availabilityNo public PoC or GitHub exploit located for CVE-2026-10882; the linked Chromium issue is still access-restricted.
EPSSNo FIRST EPSS score located for this CVE as of 2026-06-05; treat exploit probability as unknown, not low.
KEV statusNot KEV-listed; no CISA due date applies.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means remote, no auth, but user visit required; if exploitation works, theoretical impact is full within the affected security scope.
Affected versionsChrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS according to Google’s June 2, 2026 stable advisory.
Fixed versions149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS); Android’s corresponding release was 149.0.7827.59 and inherits the desktop security fixes. No distro backport advisory was located during this check.
Exposure / scanning realityShodan/Censys-style exposure data is not meaningful for a client browser bug. Measure risk by fleet version inventory, managed-browser coverage, and relaunch compliance, not internet scans.
Disclosure timelineYour intel says 2026-06-04, but Google’s stable-channel advisory was posted on 2026-06-02; use June 2, 2026 as the vendor disclosure date and treat later dates as downstream indexing/publication lag.
Reporter / technical clueGoogle credits c6eed09fc8b174b0f3eebedcceb1e792 on 2026-04-17. The public fix for bug 503420443 references net/spdy stream window-update lifetime handling, which is the best public clue to the vulnerable code path.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (8.2/10)

The decisive factor is exploit friction after the initial trigger: a user visit can reach the bug, but turning a modern Chrome network-stack use-after-free into stable endpoint compromise still has to beat browser hardening and often a sandbox boundary. The installed base is massive, so this stays HIGH, but the lack of KEV/ITW evidence keeps it out of the emergency bucket.

HIGH Affected version and fixed-version mapping
MEDIUM Exploit-path inference from the public patch
MEDIUM Final severity bucket

Why this verdict

  • Broad reachable population, but still a browser visit bug: attacker position is unauthenticated remote, yet UI:R means this is not self-propagating and still depends on web-delivery success.
  • Exploit engineering is the choke point: the public patch suggests a real network lifetime bug, but reliable weaponization must survive Chrome hardening, allocator behavior, and per-build instability.
  • Chrome’s fleet footprint keeps it high: even with friction, a remotely reachable bug in a top-endpoint application carries enough population and business exposure that backlog treatment would be irresponsible.

Why not higher?

There is no KEV entry, no public exploit, and no demonstrated in-the-wild use. More importantly, single-bug browser exploitation frequently stops at a crash or a sandboxed foothold unless the attacker also has a second stage, and that missing evidence is the main reason this is not CRITICAL.

Why not lower?

This is still a remote, no-auth browser memory-corruption bug in one of the most deployed enterprise applications on the planet. The only user action is opening content, and Google itself surfaced the issue as Critical in release notes, so dropping this to MEDIUM would understate real fleet risk.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update and relaunch — Push policy-backed Chrome auto-update, then enforce relaunch so patched binaries actually replace vulnerable ones. For a HIGH verdict, deploy this compensating control within 30 days, but in practice do it in the first few days because stale browser processes are where exposure hides.
  2. Block outdated Chrome from sensitive apps — Use endpoint compliance, ZTNA, or IdP device posture to deny access when Chrome is below the fixed build. This does not remove the bug, but it cuts high-value abuse paths while you finish patch coverage; deploy within 30 days.
  3. Isolate risky browsing cohorts — Put admins, finance, help desk, and developers behind remote browser isolation or a hardened VDI/browser container profile for untrusted web access. This is a good temporary blast-radius reducer while patch coverage converges; deploy within 30 days.
  4. Watch for crash and child-process anomalies — Hunt for repeated Chrome crashes, exploit-protection events, and suspicious child processes spawned from browser contexts. Detection is not prevention, but it is the fastest way to catch active abuse while patching catches up; enable and tune within 30 days.
What doesn't work
  • Perimeter vulnerability scanning does not meaningfully find vulnerable desktop browsers; this is an endpoint inventory problem.
  • MFA does nothing for initial exploitability here; this is a client-side memory bug, not an identity attack.
  • Signature-only AV is weak against a browser exploit chain that lives in memory and may never write a known payload to disk.
  • User awareness training alone is not enough because ordinary web browsing, ads, or compromised legitimate sites can supply the trigger.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/EDR script runner. Invoke it as python3 check_chrome_cve_2026_10882.py; it needs standard user rights on macOS/Linux and standard rights on Windows unless your environment blocks registry reads, in which case use a normal managed-user context.

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

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

FIXED_VERSION = (149, 0, 7827, 53)


def parse_version(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def version_to_str(v):
    return '.'.join(str(x) for x in v)


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


def get_windows_version():
    try:
        import winreg
    except Exception:
        return None

    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, path in reg_paths:
        try:
            with winreg.OpenKey(hive, path) as key:
                value, _ = winreg.QueryValueEx(key, 'version')
                v = parse_version(value)
                if v:
                    return v
        except OSError:
            continue
    return None


def get_macos_version():
    plist_paths = [
        '/Applications/Google Chrome.app/Contents/Info.plist',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/Info.plist'),
    ]
    for path in plist_paths:
        if os.path.exists(path):
            try:
                with open(path, 'rb') as f:
                    data = plistlib.load(f)
                v = parse_version(data.get('CFBundleShortVersionString', ''))
                if v:
                    return v
            except Exception:
                continue
    return None


def get_linux_version():
    candidates = ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']
    for cmd in candidates:
        exe = shutil.which(cmd)
        if not exe:
            continue
        try:
            out = subprocess.check_output([exe, '--version'], stderr=subprocess.STDOUT, text=True, timeout=5)
            v = parse_version(out)
            if v:
                return v
        except Exception:
            continue
    return None


def main():
    system = platform.system().lower()
    if system == 'windows':
        version = get_windows_version()
        product = 'Google Chrome on Windows'
    elif system == 'darwin':
        version = get_macos_version()
        product = 'Google Chrome on macOS'
    elif system == 'linux':
        version = get_linux_version()
        product = 'Google Chrome/Chromium on Linux'
    else:
        print('UNKNOWN - Unsupported OS: {}'.format(platform.system()))
        sys.exit(2)

    if not version:
        print('UNKNOWN - Could not determine installed browser version for {}'.format(product))
        sys.exit(2)

    print('Detected version: {}'.format(version_to_str(version)))
    print('Fixed threshold: {}'.format(version_to_str(FIXED_VERSION)))

    if compare_versions(version, FIXED_VERSION) >= 0:
        print('PATCHED')
        sys.exit(0)
    else:
        print('VULNERABLE')
        sys.exit(1)


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

If you remember one thing.

TL;DR
Monday morning, pull a fleet-wide Chrome version inventory, isolate every host below 149.0.7827.53, and force auto-update plus browser relaunch through your endpoint stack; where you cannot patch immediately, block old-browser access to sensitive SaaS and place high-risk users behind browser isolation. Because this lands HIGH with no current KEV or active exploitation evidence, the noisgate mitigation SLA is ≤30 days for temporary controls and the noisgate remediation SLA is ≤180 days for the vendor patch, but for a browser bug this exposed you should aim to finish managed endpoint patching in days and spend the remaining window chasing unmanaged stragglers.

Sources

  1. Google Chrome stable release 149 advisory
  2. Chromium issue 503420443
  3. Chromium fix commit tied to bug 503420443
  4. Chromium Security page
  5. Chromium Security Release Management
  6. Chromium Site Isolation
  7. CISA Known Exploited Vulnerabilities Catalog
  8. Canadian Centre for Cyber Security advisory AV26-544
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.