← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-10905 · 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 the second key in a two-key vault, not a burglar opening the front door

CVE-2026-10905 is a use-after-free in Chrome's Network component affecting Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS. Per the CNA description you provided, exploitation requires an attacker to have already compromised the renderer process and then use this bug to move past that boundary, i.e. a likely sandbox-escape / privilege-boundary crossing step rather than initial code execution.

Google's HIGH 8.3 label is technically fair in isolation because a renderer-to-browser escape in Chrome matters. But in real enterprise patch triage, this is not an unauthenticated internet-to-endpoint compromise by itself. The decisive friction is the prerequisite: the attacker must first land a separate renderer exploit or comparable foothold, which turns this from a broad fleet emergency into a chain-dependent post-compromise enabler.

"This is a chain-finisher, not an entry bug: dangerous in elite exploit chains, but not your first patch fire."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land renderer code execution with a separate bug

The attacker first needs a different vulnerability that yields code execution or equivalent control inside Chrome's sandboxed renderer. This CVE does not supply that initial foothold; it only becomes useful once the renderer is already compromised. In practice this means a private exploit chain, a 1-day renderer bug, or a malicious extension / content path that gives comparable renderer influence.
Conditions required:
  • Victim uses a vulnerable Chrome build before 149.0.7827.53/54
  • Attacker has a separate working renderer-compromise primitive
  • Victim reaches attacker-controlled content or installs attacker-controlled browser content
Where this breaks in practice:
  • Requires a second bug or pre-existing foothold before this CVE matters
  • Renderer RCE chains are expensive and not commodity-grade for most actors
  • Modern browser mitigations, exploit mitigations, and site isolation raise exploit-development cost
Detection/coverage: No scanner will prove step 1 from version data alone. Detect with browser telemetry, extension inventory, EDR child-process anomalies, crash spikes, and exploit-protection events.
STEP 02

Trigger the Network use-after-free from the compromised renderer

With renderer control, the attacker drives the vulnerable Network code path and attempts to reclaim freed memory into attacker-controlled objects. This is the classic memory-corruption stage where reliability determines whether the bug is just a crash or a usable boundary-crossing primitive. There is no public weaponized PoC located in primary-source review, so real exploitation likely depends on private research.
Conditions required:
  • Reliable renderer foothold already exists
  • Attacker can reach the vulnerable Network code path from that context
  • Target configuration matches the exploit developer's assumptions
Where this breaks in practice:
  • Use-after-free bugs are often unstable across builds and platforms
  • Exploit reliability can break under allocator hardening and version drift
  • Restricted bug details slow copycat weaponization
Detection/coverage: Version scanners can identify exposure. Runtime detection is weak; likely signals are renderer/browser crashes, abnormal Chrome termination, and EDR memory-corruption heuristics.
STEP 03

Cross the sandbox boundary

If exploitation succeeds, the attacker can move from the low-privilege renderer into a more trusted browser or system-relevant context. That is the whole reason this class of bug matters: Chrome is designed to assume renderer compromise can happen and uses sandboxing to contain it. This CVE threatens that containment layer.
Conditions required:
  • Successful memory corruption in the Network component
  • Exploit chain survives modern Chromium hardening
  • Target endpoint permits useful post-escape actions
Where this breaks in practice:
  • Chrome sandbox design is specifically meant to make this step hard
  • EDR, exploit prevention, and application control may still stop follow-on payloads
  • Impact can remain local to the user context if post-escape privilege elevation is absent
Detection/coverage: Look for browser process injection, suspicious child processes from Chrome, unexpected network beacons, credential store access, and post-browser LOLBin activity.
STEP 04

Operationalize endpoint access

After the boundary crossing, the attacker still needs a practical post-exploitation objective: steal session material, drop malware, or pivot through the user context. This is where enterprise defenses outside the browser matter most. The bug's blast radius depends heavily on what the user can access and what endpoint controls are enforced.
Conditions required:
  • Successful sandbox escape
  • Useful user privileges or accessible sensitive data
  • No effective EDR/AppControl containment
