Chrome 153 Ships 230 Security Fixes — Enterprise Detection, Verification, and Patching Guide

On September 8, 2026, the Chrome team promoted Chrome 153 to the stable channel for Windows, Mac, and Linux. On its face, this reads like a routine release note. It is not. Buried in the announcement is the line that should get every vulnerability management and SOC team's attention: this update includes 230 security fixes.

Two hundred thirty. That is one of the largest single-release patch volumes we have seen ship to the stable channel, and it lands on the most attacked piece of enterprise software on the planet. The browser is the primary initial-access surface for phishing-driven intrusion, malvertising, drive-by exploitation, and watering-hole campaigns. Every one of those 230 fixes represents a code path that, until this build, an attacker could potentially weaponize against an unpatched endpoint.

Compounding the urgency: Google is deliberately withholding bug details. Per the release note, "Access to bug details and links may be kept restricted until a majority of users are updated with a fix." That is standard Chrome practice — but it also means defenders are flying partially blind. We do not yet know which of the 230 fixes are critical, which are renderer sandbox escapes, and which may already be under active exploitation. Historically, when Google restricts bug details at scale, at least a subset of those bugs are the ones threat actors would most like to reverse-engineer from the patch diff.

The defensive posture here is straightforward: patch immediately, verify the patch actually landed, and hunt for evidence of compromise on endpoints that were running vulnerable builds. This post walks through all three.

Technical Analysis

Affected Products and Versions

Any Chrome build prior to 153.0.8010.36 should be treated as vulnerable to the full set of 230 fixed issues. Extended Stable channel users should confirm their channel has received the equivalent fix set. Chromium-based downstream browsers (Edge, Brave, Opera, Vivaldi) inherit these fixes on their own release cadence — do not assume your fleet is covered because users run a Chromium derivative.

What We Know — and What We Don't

Google has not disclosed individual CVE identifiers, CVSS scores, or component-level details in this announcement, and per policy we will not speculate on specific CVEs. What we can say from 15 years of watching these releases:

1. The attack surface distribution is predictable. Chrome security fixes historically cluster around the V8 JavaScript engine (type confusion, use-after-free), the Blink rendering engine, the GPU/process sandbox boundary, and WebAssembly. Large fix volumes almost always include memory-corruption bugs reachable from a malicious web page with zero user interaction beyond page load.

2. Patch-diffing is the adversary's playbook. Within 24–72 hours of a stable release, researchers and offensive actors diff the Chromium source against the prior build to identify fixed bug classes. N-day exploitation of freshly patched Chrome bugs is a mature, industrialized capability — particularly among commercial surveillance vendors and state-sponsored actors. The window between "patch released" and "working exploit" for high-value browser bugs is measured in days, not months.

3. Renderer compromise is the foot in the door. Even when a bug is "only" a renderer RCE, attackers chain it with sandbox escapes. From a defender's perspective, the observable artifact of renderer exploitation is almost always the same: the Chrome renderer or GPU process spawning an unexpected child process — a shell, a script interpreter, or a dropped payload.

Exploitation Status

As of publication, Google has not flagged any of the 230 fixes as actively exploited in the wild, and no entries from this release have appeared in the CISA Known Exploited Vulnerabilities catalog. That assessment can change quickly — Chrome zero-days are frequently disclosed as "fixed in this release, exploited in the wild" in follow-up advisories. Treat this update with KEV-level urgency until the fix-level details are public and triaged.

Detection & Response

Because individual bug details are restricted, signature- and CVE-specific detection is not yet possible. What is possible — and what we recommend deploying today — is behavioral detection for post-exploitation of the browser, plus rigorous patch verification. These detections are technique-based, not indicator-based, which means they hold value regardless of which of the 230 bugs an attacker used.

The single highest-fidelity behavioral signal for browser exploitation is a Chrome process spawning a child process that no legitimate web page should ever launch: command shells, script interpreters, LOLBins, or Office-style payload droppers.

---
title: Chrome Renderer Spawning Shell or Script Interpreter
description: Detects Chrome browser processes spawning command shells or script interpreters, a hallmark of renderer exploitation followed by sandbox escape or payload execution.
references:
  - https://attack.mitre.org/techniques/T1203/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/08
id: 3f8a1c92-7d4e-4b5a-9c61-2e8f4a0b7d33
status: experimental
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'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare enterprise browser extensions that shell out to system tools
  - Legitimate software updaters invoked from browser download handlers
level: high
---
title: Chrome Process Writing Executable to User-Writable Directory
description: Detects Chrome writing executable or script content to user-writable staging directories, consistent with drive-by download payload staging after browser exploitation.
references:
  - https://attack.mitre.org/techniques/T1203/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/09/08
