Chrome 155 for Android (155.0.8059.84): Closing the Mobile Browser Patch Gap Before Attackers Exploit It

Google has released Chrome 155 (155.0.8059.84) for Android, rolling out via Google Play over the coming days. The release notes are terse — "stability and performance improvements" — but the critical line for defenders is the one at the bottom: Android releases contain the same security fixes as their corresponding Desktop releases (Windows & Mac: 155.0.8059.84/.85, Linux: 155.0.8059.84). In plain terms, whatever vulnerabilities warranted a desktop Stable channel refresh are also patched in this Android build.

If your vulnerability management program tracks desktop Chrome aggressively but treats Android as an afterthought, you have a measurable, exploitable asymmetry. Mobile devices hold the same corporate credentials, session tokens, MFA apps, and SaaS access as laptops — but they typically sit outside your EDR visibility, outside your patch SLAs, and outside your detection coverage. Attackers know this. Browser exploitation against mobile targets has been a consistent feature of both commercial spyware operations and financially motivated campaigns, and a version lag of even a few weeks on Android is a window an adversary can walk through.

This post covers what this release means, why the Android patch gap is a genuine enterprise risk, how to hunt for outdated and potentially compromised browser instances, and exactly how to remediate.

Technical Analysis

Affected Products and Versions

• Google Chrome for Android — all versions prior to 155.0.8059.84
• Corresponding desktop builds: Windows & Mac 155.0.8059.84/.85, Linux 155.0.8059.84
• By extension, any Android applications embedding Chromium-based WebView should be monitored for corresponding WebView updates via Google Play, as WebView security fixes typically track the same Chromium release train

What the Release Contains

Google's announcement does not enumerate individual CVEs in the Android channel post — the security fix detail lives in the corresponding desktop Stable Channel update, and Google explicitly states the Android build carries the same fixes. This is standard Chrome release practice: Android posts are short-form, and the full vulnerability list (with CVE identifiers, reporter credits, and bounty amounts) appears in the desktop advisory and the Chromium Git log referenced in the announcement.

From a defender's perspective, the operational facts are:

1. Security fixes are included, even though the headline says "stability and performance." Chrome Stable channel refreshes with matching desktop build numbers ship the desktop security patch set.
2. The rollout is staged. "It'll become available on Google Play over the next few days" means your fleet will patch asynchronously — devices with auto-update disabled, devices on metered connections, and devices with deferred Play Store updates will trail the release by days or weeks.
3. The vulnerability details are now public. Once the desktop advisory publishes fix details and the Chromium Git log shows the patched commits, the clock starts. Patch-diffing Chromium releases to identify the fixed bug classes is a well-established technique used by both researchers and exploit developers. The n-day window between public disclosure and fleet-wide patching is your exposure period.