Where this breaks in practice:
  • Least-privilege endpoints reduce blast radius
  • Credential protections and MFA limit token abuse
  • EDR containment can cut the chain before persistence or lateral movement
Detection/coverage: Strong EDR coverage should catch most follow-on tradecraft even if the browser exploit itself is quiet.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in reviewed primary sources; the bug is not KEV-listed.
Public PoC availabilityNo public PoC located in primary-source review. Chromium issue details appear restricted, which is normal until broad patch uptake.
EPSS0.00068 per your intel. That is a very low predicted near-term exploitation probability; percentile was not verified from a primary EPSS record in this review.
KEV statusNo. As of the reviewed CISA KEV catalog, CVE-2026-10905 does not appear listed.
CVSS vector meaningCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H means network-reachable with user interaction and high complexity, plus scope change consistent with crossing a trust boundary such as Chrome's sandbox.
Affected versionsGoogle Chrome prior to 149.0.7827.53; Chrome stable notes show patched builds as 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS).
Fixed versionsPatch to 149.0.7827.53 or later. On Windows/macOS, 149.0.7827.54 is also part of the stable fix release.
Exposure realityThis is client software, not a server-side listening service. There is no meaningful Shodan/Censys-style internet exposure surface to count; exposure is driven by endpoint fleet size and patch lag, not public ingress.
Disclosure timelineDisclosed 2026-06-04 per your intel. Google published the Chrome 149 stable patch on 2026-06-02.
Researcher / reportingGoogle's stable release notes attribute the bug to c6eed09fc8b174b0f3eebedcceb1e792, reported on 2026-02-25.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

The single biggest reason this drops to MEDIUM is the attacker position requirement: this bug only matters after the renderer is already compromised. That makes CVE-2026-10905 a chain component for sophisticated operators, not a stand-alone fleet-wide breach path for commodity attackers.

HIGH Patch/build identification and affected version range
MEDIUM Assessment that this is a sandbox-escape style chain component based on the provided CNA description
MEDIUM Real-world exploitability downgrade versus vendor CVSS

Why this verdict

  • Downgrade for attacker position: the bug requires a pre-compromised renderer, which implies the attacker has already solved initial code execution with a separate exploit stage.
  • Downgrade for reachable population: Chrome is everywhere, but this specific step is only reachable in the subset of attacks where a working renderer exploit already exists; that is a much narrower real-world slice than the vendor score assumes.
  • Downgrade for defensive friction: Chrome sandboxing, site isolation, allocator hardening, EDR, and exploit protections all stack against reliable weaponization of a UAF chain step.
  • Keep it above LOW: if paired with a renderer exploit, the bug can break a critical trust boundary on high-value endpoints, so the impact ceiling remains serious even if prevalence is low.
  • No threat intelligence amplifier: no KEV listing, no confirmed in-the-wild use, and a very low EPSS score remove the usual upward pressure.

Why not higher?

Because this is not initial access. Requiring prior renderer compromise means the attack already depends on a separate exploit stage, which sharply reduces both the exposed population and the number of actors capable of using it effectively. Absent KEV, active exploitation, or a public weaponized chain, this does not earn a HIGH/CRITICAL operational priority.

Why not lower?

