Google has released Chrome 155 (build 155.0.8059.39) for Android, rolling out via Google Play over the coming days. The official release note is terse — stability and performance improvements, a pointer to the Git log, and a bug-filing link — but the line that matters to defenders is this one: Android releases contain the same security fixes as their corresponding Desktop releases (Windows & Mac: 155.0.8059.39/.40, Linux: 155.0.8059.39) unless otherwise noted.
That sentence is your action trigger. Chrome desktop channel updates in this cadence class routinely ship patches for vulnerabilities that are either under active exploitation or at high risk of rapid weaponization. Google's practice of withholding CVE details until a majority of users are patched means the absence of a public CVE list in the release note is not evidence of low severity — it is standard disclosure hygiene while the fleet updates. The defensive posture is the same as it is for every Chrome stable-channel bump: treat it as a priority patch, deploy it fast, and verify compliance across every device that can reach your data.
The mobile dimension is what makes this release worth a closer look. In most enterprises, desktop Chrome patch compliance is enforced by tooling — WSUS-adjacent update rings, Intune, Jamf, or Chrome Browser Cloud Management. Android Chrome, by contrast, frequently rides on unmanaged or loosely managed devices: BYOD phones with corporate email, contractor handsets, shared frontline devices, and executives' personal tablets. Those devices authenticate to M365, VPNs, SaaS consoles, and internal portals. A renderer exploit on a mobile browser is no longer a nuisance — it is a credential theft and session hijack vector pointed directly at your identity perimeter.
Technical Analysis
Affected products and versions
- Chrome for Android prior to 155.0.8059.39
- Corresponding desktop builds carrying the same fix set: Windows & Mac 155.0.8059.39/.40, Linux 155.0.8059.39
- Any Chromium-derived browser or embedded WebView on Android that has not yet absorbed the upstream fixes (third-party Chromium forks and Android System WebView lag the main Chrome release by days to weeks)
Vulnerability details
Google's release note does not enumerate individual CVEs at publication time — consistent with their policy of restricting bug details until the patch has saturated the user base. What we know operationally:
- The Android build carries the same security fix set as the simultaneous desktop release. Historically, desktop stable updates in this format have included fixes for V8 type confusion, use-after-free in browser components, and sandbox escape chains — the vulnerability classes most frequently exploited in the wild against Chrome.
- Android adds an exploitation dimension desktop lacks: WebView. Android System WebView renders web content inside third-party apps, meaning an attacker does not need the victim to open Chrome — a malicious ad network, a phishing link opened in a mail client, or an in-app browser can reach the same renderer code paths.
- Mobile exploitation tradecraft in 2025 and 2026 has trended toward zero-click and one-click watering-hole chains targeting mobile browsers as the initial entry point in spyware and APT campaigns. Patching latency on mobile is the gap these operators count on.
Exploitation status
No CVE identifiers, in-the-wild confirmation, or CISA KEV entries are referenced in this specific release note. That should be read as status unknown, treat as urgent — not as safe to defer. Google's own historical pattern shows that a meaningful share of stable-channel updates include at least one vulnerability with an exploit in the wild, disclosed only after patch adoption crosses their threshold. Monitor the Chrome Releases blog for the retrospective CVE list and cross-check against the CISA Known Exploited Vulnerabilities catalog as entries are published.
Attack chain from a defender's perspective
A typical mobile Chrome exploitation chain looks like this:
- Delivery — spear-phish link via SMS/email/messaging app, malvertising redirect, or compromised watering-hole site.
- Renderer compromise — V8 or Blink bug yields code execution inside the sandboxed renderer process.
- Sandbox escape — a second bug (often in the GPU process, broker interface, or the Android kernel/vendor driver layer) breaks out to full app or system context.
- Post-exploitation — credential and cookie theft, session token exfiltration, or staging of a persistent implant.
Your patching window is the distance between step 1 and step 4. Every unpatched device extends it.
Detection & Response
Version-based hunting is your highest-fidelity control here: find every endpoint running Chrome below 155.0.8059.39 and treat it as an exposure. Layer behavioral detections on top to catch exploitation attempts against the lagging devices.
Sigma Rules
These rules target the post-exploitation behaviors common to browser compromise chains — a renderer or browser process spawning script interpreters or command shells, and sandbox-disabling flags that indicate tampering or exploit staging.
---
title: Chrome Spawning Command Shell or Script Interpreter
id: 8f2e6a41-3b7c-4d9e-a51f-2c4d7e9b0135
status: experimental
description: Detects chrome.exe spawning cmd, powershell, wscript, cscript, or mshta — a common post-exploitation indicator following browser renderer compromise.
references:
- https://chromereleases.googleblog.com/2026/10/chrome-for-android-update_01835271525.html
- https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/10/21
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'
condition: selection_parent and selection_child
falsepositives:
- Rare legitimate enterprise extensions launching helper processes
- Developer tooling launched from Chrome DevTools
level: high
---
title: Chrome Launched With Sandbox Disabled
id: 4d1b9c73-6e2a-4f58-b317-9a5c2d8e6041
status: experimental
description: Detects chrome.exe launched with --no-sandbox or related sandbox-disabling flags, which can indicate exploit staging, tampering, or malicious shortcut modification.
references:
- https://chromereleases.googleblog.com/2026/10/chrome-for-android-update_01835271525.html
- https://attack.mitre.org/techniques/T1218/
author: Security Arsenal
date: 2026/10/21
tags:
- attack.defense_evasion
- attack.t1218
logsource:
category: process_creation
product: windows
detection:
selection_image:
Image|endswith: '\chrome.exe'
selection_flags:
CommandLine|contains:
- '--no-sandbox'
- '--disable-features=RendererCodeIntegrity'
- '--disable-popup-blocking --no-first-run --no-sandbox'
condition: selection_image and selection_flags
falsepositives:
- Legacy application compatibility testing
- Some CI/CD automated browser testing frameworks
level: medium
KQL (Microsoft Sentinel / Defender)
Two hunts: first, inventory every Windows endpoint running a Chrome build below the patched baseline; second, hunt the post-exploitation child-process behavior fleet-wide.
// Hunt 1: Endpoints running Chrome below 155.0.8059.39
DeviceTvmSoftwareInventory
| where SoftwareName has "chrome"
| extend ParsedVersion = parse_version(SoftwareVersion)
| where ParsedVersion < parse_version("155.0.8059.39")
| summarize arg_max(LastSeenTime, *) by DeviceName, SoftwareVersion
| project DeviceName, SoftwareVersion, OSPlatform, LastSeenTime
| order by SoftwareVersion asc
// Hunt 2: Chrome spawning script interpreters or shells (post-exploitation indicator)
DeviceProcessEvents
| where InitiatingProcessFileName =~ "chrome.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe")
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessCommandLine, FileName, ProcessCommandLine
| order by TimeGenerated desc
For Android devices enrolled in Defender for Endpoint, complement this with app inventory review in Intune or your MDM's compliance blade — Defender's Android telemetry surfaces installed app versions through the MDM integration rather than the tables above.
Velociraptor VQL
Enumerate Chrome installs and their on-disk version folders across Windows endpoints. The Chrome application directory names itself after the installed version, which gives you a fast filesystem-based version check without querying the registry.
-- Enumerate installed Chrome versions via version-named application folders
SELECT FullPath,
basename(path=dirname(path=FullPath)) AS ChromeVersion,
Mtime AS BinaryModified,
hostname() AS Hostname
FROM glob(globs='C:/Program Files*/Google/Chrome/Application/*/chrome.exe')
ORDER BY ChromeVersion ASC
Pair this with a pslist() sweep for chrome.exe processes whose loaded version folder differs from the newest on disk — a tell that Chrome has updated on disk but the browser has not been restarted, leaving the old vulnerable process running.
-- Find running Chrome processes (compare process path against newest installed version)
SELECT Pid, Name, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ 'chrome.exe'
Remediation Verification Script
Run this across your Windows fleet (via RMM, Intune remediation, or GPO scheduled task) to verify Chrome is at or above the patched baseline and flag devices where the on-disk update is pending a browser restart.
# Verify Chrome version against the 155.0.8059.39 patched baseline
$baseline = [version]"155.0.8059.39"
$results = @()
# Check both install locations (system and per-user)
$chromePaths = @(
"${env:ProgramFiles}\Google\Chrome\Application\chrome.exe",
"${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
"$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
)
foreach ($path in $chromePaths) {
if (Test-Path $path) {
$installed = [version](Get-Item $path).VersionInfo.ProductVersion
$status = if ($installed -ge $baseline) { "PATCHED" } else { "EXPOSED" }
$results += [PSCustomObject]@{
Computer = $env:COMPUTERNAME
Path = $path
Version = $installed
Status = $status
}
}
}
# Detect running Chrome processes launched before the newest on-disk build
$running = Get-Process chrome -ErrorAction SilentlyContinue | Select-Object -First 1 -ExpandProperty Path
if ($running -and $results.Count -gt 0) {
$results | Add-Member -NotePropertyName RunningProcess -NotePropertyValue $running -Force
}
if ($results.Count -eq 0) {
Write-Output "Chrome not found on $env:COMPUTERNAME"
} else {
$results | Format-Table -AutoSize
$exposed = $results | Where-Object { $_.Status -eq "EXPOSED" }
if ($exposed) {
Write-Warning "Chrome below baseline 155.0.8059.39 — force update via Chrome Browser Cloud Management or reinstall from https://www.google.com/chrome/"
exit 1
}
}
exit 0
Remediation
1. Push the Android update now. Chrome 155.0.8059.39 is distributing through Google Play over the next several days — that staged rollout is your enemy. For managed devices, do not wait on users:
- Intune / Managed Google Play: Set the Chrome app deployment to Required and enable priority or expedited app updates where supported. Configure an app compliance policy with minimum version 155.0.8059.39 and mark non-compliant devices at a short grace period.
- Conditional Access: Gate M365, VPN, and SaaS access on device compliance so unpatched Android devices lose access to corporate resources until Chrome updates. This converts a patching problem into a self-remediating one.
- BYOD without MDM enrollment: Send a targeted advisory to your user base instructing manual update via Google Play → Profile → Manage apps & device → Update Chrome. Verify coverage through your identity provider's device logs.
2. Don't forget WebView. Audit Android System WebView versions across the fleet — it is updated separately from Chrome and exposes the same renderer code inside third-party apps. Enforce minimum versions for both.
3. Close the desktop loop. Confirm Windows/Mac/Linux fleets are on 155.0.8059.39/.40 (Windows & Mac) or 155.0.8059.39 (Linux). Chrome updates are delivered on disk silently but require a browser restart to activate — hunt for running processes on stale builds, not just installed versions. Force restarts through Chrome Browser Cloud Management's RelaunchNotification and RelaunchWindow policies.
4. Verify third-party Chromium derivatives. Edge, Brave, Opera, Vivaldi, and embedded Chromium runtimes (Electron apps) absorb upstream fixes on their own schedules. Track their advisories separately — "we patched Chrome" does not mean the browser attack surface is closed.
5. Monitor for retrospective disclosure. Watch the Chrome Releases blog for the CVE list attached to this milestone and check each entry against the CISA KEV catalog. If any entry lands in KEV, federal civilian agencies face a binding remediation deadline under BOD 22-01, and your own SLA should be tighter than that deadline.
6. Validate with an adversary's eye. After the patch wave, have your red team or pen-testing partner confirm that mobile browsing paths — phishing-resistant MFA bypass attempts, session token theft from mobile browsers, WebView-based payload delivery — are actually covered by your controls. A patched browser plus an unmonitored identity plane is still a breach waiting for a link click.
The recurring lesson of Chrome stable-channel bumps is that browser patching is an operational discipline, not an event. The organizations that absorb zero-days without incident are the ones whose mobile fleets patch in hours, whose compliance gates enforce it automatically, and whose SOC hunts stale builds instead of waiting for alerts.
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.