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.
4 steps from start to impact.
Lure the user into rendering attacker content
- Victim runs vulnerable Chrome
- Victim browses to attacker-controlled or attacker-influenced content
- JavaScript and normal browser networking are allowed
- 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
Trigger the Network lifetime 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.- 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
- 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
chrome faults are your best clues.Stabilize memory corruption into code execution
- Reliable memory corruption primitive
- Target-specific exploit chain for the victim platform/build
- Ability to bypass or survive modern browser mitigations
- 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
Escape the browser blast radius
- 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
- 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
chrome.exe, unsigned payload drops, browser crash-then-spawn behavior, and exploit protection alerts.The supporting signals.
| In-the-wild status | No active exploitation evidence found in Google release notes, and not listed in CISA KEV as of 2026-06-05. |
|---|---|
| Public PoC availability | No public PoC or GitHub exploit located for CVE-2026-10882; the linked Chromium issue is still access-restricted. |
| EPSS | No FIRST EPSS score located for this CVE as of 2026-06-05; treat exploit probability as unknown, not low. |
| KEV status | Not KEV-listed; no CISA due date applies. |
| CVSS vector meaning | CVSS: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 versions | Chrome 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 versions | 149.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 reality | Shodan/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 timeline | Your 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 clue | Google 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. |
noisgate verdict.
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.
Why this verdict
- Broad reachable population, but still a browser visit bug: attacker position is unauthenticated remote, yet
UI:Rmeans 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.
What to do — in priority order.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.