Use-after-free in Chrome Lens 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 vulnerability in Google Chrome's Lens component allows arbitrary code execution; no active exploitation reported.
Google Chrome versions prior to 134.0.6998.117/.118 (Windows/Mac) and 134.0.6998.117 (Linux) contain a use-after-free vulnerability in the Lens component that can be exploited for arbitrary code execution. The flaw can be triggered via drive-by compromise when a user visits a malicious website. Successful exploitation executes code in the context of the logged-on user; impact depends on user privileges—administrative accounts face full system compromise including program installation, data modification, and account creation. Non-administrative users experience reduced impact. The advisory notes no current wild exploitation. Defenders should prioritize immediate patching after testing, enforce least-privilege principles, restrict administrator privileges to dedicated accounts, and enable exploit-protection features such as DEP, WDEG, or SIP.
Mentioned in this report
Detection guidance
Chrome Browser Spawning Command Shell or Scripting/LOLBin Child Process
Detects chrome.exe spawning a shell, scripting host or common download/proxy-execution LOLBin, a post-exploitation sign of a browser memory-corruption exploit (e.g. a Lens use-after-free) delivered via 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 Spawning Command Shell or Scripting/LOLBin Child Process
id: 5793cddd-965e-5b93-b086-e379852ab7e3
status: experimental
description: Detects chrome.exe spawning a shell, scripting host or common proxy-execution
LOLBin. After successful exploitation of a Chrome memory-corruption flaw (for example
a Lens use-after-free reached through a drive-by visit), attacker code often launches
such child processes in the context of the logged-on user. Generalises on the parent/child
relation, not on any specific exploit artefact.
references:
- https://www.cisecurity.org/advisory/a-vulnerability-in-google-chrome-could-allow-for-arbitrary-code-execution_2025-030
tags:
- attack.initial-access
- attack.t1189
- attack.execution
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
- \wmic.exe
condition: selection
falsepositives:
- Browser extensions or native messaging hosts that deliberately launch cmd.exe or
PowerShell
- Developers or helpdesk staff launching scripts from Chrome-based web tooling or
custom URL protocol handlers
level: high
author: Vorant
Chrome Browser Spawning Executable From User-Writable Directory
Detects chrome.exe launching a non-Chrome child process from Temp, Downloads, Public or AppData paths, consistent with a browser exploit dropping and running a payload. 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 Spawning Executable From User-Writable Directory
id: ac6ec4d4-10a7-5ca0-8b30-087da84a2548
status: experimental
description: Detects chrome.exe as the parent of a process whose image sits in a user-writable
location such as Temp, Downloads, Users\Public or AppData. A compromised browser
process dropping and executing a second-stage payload after a drive-by exploit produces
this pattern. Chrome's own helper processes and updater/installer locations are
filtered out.
references:
- https://www.cisecurity.org/advisory/a-vulnerability-in-google-chrome-could-allow-for-arbitrary-code-execution_2025-030
tags:
- attack.initial-access
- attack.t1189
- attack.execution
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith: \chrome.exe
Image|contains:
- \AppData\Local\Temp\
- \Users\Public\
- \Downloads\
- \AppData\Roaming\
filter_chrome:
Image|endswith: \chrome.exe
filter_google_installer:
Image|contains:
- \Google\Chrome\Application\
- \Google\Update\
- \Google\Temp\
condition: selection and not 1 of filter_*
falsepositives:
- Chrome launching a freshly downloaded installer directly from the download shelf
- Per-user Chrome updater or Chrome-hosted app launchers running from AppData
level: medium
author: Vorant
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-030
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