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

Type confusion in V8 in Google Chrome prior to 138

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

This is a bad lock on a car door, not a magic key to every machine

CVE-2025-6554 is a V8 type confusion bug in Chrome that affects desktop releases before 138.0.7204.96 on Windows, before 138.0.7204.92/.93 on macOS, and before 138.0.7204.92 on Linux. A malicious site can feed crafted HTML/JavaScript into the browser and turn that memory-safety mistake into an arbitrary read/write primitive inside the browser process.

Google's HIGH 8.1 baseline is basically fair. The big downward pressures are real: the attacker still needs user interaction, a reachable vulnerable browser, and in many full-compromise scenarios a second bug or a browser sandbox escape. But those frictions are offset by the two facts that matter most to an enterprise fleet manager: Chrome is everywhere and Google plus CISA both confirm real-world exploitation.

"Active exploitation keeps this high, but this bug still needs a user visit and likely a second bug for full host compromise."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled web content

The operator uses a malicious site, injected ad, phishing link, or compromised legitimate page to serve crafted HTML and JavaScript to Chrome. The practical weapon here is just web content, which makes delivery cheap and scalable once a target clicks or browses there.
Conditions required:
  • Target uses Chrome/Chromium-based browser in the affected range
  • Target visits attacker-controlled or attacker-influenced content
  • JavaScript execution is allowed
Where this breaks in practice:
  • Requires UI:R; no click, no bug
  • Email gateways, Safe Browsing, DNS filtering, and browser isolation cut a lot of commodity delivery
  • Internal-only or kiosk workflows with restricted browsing reduce reachable population
Detection/coverage: Very little scanner value here; look instead for phishing telemetry, web proxy logs, Safe Browsing hits, and unusual visits immediately preceding browser crashes.
STEP 02

Trigger the V8 type confusion and win a renderer primitive

The exploit uses crafted JavaScript/HTML to hit the V8 type confusion and obtain arbitrary read/write in the browser's renderer context. This is the step directly covered by CVE-2025-6554 and the June 30, 2025 Chrome advisory.
Conditions required:
  • Correct vulnerable build and platform
  • Exploit reliably shaped for that Chrome/V8 release
  • Browser-side mitigations not sufficient to break the exploit chain
Where this breaks in practice:
  • Browser exploitation is version-fragile; heap shaping and reliability are not one-size-fits-all
  • Google pushed a configuration mitigation on June 26, 2025 before the stable update
  • Patch levels move quickly in managed Chrome fleets
Detection/coverage: Traditional vuln scanners only see version state. Runtime detection is weak unless the exploit crashes the renderer or chains into a noisier second stage.
STEP 03

Abuse browser-process access for theft or staging

From the compromised renderer, the attacker can try to steal data available in that browsing context, abuse authenticated sessions, or prepare a second exploit. The practical tool here is a post-exploitation JavaScript/WASM stage plus network exfiltration, not a loud binary dropper by default.
Conditions required:
  • Victim is authenticated to useful SaaS/apps
  • Sensitive content is reachable from the compromised browsing session
  • Outbound exfiltration is not blocked
Where this breaks in practice:
  • Chrome sandboxing and site isolation limit what a single renderer bug gets you
  • HttpOnly cookies, CSP, CASB controls, and browser isolation narrow easy data theft paths
  • Without a second bug, impact may stay inside the browser/session boundary
Detection/coverage: Watch proxy/DLP/CASB for abnormal browser-originated exfiltration. EDR usually sees little until the chain escapes the browser or launches a native payload.
STEP 04

Chain to full device compromise only if a second bug is available

For host-level code execution or sandbox escape, attackers often need another vulnerability beyond this read/write primitive. In other words, this CVE is dangerous alone, but devastating mainly as part of a chain.
Conditions required:
  • Operator has or acquires a compatible second-stage exploit
  • Target defenses fail to stop the post-renderer stage
Where this breaks in practice:
  • No public, authoritative exploit chain showing guaranteed one-bug full host compromise was available at review time
  • EDR, exploit protection, and OS hardening are much more likely to catch the native stage than the initial renderer bug
