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

Use after free in Compositing in Google Chrome prior to 137

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

This is a booby-trapped webpage trying to make Chrome grab a freed steering wheel mid-turn

CVE-2025-5063 is a use-after-free bug in Chrome's Compositing pipeline. Google says Chrome versions prior to 137.0.7151.55 are affected, with desktop fixes shipping as 137.0.7151.55 on Linux and 137.0.7151.55/.56 on Windows and Mac; Google's Android note says the corresponding Android release carries the same security fixes. The bug is reachable through a crafted HTML page, so the attacker path is classic browser exploitation: get a user to render hostile content, trigger a dangling-pointer condition, and turn that memory corruption into controlled execution inside the browser.

The vendor's HIGH label is directionally right, but the raw 8.8 overstates enterprise urgency a bit when you do a friction audit. This is not an unauthenticated server-side RCE and not a worm; it needs user interaction, lands first in a sandboxed renderer/compositing path, and there is no KEV listing or Google statement of in-the-wild exploitation in the advisory reviewed here. Still, Chrome is ubiquitous, web content is attacker-delivered by default, and a reliable renderer exploit can be operationally valuable even before a sandbox escape is paired with it.

"Internet-delivered and everywhere, but still gated by user interaction and Chrome's sandbox"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land hostile web content

The attacker serves a crafted HTML/JavaScript page to a target browser, using phishing, malvertising, SEO poisoning, or a compromised legitimate site. The advisory itself explicitly says exploitation is via a crafted HTML page, so there is no authentication or local foothold requirement before content delivery.
Conditions required:
  • Target runs Chrome/Chromium-based build still below the fixed version
  • User visits attacker-controlled or attacker-influenced content
  • Browser protections are not already forcing that activity into isolated remote browsing
Where this breaks in practice:
  • Requires UI:R: a user must browse to or render the page
  • Email security, web filtering, Safe Browsing, and ad-blocking reduce commodity delivery success
  • This is endpoint population-wide, but still not externally reachable in the server sense
Detection/coverage: Vulnerability scanners can usually detect version exposure well; they cannot validate exploitability from the network. Web proxy, Secure Web Gateway, and Safe Browsing telemetry are better at spotting delivery than infrastructure scanners.
STEP 02

Trigger the compositor UAF

Once rendered, the page drives Chrome's Compositing code into a use-after-free condition and attempts heap grooming to make freed memory reusable in a controlled way. In practice this is a reliability problem, not just a bug-class label: many crashes stay crashes unless the attacker can shape allocator state precisely.
Conditions required:
  • The target path in Compositing is reachable on the target platform/build
  • Exploit code can reliably influence heap layout and object lifetime
  • Crash defenses and allocator behavior do not collapse the attempt first
Where this breaks in practice:
  • Bug details were still restricted in Google's tracker during review, so public weaponization detail is limited
  • Memory-corruption exploitation reliability often varies by OS, channel, and hardware/GPU stack
  • A single malformed page causing a tab crash is much easier than dependable code execution
Detection/coverage: EDR/browser telemetry may only show chrome.exe or renderer crashes unless exploit prevention fires. Crash spikes, tab crashes, and browser sandbox violations are useful weak signals, but signature-grade detection is usually poor before a public PoC appears.
STEP 03

Convert corruption into renderer-level code execution

If heap control is good enough, the attacker can turn the dangling-pointer bug into execution in the renderer/compositor context. Chromium's own architecture docs matter here: renderer logic is isolated into dedicated processes with heavy restrictions, so the first win is typically inside a sandboxed process, not full host compromise.
Conditions required:
  • Exploit chain achieves instruction/data control rather than a plain crash
  • Browser exploit mitigations do not stop payload staging
  • The compromised renderer has access to data or tokens worth stealing
Where this breaks in practice:
  • Chrome's multi-process architecture and renderer sandbox sharply reduce immediate blast radius
  • Site/process isolation limits some cross-origin abuse paths
  • Enterprise EDR and browser hardening may catch follow-on activity even if the initial renderer exploit works
Detection/coverage: Look for child-process anomalies, exploit-prevention events, browser crashes followed by unusual process spawns, or renderer sandbox diagnostics. Traditional network vulnerability scanners will miss this stage entirely.
STEP 04

Escape or monetize the foothold

To move from renderer compromise to host compromise, the attacker usually needs a second bug such as a sandbox escape, GPU/process boundary issue, or another privilege transition. Without that second step, impact is often limited to browser-session abuse, data theft available to the compromised renderer, or a crash/denial outcome.
Conditions required:
  • A workable post-renderer objective exists
  • Another vulnerability or misconfiguration weakens sandbox boundaries
  • The user/session holds valuable browser-accessible data
Where this breaks in practice:
  • This CVE by itself does not document a sandbox escape
  • Modern Chrome sandboxes deliberately restrict filesystem and OS access from renderers
  • Post-exploitation value varies a lot by user profile and session state
