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

Use after free in TopChrome in Google Chrome prior to 148

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

This is a side door inside the bank vault, not the street-facing front door

CVE-2026-7970 is a use-after-free in Chrome's TopChrome browser-process UI code affecting Google Chrome before 148.0.7778.96 on desktop platforms. The bug does not hand an attacker initial code execution from a cold start; it is explicitly described as a flaw that can let an attacker who has already compromised the renderer process use a crafted HTML page to potentially escape the sandbox.

The vendor-style 8.3 CVSS overstates day-to-day enterprise urgency because it scores the post-exploitation impact of a sandbox escape more than the real-world entry conditions. In practice this is a second-stage browser exploit-chain component with meaningful value to capable attackers, but the prerequisite of prior renderer compromise, plus user interaction and high attack complexity, pushes this down from patch-now-everything territory to a solid MEDIUM.

"Useful to an exploit chain, but not a Monday-morning fire drill by itself."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land code execution in the renderer first

The attacker needs a separate renderer compromise first, typically a memory-corruption or logic bug that achieves code execution inside Chrome's sandboxed renderer. CVE-2026-7970 does not provide that first foothold; it only becomes relevant after the attacker already owns renderer execution. In exploit-chain terms, this is the bridge from sandboxed code execution to the more privileged browser process.
Conditions required:
  • A separate exploitable renderer bug or equivalent renderer compromise already exists
  • Target is running Chrome earlier than 148.0.7778.96
  • Victim reaches attacker-controlled content
Where this breaks in practice:
  • This prerequisite alone removes commodity opportunistic abuse
  • Modern site isolation, exploit mitigations, and browser hardening make reliable renderer compromise non-trivial
  • Many enterprise detections focus on the initial renderer exploit and may break the chain before this CVE matters
Detection/coverage: Version-only scanners can flag vulnerable Chrome builds, but they cannot tell you whether a renderer exploit chain exists in your environment.
STEP 02

Trigger the TopChrome lifetime bug from crafted web content

After renderer compromise, the attacker uses crafted HTML to drive the browser into the vulnerable TopChrome code path and hit the dangling reference. The bug lives in browser-process UI-adjacent code, so the exploitation objective is to pivot from low-privilege renderer control into a more trusted process boundary. The weaponized 'tool' here is simply the malicious web page plus the prior renderer exploit.
Conditions required:
  • Renderer code execution is stable enough to steer browser behavior
  • The vulnerable TopChrome path is reachable on the victim platform/build
  • The crafted page reaches the intended state without crashing first
Where this breaks in practice:
  • High-complexity memory-corruption exploitation means reliability is not guaranteed
  • Browser version drift and platform differences reduce one-size-fits-all exploitability
  • Chrome bug details were still access-restricted at publication, which slows copycat weaponization
Detection/coverage: Crash telemetry, unusual browser-process faults, and Chrome EDR child-process anomalies are more useful than network scanners.
STEP 03

Cross the sandbox boundary

If exploitation succeeds, the attacker escapes the renderer sandbox and gains code execution or equivalent control in a more privileged browser context. That materially increases post-exploitation options: data access broadens, local actions become easier, and follow-on OS-level abuse becomes more feasible. This is why sandbox escapes matter even when they are not initial-access bugs.
Conditions required:
  • Successful memory corruption without process termination
  • Relevant exploit mitigations do not stop the browser-process pivot
Where this breaks in practice:
  • EDR, crash protection, and exploit mitigations can break the chain after renderer compromise
  • The blast radius is still endpoint-local; this is not a wormable enterprise service flaw
Detection/coverage: Look for browser-process abnormal behavior after suspicious page loads: child process creation, LOLBin launches, credential store access, or unusual inter-process patterns.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed public in-the-wild exploitation found in the cited sources; CISA KEV did not list this CVE at time of review.
Proof-of-concept availabilityNo public PoC located in quick checks across public search results; Chromium bug details were access-restricted, which raises short-term weaponization friction.
EPSS0.00073 — extremely low, consistent with a niche exploit-chain component rather than broad opportunistic abuse.
KEV statusNot KEV-listed as of review; no CISA due date applies.
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the important parts are AC:H, UI:R, and the hidden real-world prerequisite: prior renderer compromise.
Vendor vs realityNVD/CISA-ADP shows 8.3 HIGH, but both NVD text and Ubuntu note Chromium security severity: Medium. I side with the browser team's framing because the prerequisite chain is the whole story here.
Affected versionsGoogle Chrome before 148.0.7778.96; NVD models this across Windows, macOS, and Linux desktop builds.
Fixed versionsGoogle patched in 148.0.7778.96 for Linux and 148.0.7778.96/.97 for Windows/Mac stable release notes. Debian backported fixes in chromium 148.0.7778.96-1~deb12u1 and 148.0.7778.96-1~deb13u1.
Scanning / exposure dataNot meaningfully internet-enumerable via Shodan/Censys/FOFA/GreyNoise because this is a client-side browser sandbox-escape component, not a remotely exposed network service. Exposure is your endpoint fleet size, not your public attack surface.
Disclosure / reportingPublished 2026-05-06; Chrome release notes say it was reported by Google on 2026-03-29 under issue 497487462.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.4/10)

The single biggest downward pressure is that exploitation requires prior renderer compromise, which means this CVE is usually post-initial-access inside the browser exploit chain, not the first breach event. That sharply narrows the attacker population and reachable exposure compared with a true drive-by RCE, even though the sandbox-escape impact is serious when chained.

HIGH Affected version range and fix version
HIGH Assessment that this is a chained sandbox escape, not an initial-access bug
MEDIUM Absence of public PoC / exploitation evidence at review time

