MEDIUMCVSS6.5

Google Chrome < 132.0.6834.159 — RCE

A use-after-free in Chrome's DevTools component allows a crafted Chrome extension to corrupt heap memory and potentially execute code. Update Chrome to 132.0.6834.159/.160.

Published Jan 29, 2025 · Updated May 19, 2026

Why patchRisk explained in plain English

Worst-case scenarioIf unpatched

An attacker who can get a victim to install a malicious extension (or who can compromise a legitimate extension's update channel) can ship a payload that triggers the UAF the next time the user opens DevTools or when the extension itself opens a DevTools-connected target. The resulting heap-corruption primitive is constrained but already past Chrome's renderer sandbox in many cases, depending on the DevTools surface reached. Lower severity than the V8 bugs above because of the user-action prerequisite, but a real concern on developer / SRE workstations where DevTools is opened constantly.

How the attack works

CVE-2025-0762 is a use-after-free in Chrome's DevTools subsystem. A crafted Chrome extension can trigger DevTools to dereference memory it has already freed, corrupting the heap. Because DevTools historically runs with broader privileges than ordinary web content, a successful exploit yields heap-corruption inside an elevated Chrome process — a stronger primitive than the equivalent bug in a renderer would give.

Am I affected?Quick check

Probably yes if any of these apply:

●Developer workstations with Chrome and unmanaged extensions

●SRE / DBA hosts where Chrome DevTools is used against internal consoles

●Jump hosts where engineers attach DevTools

●Running Chrome < 132.0.6834.159

Affected OS versions

Windows Server 2016Windows Server 2019Windows Server 2022Windows Server 2025Windows 10Windows 11

Fixed in132.0.6834.159 (Windows) / 132.0.6834.160 (Mac)

Real-world incidentsWhat we've seen

Reported by "Sakana.S" on December 18, 2024 and patched in Chrome 132.0.6834.159/.160 on January 29, 2025. Microsoft Edge 132.0.2957.140 incorporated the same fix the day after. Distributions (Debian, Fedora, openSUSE, SUSE) all shipped tracking advisories the same week. No in-the-wild exploitation has been reported, but DevTools UAFs have shown up in malicious-extension supply-chain reports in prior years — worth tracking the install base of unmanaged extensions on developer fleets.

How to patch

Manual remediation steps

⏱ 10 minutes (browser relaunch only)

Check current Chrome version

(Get-ItemProperty 'HKLM:\SOFTWARE\Google\Chrome\BLBeacon' -ErrorAction SilentlyContinue).version

Update Chrome

$gu = "$env:ProgramFiles\Google\Update\GoogleUpdate.exe"
if (-not (Test-Path $gu)) { $gu = "${env:ProgramFiles(x86)}\Google\Update\GoogleUpdate.exe" }
if (Test-Path $gu) { & $gu /ua /installsource scheduler }

Audit installed extensions (defence-in-depth)

# Enumerate extensions installed under each Chrome profile on this host:
$root = "$env:LOCALAPPDATA\Google\Chrome\User Data"
if (Test-Path $root) {
  Get-ChildItem -Path $root -Filter "manifest.json" -Recurse -ErrorAction SilentlyContinue |
    Select-Object FullName, LastWriteTime
}

For managed estates, prefer the Chrome ExtensionInstallAllowlist / ExtensionInstallBlocklist policies — they are far stronger than per-host inventory.

Verify

(Get-ItemProperty 'HKLM:\SOFTWARE\Google\Chrome\BLBeacon').version
# Must show 132.0.6834.159 or later.

PowerShell automationComing soon

No tested PowerShell script for this entry yet. We’re prioritising automation based on user demand.

References

↗ CVE-2025-0762 ↗ NVD