Detection/coverage: EDR, browser exploit prevention, child-process controls, and sandbox policy telemetry are the practical stops here. If only the renderer is compromised and dies, defenders may see nothing beyond unstable tabs and crash artifacts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation in reviewed primary sources. Google did not add an 'exploit exists in the wild' statement to the May 27, 2025 Chrome advisory, and the CVE is not listed in CISA KEV.
Public PoC availabilityNo authoritative public PoC located in the reviewed sources. Google's issue tracker entry was still restricted, which usually delays copycat exploit development but does not eliminate private weaponization risk.
EPSS0.00457 from the user-provided intel, which is low. Treat that as downward pressure only; EPSS measures exploitation likelihood, not business impact.
KEV statusNot KEV-listed in CISA's catalog as reviewed.
CVSS vector reality checkAV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H is a fair *technical* baseline for a browser memory-corruption flaw, but the decisive real-world brake is UI:R plus renderer sandboxing.
Affected versionsGoogle/NVD describe affected builds as Google Chrome prior to 137.0.7151.55.
Fixed versionsUpstream desktop fix shipped as 137.0.7151.55 (Linux) and 137.0.7151.55/.56 (Windows and Mac). Debian tracks a fix at 137.0.7151.55-3~deb12u1 for bookworm; Ubuntu notes the Chromium packaging path is largely via snap on newer releases.
Scanning and exposure dataInternet scan data is not meaningful here. Shodan/Censys/FOFA-style exposure counting applies poorly because Chrome is client software, not an internet-facing service. That is an inference from the product type, not a direct scan result.
Disclosure and reporterGoogle's advisory says the bug was reported by Anonymous on 2025-04-18 and publicly disclosed on 2025-05-27.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.3/10)

The single biggest severity brake is that exploitation starts with user-driven web content and lands in Chrome's sandboxed renderer/compositing path, not directly on the host. It stays in HIGH because Chrome is massively deployed and hostile web content is a default exposure channel across almost every enterprise endpoint.

HIGH Affected version range and fixed versions
MEDIUM Real-world exploitability without a public PoC or in-the-wild confirmation
HIGH Downward impact of user interaction and sandbox prerequisites

Why this verdict

  • Downgrade from 8.8 because it is client-side, not server-side — the attacker cannot hit a listening service; they must first win a browsing event.
  • User interaction compounds the frictionUI:R means phishing, malvertising, or content placement has to work before the bug matters.
  • Renderer sandboxing is the decisive brake — Chromium's architecture explicitly restricts renderer access to the OS, so this CVE alone is not the same as straight host-level RCE.
  • No KEV and no Google in-the-wild statement — there is no authoritative exploitation amplifier in the sources reviewed.
  • Still kept in HIGH because Chrome is everywhere — unlike a niche client bug, this has a very large reachable population across enterprise endpoints.

Why not higher?

There is no evidence here of active exploitation, no KEV listing, and no documented sandbox escape bundled with this CVE. A browser memory corruption bug that needs a user to render hostile content and first lands in a locked-down renderer should not be scored like an unauthenticated perimeter RCE.

Why not lower?

Chrome is one of the highest-exposure applications in the enterprise, and the delivery mechanism is ordinary web content rather than a rare local condition. If exploitation reliability exists, the attacker can reach a huge endpoint population with no credentials and no prior foothold.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update — Use enterprise policy to ensure Chrome/Chromium channels actually pull the fixed build and do not sit indefinitely pending relaunch. For a HIGH verdict, deploy this control within 30 days if patch completion is lagging.
  2. Force relaunch of stale browsers — Chrome fixes are useless until the vulnerable process exits. Use managed restart prompts, maintenance windows, or VDI image refresh to evict long-lived renderer processes; do this within 30 days for systems that are not naturally cycling.
  3. Isolate risky browsing — Put high-risk populations such as finance, executives, researchers, and helpdesk into remote browser isolation or hardened VDI browsing paths where feasible. This cuts exploit delivery success while you finish remediation, and for HIGH severity should be stood up within 30 days where gaps exist.
  4. Harden web delivery controls — Tighten Secure Web Gateway, ad/tracker blocking, attachment detonation, and URL filtering around newly registered domains, malvertising-heavy categories, and untrusted file-sharing destinations. This does not fix the bug, but it reduces the probability that UI:R ever becomes execution; implement within 30 days.
  5. Audit sandbox exceptions — Find endpoints running Chrome with unsafe flags, debugging options, disabled sandboxes, unusual extension sets, or legacy compatibility tooling that weakens browser process boundaries. Correct those deviations within 30 days because they directly erode the main friction that kept this CVE below critical.
