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.
4 steps from start to impact.
Land hostile web content
- 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
- 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
Trigger the compositor UAF
- 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
- 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
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.Convert corruption into renderer-level code execution
- 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
- 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
Escape or monetize the foothold
- A workable post-renderer objective exists
- Another vulnerability or misconfiguration weakens sandbox boundaries
- The user/session holds valuable browser-accessible data
- 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
The supporting signals.
| In-the-wild status | No 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 availability | No 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. |
| EPSS | 0.00457 from the user-provided intel, which is low. Treat that as downward pressure only; EPSS measures exploitation likelihood, not business impact. |
| KEV status | Not KEV-listed in CISA's catalog as reviewed. |
| CVSS vector reality check | AV: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 versions | Google/NVD describe affected builds as Google Chrome prior to 137.0.7151.55. |
| Fixed versions | Upstream 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 data | Internet 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 reporter | Google's advisory says the bug was reported by Anonymous on 2025-04-18 and publicly disclosed on 2025-05-27. |
noisgate verdict.
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.
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 friction —
UI:Rmeans 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.
What to do — in priority order.
- 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.
- 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.
- 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.
- 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:Rever becomes execution; implement within 30 days. - 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.
Network perimeter scanningdoesn't help much because this is client software exposure, not an internet-facing service.MFAis mostly irrelevant to the exploitation step; it may reduce downstream account abuse, but it does not stop the browser bug from triggering.Crash-only monitoringis insufficient because a mature exploit aims to avoid obvious repeated crashes, and many benign crashes will look similar anyway.Telling users to be carefulis weak control coverage for a web-delivered browser bug; commodity delivery can come through legitimate but compromised sites.
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.
#!/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()
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.