id: 91b2e7d4-3c6f-4a18-b5d2-8f0c1e9a4b66
status: experimental
tags:
  - attack.execution
  - attack.t1203
  - attack.t1105
logsource:
  category: file_event
  product: windows
detection:
  selection_source:
    Image|endswith: '\chrome.exe'
  selection_path:
    TargetFilename|contains:
      - '\AppData\Local\Temp\'
      - '\AppData\Roaming\'
      - '\Users\Public\'
      - '\ProgramData\'
  selection_ext:
    TargetFilename|endswith:
      - '.exe'
      - '.dll'
      - '.scr'
      - '.js'
      - '.jse'
      - '.vbs'
      - '.hta'
      - '.ps1'
  filter_downloads:
    TargetFilename|contains: '\Downloads\'
  condition: selection_source and selection_path and selection_ext and not filter_downloads
falsepositives:
  - Chrome component and extension updates writing to AppData
  - Enterprise web applications with legitimate local file integration
level: medium
---
title: Chrome Process Establishing Outbound Connection from Non-Renderer Context
description: Detects network connections initiated by child processes of chrome.exe to external hosts, indicating potential C2 establishment following browser compromise.
references:
  - https://attack.mitre.org/techniques/T1071/
  - https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/09/08
id: c4d71a08-2f9b-4e63-8a1d-5b3c9e7f2084
status: experimental
tags:
  - attack.command_and_control
  - attack.t1071
  - attack.t1203
logsource:
  category: process_creation
  product: windows
detection:
  selection_grandparent:
    ParentImage|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  selection_network_tools:
    Image|endswith:
      - '\curl.exe'
      - '\wget.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\powershell.exe'
  selection_cli:
    CommandLine|contains:
      - 'http://'
      - 'https://'
      - 'Invoke-WebRequest'
      - 'DownloadString'
      - 'Start-BitsTransfer'
      - '-urlcache'
  condition: selection_grandparent and selection_network_tools and selection_cli
falsepositives:
  - Administrators performing legitimate downloads from shell sessions
  - Software deployment tooling
level: high

KQL — Microsoft Sentinel / Defender

The following hunt query identifies endpoints where Chrome spawned a suspicious child process, and correlates it with the installed Chrome version so you can prioritize endpoints that were running a pre-153 build at the time of the event. This is the exact triage pivot you want during the patch rollout window.

let SuspiciousChildren = dynamic(["cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","regsvr32.exe","wmic.exe","certutil.exe","bitsadmin.exe","curl.exe"]);
let ChromeChildEvents = DeviceProcessEvents
| where InitiatingProcessFileName =~ "chrome.exe"
| where FileName in~ (SuspiciousChildren)
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine, SHA256, ReportId;
let ChromeVersions = DeviceProcessEvents
| where FileName =~ "chrome.exe"
| summarize ChromeVersion = arg_max(TimeGenerated, FileVersion) by DeviceName;
ChromeChildEvents
| join kind=leftouter ChromeVersions on DeviceName
| extend VulnerableAtEventTime = iff(todecimal(parse_version(ChromeVersion)) < todecimal(parse_version("153.0.8010.36")), "YES - pre-153 build", "Patched build")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, ChromeVersion, VulnerableAtEventTime, SHA256
| order by TimeGenerated desc

A second query worth running during rollout: identify every endpoint in the fleet still running a vulnerable Chrome build, ranked by how exposed the device is (internet-facing browsing activity as a proxy for risk).

DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where FileName =~ "chrome.exe"
| where isnotempty(FileVersion)
| summarize LastSeen = max(TimeGenerated), ChromeVersion = arg_max(TimeGenerated, FileVersion) by DeviceName
| extend IsVulnerable = iff(todecimal(parse_version(ChromeVersion)) < todecimal(parse_version("153.0.8010.36")), true, false)
| where IsVulnerable == true
| project DeviceName, ChromeVersion, LastSeen
| order by LastSeen desc

Velociraptor VQL

For IR teams validating whether a specific endpoint shows post-exploitation artifacts, this VQL artifact enumerates running processes and flags anything with chrome.exe ancestry spawning shells, interpreters, or LOLBins — useful both for live triage and for scoping during the patch window.

-- Hunt for suspicious child processes spawned under chrome.exe
-- indicative of renderer exploitation / payload execution
LET suspicious_children <= ['cmd.exe', 'powershell.exe', 'pwsh.exe',
  'wscript.exe', 'cscript.exe', 'mshta.exe', 'rundll32.exe',
  'regsvr32.exe', 'wmic.exe', 'certutil.exe', 'bitsadmin.exe'];

SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name.lower() IN suspicious_children
  AND Ppid IN (
    SELECT Pid FROM pslist() WHERE Name.lower() = 'chrome.exe'
  )

Patch Verification and Enforcement Script

