Google shipped a Stable channel update for Chrome desktop this week — version 155.0.8059.39/.40 for Windows and macOS and 155.0.8059.39 for Linux — and the security payload is unusually heavy: 247 security fixes in a single build, including two vulnerabilities rated Critical.
The two headline bugs are:
- CVE-2026-106382 — Critical use-after-free in Chromecast (reported internally by Google)
- CVE-2026-106197 — Critical use-after-free in Browser (reported by external researcher Xinyang Ge)
Critical-rated use-after-free flaws in Chrome's core browser component are the class of vulnerability that routinely ends up weaponized in drive-by exploit chains — often paired with a sandbox escape to achieve full remote code execution from a malicious webpage. Google is withholding bug details until a majority of users are updated, which is standard practice, but it also means defenders have no public technical detail to work from. Your only reliable mitigation right now is rapid, verified deployment of 155.0.8059.39+ across every managed and unmanaged endpoint.
If your fleet management telemetry shows Chrome versions below this build after rollout completes, treat those hosts as exposed.
Technical Analysis
Affected Products and Versions
| Platform | Fixed Version |
|---|---|
| Windows | 155.0.8059.39 / 155.0.8059.40 |
| macOS | 155.0.8059.39 / 155.0.8059.40 |
| Linux | 155.0.8059.39 |
Any Chrome installation below 155.0.8059.39 is vulnerable. The rollout is staged over the coming days and weeks, so auto-update alone will leave gaps — force the update where you can.
Also in scope: Chromium-based downstream browsers (Microsoft Edge, Brave, Opera, Vivaldi) consume the same engine fixes on their own cadence. Track their advisories separately — a patched Chrome and an unpatched Edge on the same host is a common audit failure.
The Vulnerabilities
CVE-2026-106382 — Use After Free in Chromecast (Critical). Reported by Google internally. A use-after-free (UAF) occurs when code continues to reference memory after it has been freed, allowing an attacker to reallocate that memory region with controlled data and hijack execution flow. In the Chromecast component, exploitation would likely require interaction with casting functionality — but note that Chrome's cast service can be reachable in enterprise environments where devices advertise on the local network, making this more than a pure drive-by concern on flat networks.
CVE-2026-106197 — Use After Free in Browser (Critical). Externally reported, which means the researcher (or Google) assessed the component and impact as warranting the highest severity tier. The "Browser" component is Chrome's privileged browser process — not the sandboxed renderer. A UAF here is significant because code execution in the browser process sits outside the renderer sandbox. In practical terms: a bug in this component can collapse the multi-stage exploit chain (renderer RCE → sandbox escape) into fewer steps, depending on the attack surface reachable from web content.
Exploitation Status
- No public proof-of-concept has been released for either CVE as of this writing.
- Google has not flagged either flaw as exploited in the wild in this advisory.
- Bug tracker entries remain restricted, consistent with Google's policy of gating details until patch adoption is broad.
However, historical precedent matters here: Chrome has averaged multiple in-the-wild zero-days per year, and Critical UAFs in the browser process are exactly the bugs that get reverse-engineered from patches within days. Once the binaries are public, diffing 155.0.8059.39 against the prior stable build gives skilled exploit developers a roadmap. Your patch window is the time between now and the first working exploit — assume it is short.
Detection & Response
Post-patch detection for browser UAFs is inherently limited — there are no IOCs. The defensive value here is in three areas: (1) identifying unpatched Chrome versions in your telemetry, (2) detecting post-exploitation behavior (a compromised browser process spawning unexpected children), and (3) surfacing crash artifacts consistent with exploitation attempts. These are high-fidelity hunts, not noise generators.
Sigma Rules
---
title: Chrome Browser Process Spawning Suspicious Child Process
id: 3f8a1c92-5d7e-4b41-a9c6-2e1f8d3b7a45
status: experimental
description: Detects chrome.exe spawning command interpreters, scripting engines, or Office-adjacent processes — a hallmark of successful browser exploitation leading to post-exploitation staging. Relevant to exploitation of critical Chrome UAF flaws such as CVE-2026-106197 and CVE-2026-106382.
references:
- https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html
- https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/10/15
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'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\wmic.exe'
condition: selection_parent and selection_child
falsepositives:
- Rare; some enterprise browser extensions or SSO tooling may spawn helper processes, but chrome.exe spawning cmd.exe or PowerShell is almost never legitimate
level: high
---
title: Outdated Chrome Version Detected in Process Execution
id: 8c2e4f17-6a3d-4e58-b1c9-7d4a2f6e8b31
status: experimental
description: Identifies execution of Chrome builds older than 155.0.8059.39 via version-string-bearing install paths, indicating hosts unpatched against CVE-2026-106197 and CVE-2026-106382. Tune the path matching to your environment's Chrome deployment model.
references:
- https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html
author: Security Arsenal
date: 2026/10/15
tags:
- attack.initial_access
- attack.t1203
logsource:
category: process_creation
product: windows
detection:
selection:
Image|contains:
- '\Google\Chrome\Application\154.'
- '\Google\Chrome\Application\153.'
- '\Google\Chrome\Application\152.'
- '\Google\Chrome\Application\151.'
- '\Google\Chrome\Application\150.'
filter_canary_beta:
Image|contains:
- '\Chrome SxS\'
condition: selection and not filter_canary_beta
falsepositives:
- Versioned Chrome paths only appear when Chrome is installed per-version (enterprise MSI deployments); per-user installs use a flat Application directory
level: medium
KQL (Microsoft Sentinel / Defender)
Hunt unpatched Chrome across the fleet and browser-process anomalies in one pass. The version query is your patch-compliance enforcement; the process query is your post-exploitation tripwire.
// Hunt 1: Fleet-wide Chrome version exposure — hosts running builds below 155.0.8059.39
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName =~ "chrome.exe"
| extend ParsedVersion = parse_version(ProcessVersionInfoProductVersion)
| summarize LastSeen = max(TimeGenerated),
ChromeVersion = any(ProcessVersionInfoProductVersion),
UserCount = dcount(AccountName)
by DeviceName
| extend Parsed = parse_version(ChromeVersion)
| extend IsVulnerable = iff(Parsed.Major < 155
or (Parsed.Major == 155 and Parsed.Minor == 0 and Parsed.Build < 8059)
or (Parsed.Major == 155 and Parsed.Minor == 0 and Parsed.Build == 8059 and Parsed.Revision < 39), true, false)
| where IsVulnerable == true
| project DeviceName, ChromeVersion, LastSeen, UserCount
| order by LastSeen desc;
// Hunt 2: Post-exploitation behavior — chrome.exe spawning LOLBins or shells
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",
"certutil.exe", "bitsadmin.exe", "wmic.exe")
| project TimeGenerated, DeviceName, AccountName,
InitiatingProcessCommandLine, FileName, ProcessCommandLine, SHA256
| order by TimeGenerated desc;
// Hunt 3: Chrome crash clustering — repeated renderer/browser crashes on a host can indicate exploit attempts (heap grooming failures)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName =~ "chrome.exe"
| where ProcessCommandLine has "--type=" // renderer/GPU/utility child processes
| summarize ChildSpawns = count() by DeviceName, bin(TimeGenerated, 1h)
| where ChildSpawns > 500 // abnormal churn baseline — tune per environment
| order by ChildSpawns desc
Velociraptor VQL
Use this artifact to enumerate installed Chrome versions across the estate for patch verification — the most operationally important step after a critical browser advisory.
-- Enumerate installed Chrome versions and running instances for patch verification
-- against CVE-2026-106197 / CVE-2026-106382 (fixed in 155.0.8059.39)
LET installs = SELECT FullPath,
parse_string_with_regex(
string=FullPath,
regex='Application\\(?P<ver>[0-9.]+)\\').ver AS Version
FROM glob(globs='C:/Program Files*/Google/Chrome/Application/*/chrome.exe')
LET running = SELECT Pid, Name, Exe, Username, CreateTime, CommandLine
FROM pslist()
WHERE Name =~ 'chrome'
SELECT * FROM installs
UNION ALL
SELECT Exe AS FullPath, 'RUNNING: ' + str(string=Pid) AS Version FROM running
Remediation / Verification Script
Run this PowerShell snippet via your RMM or as an Intune remediation to force-update Chrome and verify the resulting version on Windows endpoints.
# Force Chrome update and verify version >= 155.0.8059.39 (CVE-2026-106197 / CVE-2026-106382)
$minVersion = [version]"155.0.8059.39"
# Trigger Google Update (Omaha) for Chrome if present
$updateExe = "$env:ProgramFiles(x86)\Google\Update\GoogleUpdate.exe"
if (Test-Path $updateExe) {
& $updateExe /ua /installsource scheduler 2>$null
Start-Sleep -Seconds 90
}
# Locate chrome.exe (system and per-user installs)
$paths = @(
"$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
"$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
)
$chrome = $paths | Where-Object { Test-Path $_ } | Select-Object -First 1
if (-not $chrome) {
Write-Output "CHROME_NOT_INSTALLED"
exit 0
}
$installed = [version](Get-Item $chrome).VersionInfo.ProductVersion
if ($installed -ge $minVersion) {
Write-Output "COMPLIANT: Chrome $installed"
exit 0
} else {
Write-Output "NONCOMPLIANT: Chrome $installed < $minVersion — user must restart browser"
exit 1
}
For Linux fleets:
#!/bin/bash
# Verify/update Chrome on Debian/Ubuntu and RHEL-based systems
MIN="155.0.8059.39"
if command -v google-chrome >/dev/null 2>&1; then
CUR=$(google-chrome --version | grep -oE '[0-9.]+')
if [ "$(printf '%s\n%s\n' "$MIN" "$CUR" | sort -V | head -1)" = "$MIN" ]; then
echo "COMPLIANT: Chrome $CUR"
else
echo "NONCOMPLIANT: Chrome $CUR < $MIN — updating"
(apt-get update && apt-get install -y --only-upgrade google-chrome-stable) 2>/dev/null \
|| yum update -y google-chrome-stable 2>/dev/null
google-chrome --version
fi
else
echo "CHROME_NOT_INSTALLED"
fi
Remediation
-
Deploy Chrome 155.0.8059.39 (or .40) immediately. Do not wait for the staged auto-update rollout. Use your software distribution platform (Intune, SCCM/MECM, Jamf, GPO with the Chrome ADMX template, or your Linux package manager) to push the update.
-
Enforce browser restart. Chrome's update does not take effect until the browser restarts. Users running week-old sessions remain fully vulnerable. Set the
RelaunchNotificationandRelaunchNotificationPeriodenterprise policies to force relaunch within 24–48 hours. -
Verify at scale, don't trust the push. Use the KQL hunt and scripts above to produce an authoritative list of non-compliant hosts. Report completion percentage daily to your vulnerability management program until you hit 100%.
-
Patch Chromium derivatives on their own timelines. Confirm Edge, Brave, Opera, and other Chromium browsers in your environment have shipped builds incorporating the same fixes. Do not assume parity.
-
Address Chromecast exposure for CVE-2026-106382. Segment casting devices onto isolated VLANs and restrict mDNS/cast discovery traffic between user and device subnets. Even after patching, this is sound hygiene — cast protocol abuse is a recurring lateral-movement nuisance on flat networks.
-
Monitor for the inevitable PoC. With bug details restricted, expect public technical write-ups and exploit attempts once patch adoption plateaus. Keep the post-exploitation detection rules above in production — they catch the payload behavior regardless of which specific CVE delivered it.
-
Review your browser patch SLA. Two Critical UAFs in one release — one in the privileged browser process — should be treated as a 72-hour patch target under most risk frameworks, and faster if CISA adds either CVE to the Known Exploited Vulnerabilities catalog. Watch the KEV feed closely over the next two weeks.
Official advisory: Chrome Releases Blog — Stable Channel Update for Desktop · Chrome Security Page
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.