Attack Surface Context (Defender's Perspective)

Modern browser exploitation typically chains two components: a renderer compromise (V8 JavaScript engine or Blink rendering bugs — type confusion, use-after-free, out-of-bounds write) followed by a sandbox escape. On Android, the exploit chain differs from desktop but the delivery vector is identical: drive-by compromise via a malicious or compromised web page. A user on an unpatched Chrome for Android build who clicks a phishing link, scans a malicious QR code, or visits a watering-hole site is the entry point. No user interaction beyond rendering the page is required for the initial stage of a renderer exploit.

The exploitation status for the specific fixes in 155.0.8059.84 is not detailed in this announcement — no in-the-wild exploitation is flagged in the Android post. However, defenders should treat every Chrome security refresh as urgent by default: Chrome zero-days have been exploited in the wild repeatedly, and the Git log visibility means benign-looking releases still expose fix details to anyone motivated enough to diff them.

Detection & Response

You cannot deploy traditional EDR telemetry to most Android fleets the way you can on Windows. Your detection strategy for this class of threat is therefore three-layered: (1) inventory and version control via MDM, (2) network-layer visibility into outdated browser versions traversing your proxies, and (3) desktop-side behavioral detection for the post-exploitation patterns that follow browser compromise — because if a Chromium exploit chain lands on a managed desktop, the renderer-to-shell transition is your best detection opportunity.

Sigma Rules

The first rule targets the highest-fidelity behavioral indicator of browser exploitation on managed endpoints: Chrome spawning a command interpreter or script host. This is a classic post-exploitation pivot and fires on almost nothing legitimate. The second is a network hunting rule for outdated Chrome versions observed in proxy logs — low severity, but it directly identifies unpatched exposure for this release.

---
title: Chrome Browser Process Spawning Command Interpreter
description: Detects Chrome (browser or renderer process) spawning a shell, script host, or LOLBin. This parent-child relationship is a strong indicator of successful browser exploitation or malicious extension behavior and has near-zero legitimate prevalence.
references:
  - https://attack.mitre.org/techniques/T1203/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/20
id: 3f8a1c72-6b4d-4e91-a2c7-9d5e8f012346
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'
      - '\wmic.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare enterprise browser extensions performing system integration (investigate per-extension)
level: high
---
title: Outdated Chrome Version Observed in Web Proxy Traffic
description: Identifies HTTP user-agents indicating Chrome versions older than 155.0.8059.84, flagging unpatched desktop and Android Chrome clients traversing the network. Use as a hunting rule to drive patch compliance, not as an alerting rule.
references:
  - https://chromereleases.googleblog.com/
author: Security Arsenal
date: 2026/10/20
id: 8c2e5b19-4a7f-4d38-b6e1-3c9a7f205814
status: experimental
tags:
  - attack.initial_access
  - attack.t1189
logsource:
  category: proxy
detection:
  selection:
    c-useragent|contains:
      - 'Chrome/154.'
      - 'Chrome/153.'
      - 'Chrome/152.'
      - 'Chrome/151.'
      - 'Chrome/150.'
      - 'Chrome/149.'
      - 'Chrome/148.'
      - 'Chrome/147.'
      - 'Chrome/146.'
      - 'Chrome/145.'
  condition: selection
falsepositives:
  - Intentionally pinned browser versions for legacy application compatibility (document and isolate these)
level: informational

KQL — Microsoft Sentinel / Defender

Two hunts: the first inventories managed Windows endpoints running Chrome builds older than 155.0.8059.84, giving you a patch-compliance target list. The second hunts the post-exploitation behavior (Chrome spawning shells) across Defender for Endpoint process telemetry. If you ingest proxy/firewall logs into Sentinel via CommonSecurityLog, adapt the outdated-user-agent logic there as well.

// Hunt 1: Endpoints running Chrome builds older than 155.0.8059.84
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName =~ "chrome.exe"
| extend ParsedVersion = parse_version(ProcessVersionInfoProductVersion)
| where isnotempty(ProcessVersionInfoProductVersion)
| summarize LastSeen = max(TimeGenerated), LatestVersion = max(ProcessVersionInfoProductVersion) by DeviceName, DeviceId
| where parse_version(LatestVersion) < parse_version("155.0.8059.84")
| project DeviceName, LatestVersion, LastSeen
| order by LastSeen desc
;
// Hunt 2: Chrome spawning command interpreters or script hosts (post-exploitation pivot)
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","wmic.exe")
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, SHA256
| order by TimeGenerated desc

Velociraptor VQL

For DFIR triage on a host you suspect experienced a browser-drive-by, this artifact enumerates running processes and flags any shell or script host whose lineage involves Chrome — useful for live-response when you get a hit from the rules above.

-- Hunt for command interpreters or script hosts spawned by Chrome (browser exploitation indicator)
LET chrome_pids = SELECT Pid
FROM pslist()
WHERE Name =~ 'chrome'

SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Ppid in chrome_pids
  AND Name =~ '(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|wmic)'

Remediation

Immediate Actions

1. Enforce the update on managed Android devices. Push Chrome 155.0.8059.84 or later through your MDM/UEM platform (Intune, Workspace ONE, ManageEngine, Google endpoint management) using managed Google Play. Do not rely on consumer auto-update. Set Chrome as a required app with a minimum version floor and enforce update priority.
2. Verify desktop fleet parity. Confirm Windows/Mac endpoints are on 155.0.8059.84/.85 and Linux on 155.0.8059.84. The desktop advisory carries the actual security fix details — read it and check whether any fixes are flagged as exploited in the wild, which would escalate this from routine to emergency patching and potentially trigger CISA KEV-driven deadlines.
3. Update Android System WebView. Confirm WebView updates are also flowing through managed Play — WebView shares the Chromium codebase and inherits the same vulnerability classes, and many enterprise apps render content through it.
4. Address the long tail. Devices with auto-update disabled, personally-owned BYOD devices with work profiles, and devices stuck on metered connections will trail. Set an MDM compliance policy that flags devices with Chrome older than 155 after a defined grace period (recommend 7 days) and gates corporate access (Conditional Access / device compliance) on remediation.

Verification

Use the following scripts to validate Chrome versions across managed Windows and Linux fleets. For Android, version compliance must come from your MDM inventory — there is no equivalent local scripting path on non-rooted devices.

# Verify Chrome version on Windows endpoints — flag anything below 155.0.8059.84
$targetVersion = [version]"155.0.8059.84"
$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
        if ($installed -lt $targetVersion) {
            Write-Output "NONCOMPLIANT: Chrome $installed at $path — update to $targetVersion or later"
        } else {
            Write-Output "COMPLIANT: Chrome $installed at $path"
        }
    }
}
# Trigger Chrome enterprise update check via registry policy verification
$updatePolicy = Get-ItemProperty "HKLM:\SOFTWARE\Policies\Google\Update" -ErrorAction SilentlyContinue
if (-not $updatePolicy) {
    Write-Output "WARNING: No Google Update policy found — auto-updates may not be enforced"
}

# Verify Chrome version on Linux endpoints — flag anything below 155.0.8059.84
TARGET="155.0.8059.84"
if command -v google-chrome >/dev/null 2>&1; then
    INSTALLED=$(google-chrome --version | awk '{print $3}')
    if [ "$(printf '%s\n%s\n' "$TARGET" "$INSTALLED" | sort -V | head -n1)" != "$TARGET" ]; then
        echo "NONCOMPLIANT: Chrome $INSTALLED — run: sudo apt-get update && sudo apt-get install --only-upgrade google-chrome-stable"
    else
        echo "COMPLIANT: Chrome $INSTALLED"
    fi
else
    echo "Chrome not installed on this host"
fi

Ongoing Hardening

• Set a fleet-wide Chrome patch SLA of 72 hours for security refreshes and 24 hours for any release flagged with active exploitation.
• Enable Chrome's enterprise update policies (Google Update for Windows, managed Play for Android) rather than leaving updates to user discretion.
• Monitor the Chrome Releases blog and the desktop Stable Channel advisories — the Android posts are intentionally minimal; the desktop posts carry the CVE and severity detail your risk assessment needs.
• Treat browser version telemetry as a vulnerability management data source. Feed proxy user-agent data and MDM inventory into your vulnerability dashboard so the mobile browser gap is measured, not assumed.

Related Resources

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