Google Chrome Zero-Day Under Active Exploitation: Seventh in-the-Wild Bug of the Year — Detection and Remediation Guide

Introduction

Google shipped an emergency Chrome update on Tuesday addressing 230 vulnerabilities, and buried in that release is the detail that should be driving your patch queue right now: one of them is a zero-day already being exploited in the wild. This marks the seventh Chrome zero-day patched since the start of the year — a pace that confirms what those of us running IR engagements have seen firsthand: browser exploitation is no longer a nation-state novelty. It is a routine, industrialized initial access vector.

If your organization has users browsing the web with Chrome — and statistically, most of them are — you are exposed until the update lands on every endpoint. Drive-by exploitation of a renderer or browser-engine bug requires nothing more than a user visiting a malicious or compromised page. No macro prompts, no attachment warnings, no user error beyond opening a link. That is why these bugs command premium prices in exploit markets and why Google continues to tag them as exploited in the wild rather than disclosing full technical details.

This post gives you the defender's playbook: what we know, how to hunt for exploitation artifacts, and how to verify and enforce remediation across your fleet.

Technical Analysis

What Was Patched

• Product: Google Chrome (Stable channel), all desktop platforms — Windows, macOS, and Linux
• Scope: 230 security fixes in a single release, including one vulnerability confirmed by Google as actively exploited in attacks prior to the patch
• Exploitation status: Confirmed in-the-wild exploitation. Google's standard practice — which it followed here — is to restrict bug detail links until the majority of users are updated, meaning the technical root cause details remain limited publicly. This is deliberate: it slows reverse-engineering of the patch into working exploits.
• Related components: Chrome security updates of this cadence typically cover the V8 JavaScript engine, the Blink rendering engine, and sandbox-adjacent components — the precise attack surface most valuable to exploit developers. Defenders should treat the specific component as unconfirmed until Google lifts the restriction, but should assume renderer-level code execution with potential sandbox-escape chaining, as that is the pattern across this year's prior Chrome zero-days.

Why Seven Zero-Days in One Year Matters

Seven exploited-in-the-wild Chrome bugs before the year is even old tells you three things as a defender:

1. Patch velocity is now a detection-and-response problem, not a hygiene problem. Attackers are weaponizing Chrome bugs faster than most enterprise change-management cycles run. If your browser patch SLA is 14 or 30 days, you are carrying known-exploited risk for weeks at a time.
2. Patch-gap exploitation is guaranteed. Every Chrome zero-day disclosure is followed within days by reverse-engineered exploits derived from diffing the patch. The window between "Google ships the fix" and "your endpoints run the fixed build" is the danger zone.
3. Browser exploitation chains target the full stack. Modern Chrome exploits rarely stop at the renderer. Chaining a renderer RCE with a sandbox escape yields full endpoint code execution under the user's context — which is exactly where post-exploitation tooling (C2 beacons, credential theft, lateral movement staging) begins.

Attack Chain (Defender's View)

While technical specifics of this bug are restricted, the observable anatomy of Chrome zero-day exploitation is consistent and huntable:

1. User visits a malicious or compromised site (watering hole, malvertising, spearphish link)
2. Malicious JavaScript triggers the vulnerability in the renderer process
3. Exploit executes shellcode, then attempts sandbox escape or directly drops/launches a payload
4. Post-exploitation: a child process spawns from Chrome — typically cmd.exe, powershell.exe, wscript.exe, rundll32.exe, or a dropped executable in a user-writable directory (%TEMP%, %AppData%, %LocalAppData%)

Step 4 is your highest-fidelity detection surface. A legitimately functioning Chrome process almost never spawns command interpreters or script engines. That parent-child relationship is the single most reliable behavioral indicator of browser exploitation in any EDR stack.

Detection & Response

SIGMA Rules

---
title: Chrome Browser Spawning Command Interpreter or Script Engine
id: 8f2c4a91-3d7e-4b1a-9c5f-2e6d8a0b1c3d
status: experimental
description: Detects chrome.exe spawning command interpreters, script engines, or LOLBins — a high-fidelity indicator of browser exploitation or malicious extension behavior. Relevant to actively exploited Chrome zero-days where renderer compromise leads to payload execution.
references:
  - https://www.bleepingcomputer.com/news/security/google-patches-seventh-chrome-zero-day-exploited-in-attacks-this-year/
  - https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/02/18
tags:
  - attack.execution
  - attack.t1203
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\chrome.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\wmic.exe'
      - '\bitsadmin.exe'
      - '\certutil.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare enterprise browser extensions with legitimate helper processes
  - Internal web applications using legacy IE-mode integrations
level: high
---
title: Executable Launched From Chrome Browser Cache or Temp Directory
id: 3b9d1e57-6a2f-4c8b-b741-9d0e2f5a7c8e
status: experimental
description: Detects execution of binaries from Chrome cache, temp, or download staging locations consistent with payload drops following browser exploitation.
references:
  - https://www.bleepingcomputer.com/news/security/google-patches-seventh-chrome-zero-day-exploited-in-attacks-this-year/
  - https://attack.mitre.org/techniques/T1204.002/
author: Security Arsenal
date: 2026/02/18
tags:
  - attack.execution
  - attack.t1204.002
  - attack.t1105
logsource:
  category: process_creation
  product: windows
detection:
  selection_paths:
    Image|contains:
      - '\AppData\Local\Google\Chrome\User Data\Default\Cache\'
      - '\AppData\Local\Temp\'
  selection_ext:
    Image|endswith:
      - '.exe'
      - '.dll'
      - '.scr'
      - '.com'
  filter_updater:
    Image|contains:
      - 'GoogleUpdate'
      - 'chrome_installer'
      - 'setup.exe'
  condition: selection_paths and selection_ext and not filter_updater
falsepositives:
  - Legitimate Chrome updater and installer activity (partially filtered)
  - User-launched downloads executed from temp-extracted archives
level: medium

KQL — Microsoft Sentinel / Defender

// Hunt: Chrome spawning suspicious child processes (last 14 days)
// High-fidelity indicator of browser exploitation / zero-day payload execution
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "chrome.exe"
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","regsvr32.exe","wmic.exe","bitsadmin.exe","certutil.exe")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessCommandLine, SHA256, ReportId
| sort by TimeGenerated desc
;
// Correlate: identify endpoints running outdated Chrome versions exposed to the zero-day
DeviceTvmSoftwareInventory
| where SoftwareName has "chrome"
| summarize arg_max(TimeGenerated, *) by DeviceId
| project DeviceName, SoftwareVersion, VulnerabilityCount
| sort by SoftwareVersion asc

Velociraptor VQL

-- Hunt for suspicious child processes of Chrome across the fleet
-- and enumerate installed Chrome version for patch verification
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       (SELECT Name, Exe FROM pslist(pid=Ppid)) AS Parent
FROM pslist()
WHERE Parent[0].Name =~ 'chrome\.exe'
  AND Name =~ '(?i)(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|wmic|bitsadmin|certutil)\.exe'

Remediation & Verification Script

# Chrome Zero-Day Remediation & Verification Script
# Run via RMM/Intune/SCCM across the fleet. Requires elevation for install path queries.

$minVersion = [version]"0.0.0.0"   # <-- SET THIS to the fixed build from the Chrome Stable release notes
$results = @()

# 1. Detect installed Chrome version (64-bit and 32-bit registry hives)
$chromePaths = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome',
    'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome'
)
foreach ($path in $chromePaths) {
    if (Test-Path $path) {
        $ver = (Get-ItemProperty $path).DisplayVersion
        if ($ver) { $results += [pscustomobject]@{ Source = $path; Version = [version]$ver } }
    }
}