Why this verdict

  • Downgrade for prerequisite chain: the attacker must already have renderer compromise, which implies a prior successful exploit stage and cuts out most commodity abuse.
  • Downgrade for exposure model: this is a client-side desktop browser flaw, not an internet-exposed enterprise service. Your blast radius is vulnerable endpoints that browse hostile content, not every external IP.
  • Hold at MEDIUM, not LOW: sandbox escapes are strategically valuable to capable actors because they turn renderer footholds into materially stronger endpoint compromise.

Why not higher?

There is no cited KEV entry, no confirmed public exploitation in the reviewed sources, and no public PoC surfaced during review. More importantly, this is not a cold-start browser RCE; it assumes the attacker already solved the harder first problem of landing renderer execution.

Why not lower?

A browser sandbox escape is not bookkeeping noise. Chrome is ubiquitous, the affected component sits across major desktop platforms, and any team facing phishing, watering-hole, or targeted-browser exploitation should treat sandbox-escape fixes as real chain-breakers.

05 · Compensating Control

What to do — in priority order.

  1. Constrain browser version drift — Use enterprise browser management to force Chrome/Chromium auto-update or tightly bounded rollout rings so vulnerable builds age out quickly. For a MEDIUM verdict there is no noisgate mitigation SLA; go straight to remediation within the 365-day window, but in practice browsers should be updated far sooner because stale browsers accumulate chainable bugs.
  2. Reduce untrusted browsing paths — Apply URL filtering, remote browser isolation for high-risk user groups, and stricter access rules for newly registered or uncategorized domains. This matters because CVE-2026-7970 still needs attacker-controlled content delivery even after the renderer-compromise prerequisite.
  3. Hunt for browser-to-OS pivots — Tune EDR to alert on chrome.exe/Chromium browser-process child creation, script interpreter launches, credential-store access, and post-browser LOLBin activity. This is the right compensating control when the vulnerability's value is in escaping containment rather than initial entry.
  4. Protect high-risk cohorts first — Prioritize admins, developers, executives, and users who routinely open external content or research unknown sites. These users are the most likely to encounter full exploit chains, so targeted hardening gets the best risk reduction while patching completes.
What doesn't work
  • A WAF does not help; this is a client-side browser flaw, not a web server parsing issue.
  • Perimeter network scanning does not help; there is no exposed listening service to fingerprint for this bug.
  • Relying on MFA alone does not break browser memory-corruption exploit chains on the endpoint.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your endpoint management agent. Invoke it as python3 check_chrome_cve_2026_7970.py with standard user rights; it checks common Chrome/Chromium install locations and prints VULNERABLE, PATCHED, or UNKNOWN.

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

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

THRESHOLD = (148, 0, 7778, 96)

CANDIDATES = {
    'Windows': [
        r'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Program Files\\Chromium\\Application\\chrome.exe',
        r'C:\\Program Files (x86)\\Chromium\\Application\\chrome.exe',
    ],
    'Darwin': [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
    ],
    'Linux': [
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
        '/snap/bin/chromium',
    ],
}


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 compare_versions(found, threshold):
    if found is None:
        return None
    if found < threshold:
        return -1
    return 0


def get_version_from_binary(path):
    try:
        result = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=10)
        output = (result.stdout or '') + ' ' + (result.stderr or '')
        return parse_version(output.strip())
    except Exception:
        return None


def get_existing_candidates():
    system = platform.system()
    candidates = []
    for p in CANDIDATES.get(system, []):
        if os.path.exists(p):
            candidates.append(p)
    if system == 'Linux':
        for cmd in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
            resolved = shutil.which(cmd)
            if resolved and resolved not in candidates:
                candidates.append(resolved)
    return candidates


def main():
    candidates = get_existing_candidates()
    if not candidates:
        print('UNKNOWN: Chrome/Chromium binary not found in common locations')
        sys.exit(2)

    checked = []
    vulnerable = []
    patched = []

    for path in candidates:
        ver = get_version_from_binary(path)
        checked.append((path, ver))
        cmp_result = compare_versions(ver, THRESHOLD)
        if cmp_result is None:
            continue
        if cmp_result < 0:
            vulnerable.append((path, ver))
        else:
            patched.append((path, ver))

    if vulnerable:
        details = '; '.join([f'{p}={".".join(map(str, v))}' for p, v in vulnerable])
        print(f'VULNERABLE: found Chrome/Chromium versions older than 148.0.7778.96 -> {details}')
        sys.exit(1)

    if patched:
        details = '; '.join([f'{p}={".".join(map(str, v))}' for p, v in patched])
        print(f'PATCHED: all detected Chrome/Chromium binaries are at or above 148.0.7778.96 -> {details}')
        sys.exit(0)

    checked_paths = '; '.join([f'{p}={(".".join(map(str, v)) if v else "unreadable")}' for p, v in checked])
    print(f'UNKNOWN: binaries found but version could not be determined -> {checked_paths}')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a fleet hygiene browser update with extra attention on high-risk users, not as a stop-the-world perimeter emergency. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA, but because this is a browser sandbox-escape building block you should still push Chrome/Chromium version validation and staged updates in your normal browser ring process this cycle rather than letting it age in backlog for quarters.

Sources

  1. NVD CVE-2026-7970
  2. Chrome Releases: Stable Channel Update for Desktop (2026-05-05)
  3. Chrome Releases: Early Stable Update for Desktop (2026-04-29)
  4. Chromium issue 497487462
  5. Ubuntu CVE-2026-7970
  6. CISA Known Exploited Vulnerabilities Catalog
  7. Debian DSA-6250-1 chromium security update
  8. FIRST EPSS overview / 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.