Because the trust boundary at stake is important. A browser sandbox escape on a widely deployed endpoint platform is still dangerous once chained, especially on privileged admin workstations or users with rich SaaS session access. This is too consequential to treat as backlog-only hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Enforce rapid browser auto-update — Make sure managed Chrome channels are not pinned below 149.0.7827.53/54 and that update suppression policies are removed. For a MEDIUM noisgate rating there is no mitigation SLA, so treat this as operational hardening while you move through the remediation window.
  2. Prioritize high-value workstation rings — Push validation and update confirmation first on admin endpoints, developer workstations, VDI images, and browser-heavy user groups where a sandbox escape is most valuable to attackers. There is no mitigation SLA for MEDIUM, but these rings are where the exploit chain would pay off most.
  3. Hunt for Chrome crash anomalies — Look for unusual Chrome renderer/browser crashes, repeated relaunches, or exploit-protection telemetry around the disclosure window. That will not prove exploitation, but it is one of the few practical signals for memory-corruption attempts before a patch reaches full fleet coverage.
  4. Reduce post-browser blast radius — Confirm EDR tamper protection, application control, least privilege, and credential protections on endpoints so a successful sandbox escape has less room to operationalize. For this verdict, use the normal remediation motion rather than emergency containment.
What doesn't work
  • A WAF does not help; this is a client-side browser memory corruption issue, not a server-side web app flaw.
  • Perimeter network segmentation does not meaningfully prevent the vulnerable code path from being reached through normal browsing.
  • Email filtering alone is insufficient because the initial lure could just be a visited website, ad chain, chat link, or other user-driven web content.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software inventory agent. Invoke it with python3 verify_cve_2026_10905.py on Linux/macOS or py verify_cve_2026_10905.py on Windows; no admin rights are required if Chrome is installed in standard locations. The script checks local Chrome version and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# verify_cve_2026_10905.py
# Checks whether local Google Chrome is below 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from shutil import which

PATCHED_MIN = (149, 0, 7827, 53)


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


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=5)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def find_linux_version():
    candidates = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium', '--version'],
        ['chromium-browser', '--version'],
    ]
    for cmd in candidates:
        if which(cmd[0]):
            out = run_cmd(cmd)
            ver = parse_version(out)
            if ver:
                return ver, cmd[0], out
    paths = [
        '/opt/google/chrome/chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/snap/bin/chromium',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
    ]
    for path in paths:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return ver, path, out
    return None, None, None


def find_macos_version():
    paths = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
    ]
    for path in paths:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return ver, path, out
    return None, None, None


def find_windows_version():
    paths = [
        os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles%\Chromium\Application\chrome.exe'),
    ]
    for path in paths:
        if os.path.exists(path):
            ps = (
                "$p='{}';"
                "if (Test-Path $p) {{"
                "  (Get-Item $p).VersionInfo.ProductVersion"
                "}}"
            ).format(path.replace("'", "''"))
            out = run_cmd(['powershell', '-NoProfile', '-Command', ps])
            ver = parse_version(out)
            if ver:
                return ver, path, out
    return None, None, None


def main():
    system = platform.system().lower()
    if 'linux' in system:
        ver, source, raw = find_linux_version()
    elif 'darwin' in system:
        ver, source, raw = find_macos_version()
    elif 'windows' in system:
        ver, source, raw = find_windows_version()
    else:
        print('UNKNOWN - Unsupported OS: {}'.format(platform.system()))
        sys.exit(2)

    if not ver:
        print('UNKNOWN - Chrome/Chromium version not found')
        sys.exit(2)

    if ver < PATCHED_MIN:
        print('VULNERABLE - version {} detected from {}'.format('.'.join(map(str, ver)), source))
        sys.exit(1)
    else:
        print('PATCHED - version {} detected from {}'.format('.'.join(map(str, ver)), source))
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: treat this as a browser fleet hygiene item with elevated interest for high-value workstations, not as a fleet-wide incident. Because the noisgate verdict is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice, confirm your managed Chrome channels are auto-updating and clear any version pinning now, then complete rollout to 149.0.7827.53/54 or later within the noisgate remediation SLA of 365 days. If you have privileged admin endpoints or users who live in the browser, move them earlier inside your normal patch cycle even though this CVE does not justify an emergency blast.

Sources

  1. Google Chrome stable channel update for Desktop 149
  2. Chromium issue tracker reference for CVE-2026-10905
  3. Chromium Security page
  4. Chromium Site Isolation overview
  5. Chromium memory safety overview
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS project
  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.