Back to Intelligence

Chrome 154 for Android (154.0.8037.126) Released: Why Mobile Browser Patching Is a SOC Priority in 2026

SA
Security Arsenal Team
October 3, 2026
10 min read

Google has released Chrome 154 (154.0.8037.126) for Android, rolling out through Google Play over the coming days. Per the official Chrome Releases blog, Android builds ship with the same security fixes as their corresponding desktop releases — Windows and Mac at 154.0.8037.97/.98, Linux at 153.0.8010.97 — unless otherwise noted. The public announcement does not enumerate individual CVEs, which is standard practice for Google: detailed vulnerability entries are typically withheld until the majority of the user base has updated.

Do not let the bland 'stability and performance improvements' language lull you. Browser security releases are one of the highest-signal events in vulnerability management. Chrome remains the dominant browser across both desktop and Android, and mobile browsers are an increasingly favored initial-access vector — particularly for spyware vendors, financially motivated actors delivering droppers via malvertising, and targeted exploitation chains that begin with a single tap on a link delivered over SMS, messaging apps, or phishing email. If your organization treats Android browser patching as an afterthought, you have an unmonitored, unmanaged attack surface sitting in every employee's pocket.

This post breaks down what the release means, how to verify deployment across your fleet, and how to hunt for the post-exploitation behaviors that browser compromise typically produces.

Technical Analysis

Affected Products and Fixed Versions

PlatformFixed Version
Chrome for Android154.0.8037.126
Chrome for Windows154.0.8037.97 / 154.0.8037.98
Chrome for macOS154.0.8037.97 / 154.0.8037.98
Chrome for Linux153.0.8010.97

Any Chrome installation reporting a version below these thresholds should be treated as unpatched and exposed to whatever security fixes are bundled in this train. Note the Linux build remains on the 153 branch — confirm your Linux fleet is at 153.0.8010.97 or later rather than assuming parity with the Windows/Mac version string.

Why the Silence on CVEs Matters

Google routinely omits CVE identifiers and technical details from stable-channel release announcements, publishing them in the Chrome Releases blog 'Stable Channel Update' posts or the Chromium issue tracker only after patch adoption reaches a threshold. This is deliberate: it reduces the window in which threat actors can reverse-engineer the patch (patch-diffing) and weaponize the underlying flaw before users update. Historically, n-day exploitation of Chrome renderer and V8 JavaScript engine bugs begins within days of a stable release — and in several recent cycles, fixes in 'routine' updates were later revealed to address actively exploited zero-days. Defenders should therefore treat every Chrome stable release as potentially containing a fix for a critical, possibly exploited vulnerability until proven otherwise.

Attack Chain Context: Browser Compromise on Android

From a defender's perspective, a typical Chrome-for-Android exploitation chain looks like this:

  1. Delivery — Malicious link via SMS (smishing), messaging app, malvertising, or compromised legitimate site.
  2. Renderer exploitation — A bug in the Blink rendering engine or V8 JavaScript engine yields code execution inside the sandboxed renderer process.
  3. Sandbox escape — A second bug (often in the GPU process, a system service, or the Android kernel/Qualcomm/Mali drivers) escapes the Chrome sandbox to gain broader device access.
  4. Persistence and payload — Installation of a malicious APK, abuse of accessibility services, overlay attacks for credential theft, or delivery of commercial spyware.

Exploitation requirements are minimal: the victim simply needs to render attacker-controlled content. No file download or user interaction beyond page load is required for renderer-level bugs.

Exploitation Status

No CVEs are disclosed in this announcement, and there is no confirmation at publication time of active exploitation tied to this specific build. However, given the 2025–2026 cadence of in-the-wild Chrome zero-days and the commercial spyware ecosystem's sustained investment in Android browser chains, assume exploits for patched n-days will be developed rapidly. Patch-diffing of Chrome builds is a mature, automated discipline within offensive research circles.

Detection & Response

Because no specific vulnerability indicators are published, detection strategy centers on two things: (1) identifying unpatched Chrome installations across desktop and mobile fleets, and (2) detecting the post-exploitation behaviors that follow browser compromise — most reliably, the browser process spawning unexpected child processes or writing executable payloads.

Sigma Rules

YAML
---
title: Chrome Browser Process Spawning Shell or Script Interpreter
id: 3f8a2c41-9d1e-4b7a-a2f5-6c8d1e4b9a07
status: experimental
description: Detects chrome.exe spawning command shells, script interpreters, or LOLBins, a common post-exploitation behavior following renderer compromise or malicious extension activity.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/10/15
tags:
  - attack.execution
  - attack.t1059
  - attack.t1203
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'
  filter_extensions:
    ParentCommandLine|contains: '--type='
  condition: selection_parent and selection_child and not filter_extensions