Detection/coverage: High if it crosses into OS compromise: child-process anomalies, memory-injection alerts, persistence attempts, credential access, and egress to C2.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusConfirmed exploited. Google states it is aware of an exploit in the wild, and CISA added it to KEV on 2025-07-02.
KEVListed in CISA KEV as *Google Chromium V8 Type Confusion Vulnerability*; KEV due date was 2025-07-23 for FCEB agencies.
Proof-of-concept availabilityPublic GitHub material exists, but what's readily visible is mixed quality. The clearly visible repo from Muhammednihalmp is training-oriented and non-weaponized; other repo names are surfaced by aggregators, but reliability and completeness are unclear.
EPSSUser-supplied EPSS is 0.0158. That's low in isolation, but for a KEV-listed browser zero-day EPSS is not the deciding signal.
CVSS vector meaningAV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N means remote, no auth, low complexity, but user interaction is required and the published impact does not claim direct availability loss.
Affected versionsChrome before 138.0.7204.96 per CNA/NVD, with Google shipping fixes as 138.0.7204.96/.97 for Windows, 138.0.7204.92/.93 for macOS, and 138.0.7204.92 for Linux.
Fixed versions and backportsGoogle patched on 2025-06-30. Debian tracked the Chromium fix as 138.0.7204.92-1~deb12u1 for bookworm backports.
Exposure / scanning realityThis is client software, so internet scanners like Shodan/Censys/FOFA are mostly useless for direct exposure measurement. Your exposure is the size of your Chrome fleet and how quickly you can force browser restart plus update adoption.
Disclosure and reportingPublished 2025-06-30; reported by Clément Lecigne of Google's Threat Analysis Group on 2025-06-25; Google says a config mitigation was pushed on 2025-06-26.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (8.0/10)

The decisive factor is active exploitation of a ubiquitous endpoint application: when the browser is the target, every user is an attack surface. I am not upgrading to CRITICAL because the exploit still depends on user interaction and this CVE by itself most credibly delivers renderer compromise, not guaranteed whole-host takeover.

HIGH Active exploitation / KEV status
MEDIUM Practical blast radius from a single-bug chain
MEDIUM Public exploit maturity

Why this verdict

  • Active exploitation keeps the floor high: Google says an exploit exists in the wild and CISA KEV confirms this is not theoretical
  • User interaction subtracts real risk: attacker position is *unauthenticated remote*, but it still implies a delivery problem that modern email, web, DNS, and browser controls can disrupt
  • Single-bug impact is narrower than 'full RCE everywhere': arbitrary read/write in the browser process is serious, but many enterprise-worst outcomes still require a second vulnerability or a compatible post-browser path

Why not higher?

I am not calling this CRITICAL because the chain is not one-packet, wormable, or broadly automatable. The need for a victim browsing event and the likelihood that full host compromise needs another bug are meaningful friction points in real deployments.

Why not lower?

I am not dropping this to MEDIUM because this is Chrome, not a niche product, and Google explicitly says it is already being exploited. Once a browser zero-day is live, exposure is measured in users, not servers, and your reachable population is usually enormous.

05 · Compensating Control

What to do — in priority order.

  1. Force browser updates and restarts — Push managed Chrome updates and enforce restart/completion for lagging endpoints. Because this is KEV-listed / actively exploited, do this immediately, within hours, not on the normal HIGH 30-day rhythm.
  2. Restrict risky browsing paths — Temporarily tighten web filtering for uncategorized domains, ad-tech domains, newly registered domains, and direct file-sharing links commonly used in lure campaigns. This is a fast exposure reducer while patch uptake completes, and it should be in place immediately, within hours.
  3. Use browser isolation for high-risk groups — Route executives, finance, admins, and research users through remote browser isolation or equivalent hardened browsing controls where available. For a HIGH verdict this is a strong compensating control, but because exploitation is active, deploy for priority users immediately, within hours.
  4. Hunt for browser crash clusters — Query EDR, crash reporting, and proxy telemetry for renderer crashes, abnormal Chrome child-process behavior, or suspicious browsing immediately before help-desk complaints. Use this during the first 24-72 hours to find likely failed exploit attempts and patch laggards.
  5. Block unmanaged Chrome variants — If you govern only Google Chrome but allow unmanaged Chromium forks, close that gap with application control or MDM compliance rules. Do it within hours for internet-facing user populations because the patch speed of forks is uneven.