Detection is worthless if the patch never lands. The following PowerShell script audits the installed Chrome version on a Windows endpoint, flags it against the fixed build, and — where enterprise update mechanisms are in place — forces an update check. Deploy it via your RMM, Intune, or as a scheduled task across the fleet.

# Chrome 153 Patch Verification & Enforcement — Security Arsenal
# Flags endpoints running Chrome builds prior to 153.0.8010.36

$FixedVersion = [version]"153.0.8010.36"
$ChromePaths = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
    "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
)

$ChromeExe = $ChromePaths | Where-Object { Test-Path $_ } | Select-Object -First 1

if (-not $ChromeExe) {
    Write-Output "[INFO] Google Chrome not found on this endpoint."
    exit 0
}

$InstalledVersion = [version](Get-Item $ChromeExe).VersionInfo.ProductVersion
Write-Output "[INFO] Installed Chrome version: $InstalledVersion"

if ($InstalledVersion -lt $FixedVersion) {
    Write-Output "[ALERT] VULNERABLE: Chrome $InstalledVersion is below fixed build $FixedVersion"

    # Trigger Google Update immediately (enterprise deployments with Omaha)
    $UpdateExe = "$env:ProgramFiles(x86)\Google\Update\GoogleUpdate.exe"
    if (Test-Path $UpdateExe) {
        Write-Output "[ACTION] Forcing Google Update check..."
        Start-Process $UpdateExe -ArgumentList "/ua /installsource scheduler" -Wait
    }

    # Winget fallback for unmanaged endpoints
    if (Get-Command winget -ErrorAction SilentlyContinue) {
        Write-Output "[ACTION] Attempting update via winget..."
        winget upgrade --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements
    }

    exit 1
} else {
    Write-Output "[OK] Chrome $InstalledVersion meets or exceeds fixed build $FixedVersion"
    exit 0
}

For Linux fleets, the equivalent Bash audit:

#!/bin/bash
# Chrome 153 patch verification for Linux endpoints
FIXED="153.0.8010.36"

if command -v google-chrome >/dev/null 2>&1; then
    INSTALLED=$(google-chrome --version | grep -oP '[\d.]+')
    if [ "$(printf '%s\n' "$FIXED" "$INSTALLED" | sort -V | head -n1)" != "$FIXED" ]; then
        echo "[ALERT] VULNERABLE: Chrome $INSTALLED < $FIXED"
        # Debian/Ubuntu:
        # sudo apt-get update && sudo apt-get install --only-upgrade google-chrome-stable -y
        # RHEL/Fedora:
        # sudo dnf upgrade google-chrome-stable -y
        exit 1
    else
        echo "[OK] Chrome $INSTALLED is patched (>= $FIXED)"
        exit 0
    fi
else
    echo "[INFO] Chrome not installed"
    exit 0
fi

Remediation

1. Patch now — do not wait for the next maintenance window. Push Chrome 153.0.8010.36 (Linux) or 153.0.8010.36/.37 (Windows/Mac) fleet-wide. A release carrying 230 security fixes on the internet's dominant browser is not a candidate for deferred patching.
2. Kill running browser sessions after update. Chrome does not fully apply an update until the browser is restarted. An endpoint can show the new version on disk while users still run the vulnerable build in memory. Enforce a restart via policy (RelaunchNotification, RelaunchNotificationPeriod in Chrome Enterprise policy) or scripted process termination during off-hours.
3. Audit downstream Chromium browsers. Confirm Edge, Brave, Opera, and any embedded Chromium runtimes (Electron apps, WebView2) in your environment have ingested the equivalent fix set. WebView2 and Electron are frequently forgotten and remain vulnerable long after the main browser is patched.
4. Verify, don't assume. Use the version-audit queries and scripts above to produce a fleet compliance report. Target 100% coverage within 72 hours; escalate stragglers (offline devices, stubborn users, VDI gold images) explicitly.
5. Hunt retrospectively. Run the child-process and file-staging hunts across the window before your fleet was patched. If you find chrome.exe spawning shells on an endpoint that was running a pre-153 build, treat it as a potential intrusion and open an IR case — isolate, image, and scope.
6. Monitor for follow-on disclosure. Watch the Chrome Security Page, the Chromium bug tracker (as restrictions lift), and CISA KEV for any of these 230 fixes being elevated to known-exploited status. If that happens, your patch window justification is already done — and your hunt data tells you whether you were hit before the fix landed.
7. Harden the browser going forward. This release is a forcing function to revisit Chrome Enterprise controls: enforce automatic updates, block sideloaded extensions, enable Safe Browsing Enhanced Protection where privacy policy permits, and consider site isolation and renderer code integrity defaults. Patch velocity plus defense-in-depth is the only sustainable posture for browser risk.

Official advisory: Stable Channel Update for Desktop — Chrome Releases Blog

Related Resources

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