Chrome 156 for Android (156.0.8078.47) Security Update: Patch Verification, Version Inventory, and Exploit Detection Guide

Google has released Chrome 156 (build 156.0.8078.47) for Android, rolling out via Google Play over the coming days. Per the official Chrome Releases blog, this Android build carries the same security fixes as the corresponding desktop release (Windows & Mac: 156.0.8078.47/.48, Linux: 156.0.8078.47). While Google's advisory language is sparse — 'stability and performance improvements' — the explicit statement that Android releases inherit the desktop security fixes is the signal that matters: there are patched vulnerabilities in this train, and your mobile fleet is exposed until it updates.

Chrome is the dominant browser on Android, and Android is the dominant mobile OS in most enterprise fleets. Browser exploits remain the single most common initial-access vector in both commodity drive-by campaigns and targeted operations — watering-hole attacks, malicious ad networks, and phishing-delivered exploit kits all terminate at the browser renderer. When Google ships a security-bearing Chrome build, the correct defensive posture is to treat it as an urgent patch event even before individual CVE details are fully public, because Google's stable-channel release notes routinely understate severity while fixes are already in attackers' diffing pipelines.

Why the 'silent patch' problem matters

Patch diffing is a mature, automated practice. Within hours of a stable Chrome release, offensive researchers and threat actors binary-diff the new build against the prior one, identify the changed functions in Blink, V8, or the Android WebView layer, and reverse-engineer the underlying bug. The window between 'patch available' and 'working exploit' has compressed to days — sometimes hours — for browser bugs. Your only durable defense is shrinking your own patch latency below the attacker's weaponization latency.

Technical Analysis

Affected products and versions

Any Chrome installation below build 156.0.8078.47 on any of these platforms should be treated as unpatched. Note that Chromium-derived browsers (Microsoft Edge, Brave, Vivaldi, Opera) and Android WebView consume these fixes on their own schedules — WebView in particular is a frequently forgotten attack surface on Android, since any app rendering web content through a vulnerable WebView inherits the exposure even if the user never opens Chrome.

What we know about the fixes

Google's Android release announcement does not enumerate individual CVEs in the summary — this is normal for the Android channel announcement, which defers to the desktop Stable Channel update for the security bulletin. Defenders should pull the corresponding desktop Stable Channel Desktop Update post for build 156.0.8078.47/.48 for the CVE list, reward amounts (bounty size is a reliable severity proxy), and any '[actively exploited]' annotations. Key questions to answer from that bulletin:

1. Are any fixes flagged as exploited in the wild? Google annotates these explicitly. If yes, this becomes a CISA KEV candidate and your SLA should tighten to days, not weeks.
2. Which components are touched? V8 (JavaScript engine) and Blink renderer bugs are remotely exploitable via drive-by. GPU, network stack, and sandbox bugs typically require chaining but feature in full exploit chains against high-value targets.
3. Does the fix touch WebView? If so, your Android app inventory matters, not just the Chrome app.

Exploitation status

At time of writing, the advisory does not confirm in-the-wild exploitation for this train, and no CVE identifiers were published in the Android announcement itself. That said, Chrome zero-days patched in stable releases have repeatedly appeared in targeted campaigns within weeks of disclosure, and commercial spyware vendors maintain standing exploit chains against Android Chrome specifically. Treat 'no confirmed exploitation' as 'no confirmed exploitation yet' and patch accordingly.

The defensive attack-chain view

From a defender's perspective, a successful Chrome exploit on Android or desktop has a consistent observable anatomy:

• Stage 1 — Renderer compromise: Malicious JavaScript/WebAssembly triggers a memory-corruption bug in V8 or Blink. The attacker's code now runs inside the sandboxed renderer process.
• Stage 2 — Sandbox escape: A second bug (broker process, GPU process, kernel, or Android system service) breaks out of the renderer sandbox. On desktop, this frequently manifests as chrome.exe unexpectedly spawning child processes — cmd.exe, powershell.exe, rundll32.exe, regsvr32.exe — because post-exploitation tooling runs outside the renderer.
• Stage 3 — Persistence and payload: On desktop, dropped binaries, scheduled tasks, or registry run keys. On Android, abuse of Accessibility Services, sideloaded APKs, or malicious apps requesting elevated permissions.

Stages 2 and 3 are where you win. You cannot detect the renderer exploit itself reliably from the endpoint, but a browser spawning a shell is an extremely high-fidelity signal that something has gone badly wrong.

Detection & Response