falsepositives:
  - Rare; some enterprise extensions or internal web apps launching local helpers. Tune per environment.
level: high
---
title: Executable Dropped into Chrome Download or User Temp and Executed
id: 8b2e5d90-4f1a-4c6b-9e3d-7a5c2f8b1d46
status: experimental
description: Detects execution of binaries from browser download staging or temp directories shortly after creation, consistent with drive-by download or browser-delivered payload execution.
references:
  - https://attack.mitre.org/techniques/T1204.002/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/10/15
tags:
  - attack.execution
  - attack.t1204.002
  - attack.command_and_control
  - attack.t1105
logsource:
  category: process_creation
  product: windows
detection:
  selection_path:
    Image|contains:
      - '\AppData\Local\Temp\'
      - '\AppData\Local\Google\Chrome\User Data\'
      - '\Downloads\'
  selection_ext:
    Image|endswith:
      - '.exe'
      - '.dll'
      - '.scr'
      - '.bat'
      - '.cmd'
      - '.ps1'
      - '.msi'
  filter_known:
    Image|contains:
      - '\Downloads\Teams_windows'
      - '\Downloads\ZoomInstaller'
  condition: selection_path and selection_ext and not filter_known
falsepositives:
  - Users executing legitimately downloaded installers. Whitelist known software distribution paths and review hits for unsigned binaries first.
level: medium

KQL — Microsoft Sentinel / Defender

The first query identifies devices running outdated Chrome builds against the fixed version baselines. The second hunts for the post-exploitation child-process behavior.

KQL — Microsoft Sentinel / Defender
// Hunt 1: Devices running Chrome below the 154.0.8037.97/.98 fixed baseline (Windows/macOS)
DeviceTvmSoftwareInventory
| where SoftwareName has_any ("google_chrome", "chrome")
| extend ParsedVersion = parse_version(SoftwareVersion)
| where ParsedVersion < parse_version("154.0.8037.97")
| summarize arg_max(TimeGenerated, *) by DeviceId, SoftwareName, SoftwareVersion
| project DeviceName, SoftwareName, SoftwareVersion, OSPlatform
| sort by DeviceName asc;

// Hunt 2: Chrome spawning suspicious child processes (post-exploitation indicator)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| 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", "msiexec.exe")
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessCommandLine,
    FileName, ProcessCommandLine, SHA256, FolderPath
| sort by TimeGenerated desc;

// Hunt 3: Android devices with outdated Chrome (requires Defender for Endpoint mobile onboarding or Intune sync)
DeviceInfo
| where OSPlatform has_any ("Android")
| join kind=inner (
    DeviceTvmSoftwareInventory
    | where SoftwareName has "chrome"
) on DeviceId
| where parse_version(SoftwareVersion) < parse_version("154.0.8037.126")
| project DeviceName, OSPlatform, SoftwareVersion, LoggedOnUsers

Velociraptor VQL

This artifact enumerates the installed Chrome version on Windows endpoints for fleet-wide patch verification, and flags chrome.exe processes with unexpected children during triage.

VQL — Velociraptor
-- Verify Chrome version and inspect chrome.exe process trees for suspicious children
SELECT * FROM foreach(
    row={
        SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
        FROM pslist()
        WHERE Name =~ '(?i)chrome\.exe$'
    },
    query={
        SELECT Pid, Ppid, Name, Exe, Username, CreateTime,
               parse_pe(file=Exe).FileVersion AS ChromeVersion,
               CommandLine
        FROM scope()
        WHERE Name =~ '(?i)chrome\.exe$'
    })

-- Companion: children spawned by any chrome.exe process
SELECT child.Pid AS ChildPid, child.Name AS ChildName,
       child.CommandLine AS ChildCommandLine, child.Exe AS ChildExe,
       parent.Name AS ParentName, parent.Pid AS ParentPid,
       child.Username AS Username, child.CreateTime AS CreateTime
FROM foreach(
    row={
        SELECT Pid AS ParentPid, Name AS ParentName
        FROM pslist()
        WHERE Name =~ '(?i)chrome\.exe$'
    },
    query={
        SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime,
               ParentPid, ParentName
        FROM pslist()
        WHERE Ppid = ParentPid
            AND Name =~ '(?i)(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|certutil|msiexec)\.exe$'
    })

Remediation Script — Patch Verification

For Windows endpoints, verify Chrome is at or above the fixed build. For Android devices enrolled in your MDM or accessible via ADB, verify the package version. For Linux, check the installed package against the 153.0.8010.97 baseline.