What doesn't work
  • Network perimeter scanning doesn't help much because this is client software exposure, not an internet-facing service.
  • MFA is mostly irrelevant to the exploitation step; it may reduce downstream account abuse, but it does not stop the browser bug from triggering.
  • Crash-only monitoring is insufficient because a mature exploit aims to avoid obvious repeated crashes, and many benign crashes will look similar anyway.
  • Telling users to be careful is weak control coverage for a web-delivered browser bug; commodity delivery can come through legitimate but compromised sites.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or golden image, not from a remote scanner. Invoke it as python3 chrome_cve_2025_5063_check.py on macOS/Linux or py chrome_cve_2025_5063_check.py on Windows; standard user rights are usually enough, though Windows registry and machine-wide install discovery work best when local policy does not restrict reads.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2025-5063 Chrome/Chromium version check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1=vulnerable, 0=patched, 2=unknown

import os
import platform
import re
import subprocess
import sys
from pathlib import Path

FIXED = (137, 0, 7151, 55)


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 version_str(v):
    return '.'.join(str(x) for x in v)


def compare_version(v1, v2):
    return (v1 > v2) - (v1 < v2)


def try_run(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=8)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return p.returncode, out.strip()
    except Exception:
        return None, ''


def detect_linux():
    results = []
    candidates = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium', '--version'],
        ['chromium-browser', '--version'],
        ['/opt/google/chrome/chrome', '--version'],
        ['/usr/bin/google-chrome', '--version'],
        ['/usr/bin/chromium', '--version'],
        ['/usr/bin/chromium-browser', '--version'],
    ]
    seen = set()
    for cmd in candidates:
        key = tuple(cmd)
        if key in seen:
            continue
        seen.add(key)
        rc, out = try_run(cmd)
        if rc is None:
            continue
        v = parse_version(out)
        if v:
            results.append((' '.join(cmd[:-1]), v, out))
    return results


def detect_macos():
    results = []
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
        str(Path.home() / 'Applications/Chromium.app/Contents/MacOS/Chromium'),
    ]
    for app in candidates:
        if not os.path.exists(app):
            continue
        rc, out = try_run([app, '--version'])
        if rc is None:
            continue
        v = parse_version(out)
        if v:
            results.append((app, v, out))
    return results


def detect_windows():
    results = []
    candidates = [
        os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Chromium', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LocalAppData', ''), 'Chromium', 'Application', 'chrome.exe'),
    ]

    for exe in candidates:
        if exe and os.path.exists(exe):
            rc, out = try_run([exe, '--version'])
            v = parse_version(out)
            if v:
                results.append((exe, v, out))

    try:
        import winreg
        keys = [
            (winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon', 'version'),
            (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Google\Chrome\BLBeacon', 'version'),
            (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon', 'version'),
            (winreg.HKEY_CURRENT_USER, r'Software\Chromium\BLBeacon', 'version'),
            (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Chromium\BLBeacon', 'version'),
        ]
        for hive, path, name in keys:
            try:
                with winreg.OpenKey(hive, path) as k:
                    val, _ = winreg.QueryValueEx(k, name)
                    v = parse_version(str(val))
                    if v:
                        results.append((f'registry:{path}', v, str(val)))
            except Exception:
                pass
    except Exception:
        pass

    # de-duplicate by source/version pair
    deduped = []
    seen = set()
    for src, v, raw in results:
        key = (src, v)
        if key not in seen:
            seen.add(key)
            deduped.append((src, v, raw))
    return deduped


def main():
    system = platform.system().lower()
    if 'windows' in system:
        found = detect_windows()
    elif 'darwin' in system or 'mac' in system:
        found = detect_macos()
    else:
        found = detect_linux()

    if not found:
        print('UNKNOWN: No Chrome/Chromium installation detected or version could not be read')
        sys.exit(2)

    vulnerable = []
    patched = []
    for src, v, raw in found:
        if compare_version(v, FIXED) < 0:
            vulnerable.append((src, v, raw))
        else:
            patched.append((src, v, raw))

    if vulnerable:
        details = '; '.join(f'{src}={version_str(v)}' for src, v, _ in vulnerable)
        print(f'VULNERABLE: Found version(s) below {version_str(FIXED)} -> {details}')
        sys.exit(1)

    details = '; '.join(f'{src}={version_str(v)}' for src, v, _ in patched)
    print(f'PATCHED: All detected version(s) are >= {version_str(FIXED)} -> {details}')
    sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a HIGH client-side browser bug: query your fleet for Chrome/Chromium versions below 137.0.7151.55, prioritize high-risk user groups and unmanaged relaunch laggards first, and verify that auto-update plus relaunch enforcement are actually moving versions. Per the noisgate mitigation SLA, deploy compensating controls such as forced browser relaunch, risky-user browser isolation, and tightened web delivery controls within 30 days if patching is incomplete; per the noisgate remediation SLA, complete rollout of the vendor-fixed browser version across the managed fleet within 180 days.

Sources

  1. Google Chrome Stable Channel Update for Desktop - May 27, 2025
  2. Google Chrome Early Stable Update for Desktop - May 21, 2025
  3. NVD CVE-2025-5063
  4. MITRE CVE Record
  5. Debian Security Tracker CVE-2025-5063
  6. Ubuntu CVE Page
  7. CISA Known Exploited Vulnerabilities Catalog
  8. Chromium Multi-process Architecture
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.