What doesn't work
  • A perimeter vuln scan will not save you here; this is client software, not an exposed server banner problem
  • EDR alone is not enough; a renderer-only exploit can stay quiet until a second stage appears
  • A WAF does nothing for users browsing out to malicious internet content
  • Email filtering alone is incomplete because the same exploit can arrive via compromised websites, ads, chat links, or search poisoning
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/remote execution tooling. Invoke it with python3 check_cve_2025_6554.py on Windows, macOS, or Linux; standard user rights are usually enough because it only reads local version information from common install paths and the Windows registry.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2025_6554.py
# Detect likely exposure to CVE-2025-6554 on local Chrome installs.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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


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


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


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


def get_windows_version():
    # Prefer registry App Paths / BLBeacon if present
    reg_paths = [
        ["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKCU\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
    ]
    for cmd in reg_paths:
        out = run_cmd(cmd)
        v = parse_ver(out)
        if v:
            return v, out

    common = [
        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"),
    ]
    for path in common:
        if os.path.exists(path):
            out = run_cmd([path, "--version"])
            v = parse_ver(out)
            if v:
                return v, out
    return None, ''


def get_macos_version():
    apps = [
        "/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 apps:
        if os.path.exists(path):
            out = run_cmd([path, "--version"])
            v = parse_ver(out)
            if v:
                return v, out
    return None, ''


def get_linux_version():
    bins = ["google-chrome", "google-chrome-stable", "chromium", "chromium-browser", "chrome"]
    for b in bins:
        p = shutil.which(b)
        if p:
            out = run_cmd([p, "--version"])
            v = parse_ver(out)
            if v:
                return v, out
    return None, ''


def main():
    system = platform.system()
    version = None
    raw = ''
    fixed = None

    if system == 'Windows':
        version, raw = get_windows_version()
        fixed = (138, 0, 7204, 96)
    elif system == 'Darwin':
        version, raw = get_macos_version()
        fixed = (138, 0, 7204, 92)
    elif system == 'Linux':
        version, raw = get_linux_version()
        fixed = (138, 0, 7204, 92)
    else:
        print('UNKNOWN - unsupported platform:', system)
        sys.exit(2)

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

    print(f'Detected version: {version[0]}.{version[1]}.{version[2]}.{version[3]}')
    print(f'Raw version output: {raw}')
    print(f'Fixed threshold for {system}: {fixed[0]}.{fixed[1]}.{fixed[2]}.{fixed[3]}+')

    if cmp_ver(version, fixed) < 0:
        print('VULNERABLE')
        sys.exit(1)
    else:
        print('PATCHED')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a fleet-wide browser emergency. Because the CVE is KEV-listed and actively exploited, the normal HIGH timing is overridden for mitigation: use patch / mitigate immediately, within hours as the noisgate mitigation SLA by forcing Chrome updates, enforcing restarts, tightening risky web paths, and isolating high-risk users right away; while HIGH would normally allow a noisgate remediation SLA of ≤180 days, this is one of the rare cases where waiting is indefensible, so finish broad patch deployment the same day and burn down stragglers within 72 hours with leadership-visible exceptions only.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 30, 2025)
  2. NVD - CVE-2025-6554
  3. CISA - Adds One Known Exploited Vulnerability to Catalog (July 2, 2025)
  4. OpenCVE record for CVE-2025-6554
  5. Debian Security Tracker - CVE-2025-6554
  6. Debian Security Advisory DSA-5955-1
  7. FIRST EPSS - Data and Statistics
  8. GitHub training repo referencing CVE-2025-6554
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.