PowerShell
# Chrome patch verification — Windows fleet (run via RMM/Intune/SCCM or locally)
$FixedVersion = [version]"154.0.8037.97"
$Paths = @(
    "${env:ProgramFiles}\Google\Chrome\Application\chrome.exe",
    "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
    "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
)
$Found = $false
foreach ($Path in $Paths) {
    if (Test-Path $Path) {
        $Found = $true
        $Installed = [version](Get-Item $Path).VersionInfo.ProductVersion
        if ($Installed -ge $FixedVersion) {
            Write-Output "COMPLIANT: Chrome $Installed at $Path (>= $FixedVersion)"
        } else {
            Write-Output "NON-COMPLIANT: Chrome $Installed at $Path — update required"
            # Trigger enterprise update mechanism if configured
            $UpdateExe = "${env:ProgramFiles(x86)}\Google\Update\GoogleUpdate.exe"
            if (Test-Path $UpdateExe) {
                Start-Process $UpdateExe -ArgumentList "/ua /installsource scheduler" -NoNewWindow
            }
        }
    }
}
if (-not $Found) { Write-Output "INFO: Chrome not installed on this host." }
Bash / Shell
#!/bin/bash
# Chrome/Chromium patch verification — Linux and Android (via ADB)

FIXED_LINUX="153.0.8010.97"
FIXED_ANDROID="154.0.8037.126"

# --- Linux desktop check ---
if command -v google-chrome >/dev/null 2>&1; then
    INSTALLED=$(google-chrome --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')
    echo "[Linux] Chrome installed: $INSTALLED (fixed baseline: $FIXED_LINUX)"
    if [ "$(printf '%s\n' "$FIXED_LINUX" "$INSTALLED" | sort -V | head -n1)" != "$FIXED_LINUX" ]; then
        echo "[Linux] NON-COMPLIANT — run: sudo apt update && sudo apt install --only-upgrade google-chrome-stable"
    else
        echo "[Linux] COMPLIANT"
    fi
fi

# --- Android check via ADB (device must be connected/authorized) ---
if command -v adb >/dev/null 2>&1 && adb get-state 2>/dev/null | grep -q device; then
    ANDROID_VER=$(adb shell dumpsys package com.android.chrome | grep -m1 versionName | cut -d= -f2 | tr -d ' \r')
    echo "[Android] Chrome installed: $ANDROID_VER (fixed baseline: $FIXED_ANDROID)"
    if [ "$(printf '%s\n' "$FIXED_ANDROID" "$ANDROID_VER" | sort -V | head -n1)" != "$FIXED_ANDROID" ]; then
        echo "[Android] NON-COMPLIANT — push update via Managed Google Play or instruct user to update"
    else
        echo "[Android] COMPLIANT"
    fi
fi

Remediation

  1. Update Chrome for Android to 154.0.8037.126 immediately. For BYOD devices, push communications directing users to Google Play → Manage apps → Update. For managed devices, enforce the update through Managed Google Play in your MDM (Intune, Workspace ONE, etc.) and set a compliance policy flagging devices below the fixed build.
  2. Update desktop Chrome in parallel. Windows/macOS baseline: 154.0.8037.97/.98. Linux baseline: 153.0.8010.97. Do not assume Linux is on the 154 branch — validate against the correct version string.
  3. Force browser restart. Chrome's update is not active until the browser restarts. On managed desktops, use the RelaunchNotification / RelaunchNotificationPeriod Chrome Enterprise policies (or relaunch windows via your RMM) to force restart within 24–48 hours of update availability.
  4. Enable auto-update enforcement. Verify Google Update (desktop) and Managed Google Play auto-update (Android) are not disabled by policy. Audit for the UpdateDefault / UpdatePolicyOverride registry values being set to disabled.
  5. Verify via tooling, not trust. Run the version-verification scripts above across your fleet and feed non-compliant assets into your vulnerability management queue with a 72-hour SLA — browser updates should be treated with the same urgency as CISA KEV items given the historical rate of post-release exploitation.
  6. Harden mobile posture. Ensure Play Protect is enabled on managed Android devices, restrict sideloading (block installation from unknown sources), and consider mobile threat defense (MTD) integration for devices accessing corporate resources.
  7. Monitor the Chrome Releases blog and Chrome Security RSS for the follow-up disclosure of specific CVEs bundled in this release. If any are later confirmed as exploited-in-the-wild or added to CISA KEV, escalate remaining unpatched assets to emergency change.

Official source: Chrome Releases Blog — Chrome for Android Update

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.