The detections below focus on the highest-fidelity observable in browser exploitation: browser processes spawning unexpected children, plus version-inventory hunting so you can prove patch coverage to your CISO.

Sigma Rules

---
title: Chrome Browser Process Spawning Shell or Script Interpreter
id: 9f2c4a71-3b8d-4e6f-a1c2-7d5e9b0f3a41
status: experimental
description: Detects chrome.exe spawning command shells, script interpreters, or LOLBins — a classic post-exploitation indicator of renderer compromise followed by sandbox escape. Correlates with Chrome versions below 156.0.8078.47 for heightened severity.
references:
  - https://chromereleases.googleblog.com/2026/10/chrome-for-android-update_095004068.html
  - https://attack.mitre.org/techniques/T1203/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/13
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 or internal tooling invoking local helpers; investigate and whitelist narrowly by command line
level: high
---
title: Outdated Chrome Version Executing on Endpoint
id: 4b7e1d93-8c2a-4f5b-9d6e-1a3c5e7f9b2d
status: experimental
description: Flags execution of chrome.exe from paths where the binary version may predate the 156.0.8078.47 security build. Use as a hunting complement to asset inventory — tune the version string to your environment's last-known-good baseline.
references:
  - https://chromereleases.googleblog.com/2026/10/chrome-for-android-update_095004068.html
author: Security Arsenal
date: 2026/10/13
tags:
  - attack.initial_access
  - attack.t1189
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\chrome.exe'
  filter_version_path:
    Image|contains:
      - '\Application\156.0.8078.47\'
      - '\Application\156.0.8078.48\'
  condition: selection and not filter_version_path
falsepositives:
  - Environments where Chrome installs to non-versioned paths — validate path structure before deployment
  - Canary/Beta channels on different version trains
level: medium

Analyst note on Rule 2: Chrome's default install layout places the binary under a version-numbered directory (e.g., C:\Program Files\Google\Chrome\Application\156.0.8078.47\chrome.exe). This makes path-based version filtering viable in most enterprise fleets — but confirm your deployment topology first, or this rule will fire on everything.

KQL — Microsoft Sentinel / Defender

Use this to inventory Chrome versions across the fleet and hunt post-exploitation child processes in one pass:

// Hunt 1: Chrome child-process anomalies (post-exploitation behavior)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "chrome.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "mshta.exe",
                      "wscript.exe", "cscript.exe", "rundll32.exe", "regsvr32.exe",
                      "wmic.exe", "certutil.exe", "bitsadmin.exe")
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine, InitiatingProcessFileVersion, SHA256
| sort by TimeGenerated desc;

// Hunt 2: Fleet-wide Chrome version inventory (identify unpatched endpoints)
DeviceProcessEvents
| where TimeGenerated > ago(3d)
| where FileName =~ "chrome.exe"
| summarize LastSeen = max(TimeGenerated),
            Versions = make_set(FileVersion),
            Paths = make_set(FolderPath)
    by DeviceName
| extend IsPatched = Versions has_any ("156.0.8078.47", "156.0.8078.48")
| where IsPatched == false
| sort by LastSeen desc;

For Android fleets, Sentinel ingestion typically comes via your MDM (Intune, Workspace ONE) or mobile threat defense logs rather than Defender process telemetry — query your MDM app inventory table for Chrome package version 156.0.8078.47 to measure rollout coverage.

Velociraptor VQL

This artifact enumerates installed Chrome versions and checks for suspicious browser child processes — useful for a rapid fleet-wide patch-audit sweep:

-- Chrome patch audit: enumerate installed versions and flag suspicious children
-- Deploy as a hunt across the fleet; results feed your vulnerability register

SELECT * FROM foreach(
  row={
     SELECT FullPath
     FROM glob(globs='C:/Program Files*/Google/Chrome/Application/*/chrome.exe')
  },
  query={
     SELECT FullPath AS ChromeBinary,
            basename(path=dirname(path=FullPath)) AS InstalledVersion,
            (InstalledVersion < "156.0.8078.47") AS Unpatched
     FROM scope()
  })

-- Hunt for chrome.exe processes with suspicious child processes running now
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Ppid IN (
   SELECT Pid FROM pslist() WHERE Name =~ 'chrome.exe'
)
AND Name =~ '(?i)(cmd|powershell|pwsh|mshta|wscript|cscript|rundll32|regsvr32|certutil|bitsadmin)'

Remediation Script

Verify and enforce Chrome patch state on Windows endpoints (run via your RMM, Intune, or as a GPO startup script). The second block covers Android fleet verification via ADB for managed/test devices:

# Chrome 156 patch verification - Windows endpoints
$minVersion = [version]"156.0.8078.47"
$chromePaths = @(
    "$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 $chromePaths) {
    if (Test-Path $path) {
        $found = $true
        $ver = [version](Get-Item $path).VersionInfo.ProductVersion
        if ($ver -lt $minVersion) {
            Write-Output "VULNERABLE: $path is version $ver (< $minVersion)"
            # Force update check via Google Update
            $updateExe = "$env:ProgramFiles(x86)\Google\Update\GoogleUpdate.exe"
            if (Test-Path $updateExe) {
                Start-Process $updateExe -ArgumentList "/ua /installsource scheduler" -Wait
                Write-Output "Triggered Google Update - re-verify after restart of Chrome"
            }
        } else {
            Write-Output "COMPLIANT: $path is version $ver"
        }
    }
}
if (-not $found) { Write-Output "Chrome not installed on this endpoint" }

# Also enumerate version-directory installs
Get-ChildItem "C:\Program Files\Google\Chrome\Application" -Directory -ErrorAction SilentlyContinue |
    Where-Object { $_.Name -match '^\d+\.' } |
    ForEach-Object {
        $v = [version]$_.Name
        if ($v -lt $minVersion) { Write-Output "STALE VERSION DIR: $($_.Name) - chrome.dll from this dir may still load" }
    }

#!/bin/bash
# Android Chrome version verification for managed devices reachable via ADB
# For fleet-wide checks, use your MDM's app inventory API instead

for device in $(adb devices | awk 'NR>1 && $2=="device" {print $1}'); do
    ver=$(adb -s "$device" shell dumpsys package com.android.chrome | grep versionName | head -1 | cut -d= -f2)
    major=$(echo "$ver" | cut -d. -f1)
    build=$(echo "$ver" | cut -d. -f4)
    if [ "$major" -lt 156 ] || { [ "$major" -eq 156 ] && [ "$build" -lt 47 ]; }; then
        echo "VULNERABLE: $device running Chrome $ver (need >= 156.0.8078.47)"
    else
        echo "COMPLIANT: $device running Chrome $ver"
    fi
    # Also check WebView - a stale WebView exposes every app rendering web content
    wv=$(adb -s "$device" shell dumpsys package com.google.android.webview | grep versionName | head -1 | cut -d= -f2)
    echo "  WebView on $device: $wv - verify it tracks the 156 train"
done

Remediation

1. Patch immediately. Enforce Chrome 156.0.8078.47 across Android and desktop fleets. On Android, the update rolls out via Google Play over several days — use your MDM to force the update on managed devices rather than waiting for the staged rollout. On desktop, Chrome's relaunch-to-update model means a running browser is an unpatched browser: enforce relaunch policies or kill the process during maintenance windows.
2. Audit Android System WebView. Pull the desktop Stable Channel bulletin for 156.0.8078.47/.48 and check whether fixes touch components shared with WebView. If so, ensure WebView updates are enforced on Android devices — WebView updates independently of Chrome and is a silent laggard in many fleets.
3. Pull the full CVE list. The Android announcement defers to the desktop advisory for security detail. Review the desktop Stable Channel post at the official Chrome Releases blog, map CVEs to your asset inventory, and check CISA KEV for any additions tied to this train. If any fix is annotated as exploited in the wild, escalate to emergency change and document remediation dates for compliance evidence (NIST CSF RS.MI, CIS Control 7).
4. Don't forget Chromium derivatives. Edge, Brave, Opera, and Electron-based applications consume Chromium security fixes on their own cadence. Inventory every Chromium-based browser and embedded framework in your environment and track their uptake of the 156 fix train separately.
5. Reduce attack surface while patching. Enforce site isolation, disable JIT where policy allows for high-risk users (Microsoft Edge's Super Duper Secure Mode concept and Chrome's V8 sandbox mitigations), restrict sideloaded APKs on Android, and block installation of unapproved browsers that won't inherit your patch cadence.
6. Measure and report. Use the KQL inventory query above to produce a daily patch-coverage metric until you hit 100%. Patch latency for browser security updates should be a tracked KPI — target under 72 hours for stable-channel security releases, under 24 hours when exploitation is confirmed.
7. Monitor for exploitation indicators. Deploy the Sigma rules above. A browser spawning a shell is never normal in an enterprise context; treat every hit as a potential incident and initiate triage (memory capture of the renderer process tree, DNS/proxy log review for the session timeframe).

Related Resources

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