# Fallback: query the binary directly
if (-not $results -and (Test-Path "$env:ProgramFiles\Google\Chrome\Application\chrome.exe")) {
    $ver = (Get-Item "$env:ProgramFiles\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion
    $results += [pscustomobject]@{ Source = 'chrome.exe'; Version = [version]$ver }
}

# 2. Evaluate compliance
foreach ($r in $results) {
    if ($r.Version -ge $minVersion) {
        Write-Output "COMPLIANT: Chrome $($r.Version) >= $minVersion ($($r.Source))"
    } else {
        Write-Output "NON-COMPLIANT: Chrome $($r.Version) < $minVersion — triggering update"
        # 3. Force Google Update check (requires Chrome enterprise policies permitting updates)
        Start-Process "$env:ProgramFiles (x86)\Google\Update\GoogleUpdate.exe" -ArgumentList '/ua /installsource scheduler' -ErrorAction SilentlyContinue
        # Kill running Chrome so the pending update can apply on next launch
        Get-Process chrome -ErrorAction SilentlyContinue | Stop-Process -Force
    }
}

# 4. Verify Google Update is not disabled via policy
$updatePolicy = 'HKLM:\SOFTWARE\Policies\Google\Update'
if (Test-Path $updatePolicy) {
    $val = (Get-ItemProperty $updatePolicy -Name 'UpdateDefault' -ErrorAction SilentlyContinue).UpdateDefault
    if ($val -eq 0) { Write-Warning 'POLICY BLOCKS CHROME UPDATES: UpdateDefault=0 — remediate GPO immediately' }
}

Remediation

1. Update Chrome immediately. Open chrome://settings/help on any endpoint to force an update check, or push the latest Stable build via your software distribution platform (Intune, SCCM, Jamf, your RMM). Set the minimum compliant version in the script above to the exact fixed build listed in the Chrome Releases blog for this release — verify it there rather than trusting secondary sources.
2. Restart the browser — the update does not apply until relaunch. This is the most commonly missed step in enterprise Chrome patching. Chrome downloads the update in the background but continues running the vulnerable build until the process restarts. Enforce relaunch via policy or scheduled process termination.
3. Do not forget Chromium derivatives. Microsoft Edge, Brave, Opera, and Vivaldi inherit Chromium engine bugs and ship fixes on their own schedules. Track and patch Edge separately — it is frequently the actual deployed browser in Windows enterprises.
4. Verify update policies. Confirm that GPO/MDM policies do not disable Google Update (UpdateDefault = 0), and consider enabling Chrome's force relaunch notification policy to close the patch-restart gap.
5. Hunt retroactively. Run the KQL and VQL queries above across at least the last 14–30 days of telemetry. If you find Chrome spawning script interpreters on any endpoint, isolate that host and begin IR scoping — that behavior warrants a full compromise assessment, not just a patch.
6. Reduce browser attack surface going forward. Enforce site isolation (on by default), deploy browser-level web filtering to block known-malicious domains, and consider application control policies that prevent browser processes from launching child executables outright.
7. Reference the official advisory: Google Chrome Releases and the BleepingComputer report for the full fixed-version list and disclosure updates. If this CVE lands in the CISA Known Exploited Vulnerabilities catalog — as virtually every exploited Chrome zero-day does — federal deadlines (typically 3 weeks under BOD 22-01) give you a defensible internal SLA to cite when pushing emergency browser patches through change control.

The Bottom Line

Seven actively exploited Chrome zero-days in a single year is not an anomaly — it is the operating tempo. Browser patch SLAs measured in weeks are now measured risk. Treat every Chrome stable update tagged with an exploited vulnerability as an emergency change, verify the browser actually restarted, and hunt the parent-child process telemetry that tells you whether someone got there before the patch did.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub