Chrome use-after-free in Site Isolation allows arbitrary code execution
Free public brief. The indicators, the detections with Splunk SPL already written (plus Elastic and KQL where they apply), and a Slack alert the next time this touches a vendor you run are in the app — free account, no card.
A use-after-free flaw in Chrome Site Isolation lets attackers execute code as the logged-on user; patch to 135.0.7049.84+ immediately.
Google Chrome contains a use-after-free vulnerability in its Site Isolation feature (CVE-2025-3066) that could allow arbitrary code execution in the context of the logged-on user. The vulnerability can be exploited via drive-by compromise—attackers need only trick a user into visiting a malicious website. Successful exploitation grants an attacker the privileges of the logged-on user, potentially allowing installation of programs, modification or deletion of data, or creation of accounts with full rights; the impact scales with user privilege level. As of publication, there are no confirmed reports of active exploitation in the wild, but the vulnerability affects Chrome versions prior to 135.0.7049.84 on Windows and Mac, and prior to 135.0.7049.84 on Linux. Google has released patched versions and defenders should apply updates immediately. Standard mitigations include enforcing least-privilege user accounts, enabling exploit-protection features (DEP, Windows Defender Exploit Guard, SIP), restricting browser extensions, and maintaining user security awareness training.
Mentioned in this report
Detection guidance
Chrome Browser Process Spawning Shell or Script LOLBin
Chrome spawning cmd, PowerShell, script hosts or common LOLBins can indicate a browser exploit (e.g. a Site Isolation use-after-free) reaching post-exploitation code execution after a drive-by. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: Chrome Browser Process Spawning Shell or Script LOLBin
id: 94fa1567-da03-50c7-b289-886adfa6e520
status: experimental
description: Detects chrome.exe spawning command shells, script hosts or common living-off-the-land
binaries. This is rare for normal browsing and can indicate a browser memory-corruption
exploit (e.g. a Site Isolation use-after-free) leading to code execution after a
drive-by visit. Generalises on the parent/child relation, not any specific exploit
artefact.
tags:
- attack.initial-access
- attack.t1189
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith: \chrome.exe
Image|endswith:
- \cmd.exe
- \powershell.exe
- \pwsh.exe
- \wscript.exe
- \cscript.exe
- \mshta.exe
- \rundll32.exe
- \regsvr32.exe
- \certutil.exe
- \bitsadmin.exe
- \msiexec.exe
condition: selection
falsepositives:
- Chrome extensions or native messaging hosts that launch helper scripts through cmd.exe
- Enterprise web apps registering custom URL protocol handlers that start scripts
via Chrome
level: high
author: Vorant
references:
- https://www.cisecurity.org/advisory/a-vulnerability-in-google-chrome-could-allow-for-arbitrary-code-execution_2025-038
Chrome Renderer or GPU Process Spawning Non-Chrome Child Process
A sandboxed Chrome renderer or GPU process spawning an unrelated child process suggests a sandbox escape or exploitation following a drive-by compromise. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: Chrome Renderer or GPU Process Spawning Non-Chrome Child Process
id: 465b2845-2dfc-5d47-8a6f-0f007615b747
status: experimental
description: Detects child processes launched by a Chrome renderer or GPU process
(identified by the --type= argument in the parent command line) that are not Chrome
itself or its crash handlers. Sandboxed Chrome processes should not start arbitrary
programs, so this indicates exploitation such as a use-after-free chained with a
sandbox escape.
tags:
- attack.initial-access
- attack.t1189
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith: \chrome.exe
ParentCommandLine|contains:
- --type=renderer
- --type=gpu-process
filter_chrome:
Image|endswith:
- \chrome.exe
- \WerFault.exe
- \crashpad_handler.exe
condition: selection and not filter_chrome
falsepositives:
- Security or DLP products that inject helper processes into the renderer
- Chrome crash-reporting components not covered by the filter
level: high
author: Vorant
references:
- https://www.cisecurity.org/advisory/a-vulnerability-in-google-chrome-could-allow-for-arbitrary-code-execution_2025-038
Behavioural rules are generated from public reporting — validate in your environment before deploying.
Source reporting: https://www.cisecurity.org/advisory/a-vulnerability-in-google-chrome-could-allow-for-arbitrary-code-execution_2025-038
What this brief leaves out
This page is the free tier: the write-up, the severity, the names. In the app the same report carries its extracted indicators, its detections (Splunk SPL already written, plus Elastic and Microsoft KQL where they apply), the actors and CVEs it names as live profiles, and the vendor research on the same campaign — the primary source the news paraphrased, cited and read directly.
It sits in a corpus of 13,854 reports from 146 sources, 616 of them written in the last seven days, and it grows through the day.
A new account starts with three days of all of it, no card, then keeps the government and CERT reporting free. Name the vendors you run and Slack hears about the reports that touch them — about forty a week that are yours, not the four hundred that are not.
Create a free account What it costs