CVE-2026-58704: Google Pixel Cellular Modem Vulnerability Actively Exploited — KEV Response and Fleet Remediation Guide

On 2026-09-16, CISA added CVE-2026-58704 to the Known Exploited Vulnerabilities (KEV) catalog, confirming what every mobile fleet defender needed to hear plainly: this is not a theoretical bug. It is being exploited in the wild, right now, against Google Pixel devices.

The vulnerability is an improper authorization flaw in the cellular modem (baseband) stack. A logic error in the modem's permission-checking code allows an attacker to bypass authorization controls and escalate privileges. Baseband vulnerabilities sit in a uniquely dangerous class: the cellular modem runs its own real-time operating system with direct memory access to the application processor on many mobile SoC designs, it processes untrusted input from the cellular network itself, and it is almost entirely opaque to the endpoint detection tooling most organizations deploy. If your threat model assumes EDR will catch post-exploitation on a Pixel device, this CVE is your reminder that the attack surface below Android's application layer is largely invisible to you.

The required action per CISA is unambiguous: apply vendor mitigations in accordance with Binding Operational Directive (BOD) 26-04, "Prioritizing Security Updates Based on Risk," and CISA's Forensics Triage Requirements. Where mitigations are unavailable, discontinue use of the product. This applies directly to federal civilian executive branch agencies, but any organization running Pixel fleets — executive devices, field personnel, BYOD programs with corporate data access — should treat this with the same urgency.

Technical Analysis

Affected Products and Platforms

• Product: Google Pixel devices (cellular modem / baseband component)
• Component: Cellular modem firmware and its interface to the Android application processor
• Vulnerability class: Improper authorization (CWE-863) — a logic error permitting bypass of permission checks
• Impact: Privilege escalation from a lower-privileged execution context, with potential to pivot from baseband context toward higher-privileged components of the device

How the Vulnerability Works — Defender's View

Improper authorization in a baseband context typically manifests in one of two exploitation paths, and defenders should plan for both:

1. Network-side trigger: The modem parses signaling and data frames from the cellular network. A malformed or specially crafted message — delivered over the air via a malicious or rogue base station (IMSI catcher / stingray-class device), or in some cases via SMS/RCS or paging channels — reaches the vulnerable code path. The logic error means a permission check that should reject the operation is skipped or evaluated incorrectly, granting the attacker an execution or privilege context the modem was designed to deny.

2. Local trigger: A malicious application with limited permissions (or a compromised app) sends crafted commands to the modem interface — through the Radio Interface Layer (RIL), AT command surface, or vendor IPC — and the flawed authorization check allows the request to execute with elevated privilege, breaking the sandbox boundary between the app processor and baseband.

The privilege escalation outcome is the key detail in the summary: the attacker starts in a constrained context and ends with elevated rights. From there, realistic post-exploitation goals include call/SMS interception, persistent device compromise, credential theft from the application layer, or use of the device as a pivot point into enterprise resources it can reach (email, VPN, MDM-enrolled SaaS).

Exploitation Status

• CISA KEV: Listed 2026-09-16 — confirmed active exploitation in the wild
• CVSS: Not published in the KEV entry summary; do not wait for a score. KEV inclusion is the prioritization signal that matters — CISA only adds vulnerabilities with reliable evidence of real-world exploitation.
• Patch status: Google addresses Pixel modem vulnerabilities through the monthly Pixel security bulletin and over-the-air (OTA) update channel. Check the current month's bulletin for the CVE listing and the corresponding security patch level (SPL) string.

Why Baseband Bugs Demand Different Thinking

Three operational realities make this class of vulnerability worse than a typical Android app-layer CVE:

• No visibility: Your EDR almost certainly has no sensor in the baseband RTOS. You will not see the exploit. You will only see downstream effects — if you're looking.
• Physical proximity attack surface: If exploitation involves rogue base stations, the threat model includes targeted attacks against specific individuals (executives, journalists, government personnel) in specific locations. This is a nation-state-grade technique, and KEV-listed mobile bugs are frequently tied to commercial spyware vendors and state actors.
• Carrier and OTA lag: Unlocked Pixels get updates fastest; carrier-locked devices can lag days to weeks. Your patch SLA must account for the slowest device in the fleet, not the fastest.

Detection & Response

Candid guidance first: there is no Sigma rule that detects a baseband logic-error exploit firing inside a Qualcomm/Samsung modem RTOS. Anyone who sells you one is selling noise. What you can detect is (a) devices running vulnerable firmware in your fleet, (b) post-exploitation symptoms on the Android application layer, and (c) forensic artifacts of compromise during triage per CISA's Forensics Triage Requirements. That's what the content below targets.

Sigma Rules

These rules target the Android application-layer telemetry that your MDM, mobile threat defense (MTD), or log pipeline (logcat/syslog forwarding) can actually observe — modem crash loops consistent with exploitation attempts, and suspicious privilege transitions from radio-adjacent processes.

---
title: Android Radio Interface Layer Crash Loop - Possible Baseband Exploitation Attempt
description: Detects repeated crashes of the Android Radio Interface Layer (rild) or modem-related processes, which can indicate attempted or successful exploitation of baseband vulnerabilities such as CVE-2026-58704. A single crash is common; a crash loop on a single device is not.
author: Security Arsenal
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-58704
  - https://source.android.com/docs/security/bulletin/pixel
id: 8f2c1a47-6b3e-4d9a-b1c5-7e0f2a9d4c31
status: experimental
date: 2026/09/16
logsource:
  product: android
  service: logcat
detection:
  selection:
    Message|contains:
      - 'rild'
      - 'radio'
      - 'modem'
      - 'baseband'
      - 'android.hardware.radio'
    Message|contains:
      - 'Fatal signal'
      - 'SIGSEGV'
      - 'SIGABRT'
      - 'tombstone'
      - 'process has died'
      - 'watchdog'
  condition: selection
falsepositives:
  - Poor cellular coverage causing legitimate modem resets
  - Beta/developer preview builds with unstable radio firmware
level: medium
---
title: Android Privileged Shell or Process Spawned From Radio Context
description: Detects shell or unexpected child processes spawned by radio/baseband-adjacent system users on Android. Post-exploitation of a baseband privilege escalation such as CVE-2026-58704 may surface on the application processor as execution under the radio or system UID.
author: Security Arsenal
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-58704
id: 3b7e5f91-2c48-4a6d-9e1b-5d0c8f3a7b62
status: experimental
date: 2026/09/16
logsource:
  product: android
  service: logcat
detection:
  selection:
    Message|contains:
      - 'uid=1001'
      - 'uid=1000'
      - 'radio'
    Message|contains:
      - 'exec'
      - 'sh '
      - '/system/bin/sh'
      - 'start command'
      - 'am start'
      - 'chmod'
      - 'setenforce'
  condition: selection
falsepositives:
  - OEM/carrier diagnostic tooling
  - Enterprise MDM agents with elevated privileges
level: high
---
title: Android SELinux Enforcement Disabled or Audit Denials From Radio Domain
description: Detects indicators that SELinux has been set to permissive mode or repeated avc denials against the radio/modem domain on Android devices, a common post-exploitation step after privilege escalation flaws like CVE-2026-58704.
author: Security Arsenal
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-58704
id: 5d1a9c34-8f62-4b7e-a3d9-1c4e6b8f2a05
status: experimental
date: 2026/09/16
logsource:
  product: android
  service: logcat
detection:
  selection_enforcing:
    Message|contains:
      - 'SELinux: Disabled'
      - 'setenforce 0'
      - 'SELinux status: permissive'
  selection_avc:
    Message|contains: 'avc: denied'
    Message|contains:
      - 'scontext=u:r:radio'
      - 'scontext=u:r:rild'
      - 'tcontext=u:object_r:modem'
  condition: 1 of selection_*
falsepositives:
  - Rooted devices enrolled by users (which should itself be a policy violation)
  - Engineering/debug builds in lab environments
level: high

Deployment note: These rules only work if Android telemetry reaches your SIEM. If you run an MTD (Lookout, Zimperium, Microsoft Defender for Endpoint on Android) or forward MDM compliance events, map those alert feeds into your Sigma pipeline. If you have zero Android telemetry today, that gap is itself the finding — fix ingestion before tuning rules.

KQL — Microsoft Sentinel / Defender

The highest-value hunt is asset hygiene: finding every Pixel in your estate that has not reached the security patch level containing the CVE-2026-58704 fix. If your devices are enrolled in Intune and synced to Defender, DeviceInfo exposes the OS build and patch data. The second query hunts for post-exploitation symptoms from Defender for Endpoint on Android telemetry.

// Hunt 1: Identify Google Pixel devices with outdated security patch levels
// Adjust the SPL threshold to the patch level that remediates CVE-2026-58704
// per the current Google Pixel security bulletin.
DeviceInfo
| where Timestamp > ago(7d)
| where Manufacturer =~ "Google" or Model startswith "Pixel"
| summarize arg_max(Timestamp, *) by DeviceId
| extend PatchDate = todatetime(extract(@"(\d{4}-\d{2}-\d{2})", 1, tostring(OSBuild)))
| extend IsOutdated = OSBuild !contains "2026-09"
| where IsOutdated
| project DeviceName, Model, OSVersion, OSBuild, OSPlatform, LastSeen = Timestamp, LoggedOnUsers
| sort by LastSeen desc

// Hunt 2: Post-exploitation symptoms on Android devices in Defender for Endpoint
// Unexpected process execution or network connections from system-context apps
DeviceProcessEvents
| where Timestamp > ago(14d)
| where DeviceName has_any (DeviceInfo
    | where Manufacturer =~ "Google"
    | distinct DeviceName)
| where InitiatingProcessAccountName in~ ("system", "radio", "root")
| where FileName !in~ ("system_server", "surfaceflinger", "audioserver", "cameraserver")
| summarize ProcessCount = count(),
            DistinctCommands = dcount(ProcessCommandLine),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
    by DeviceName, FileName, InitiatingProcessAccountName, ProcessCommandLine
| order by DistinctCommands desc

// Hunt 3: Devices with anomalous network connections shortly after radio instability
// Pivot: devices talking to rare external destinations within a window of modem resets
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where DeviceName has_any (DeviceInfo
    | where Manufacturer =~ "Google"
    | distinct DeviceName)
| where ActionType == "ConnectionSuccess"
| summarize Connections = count(),
            UniqueDestinations = dcount(RemoteIP)
    by DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName
| where UniqueDestinations > 50 or InitiatingProcessFileName has_any ("sh", "busybox", "su")
| order by Connections desc

Tune Hunt 2's exclusion list against your MDM agent's legitimate process names before broad deployment — enterprise MDM tooling legitimately runs as system on managed devices and will be your dominant false positive source.

Velociraptor VQL

Velociraptor doesn't deploy to Android, but it earns its keep here in two places: (1) enumerating Android devices physically connected to managed Windows endpoints (useful for identifying unmanaged Pixels touching your environment via USB/ADB), and (2) hunting for forensic acquisition or flashing tooling that indicates someone has been interacting with device firmware — relevant when investigating whether a device in your fleet was tampered with or sideloaded.

-- Hunt: Identify Android/Google Pixel devices connected via USB to Windows endpoints
-- and detect ADB/fastboot activity that may indicate firmware interaction.
-- Deploy as a hunt across your Windows fleet.

SELECT * FROM foreach(
  row={
    SELECT KeyName, KeyValues
    FROM read_reg_key(
      globs='HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_18D1*\**',
      accessor='registry'
    )
  },
  query={
    SELECT KeyName,
           get(member='FriendlyName') AS DeviceName,
           get(member='Mfg') AS Manufacturer,
           get(member='Service') AS DriverService
    FROM read_reg_key(
      globs=KeyName,
      accessor='registry'
    )
})

-- Hunt: ADB / fastboot execution on Windows endpoints (firmware tooling)
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)adb|fastboot'
   OR CommandLine =~ '(?i)fastboot\s+flash|adb\s+(sideload|shell\s+su|push.*boot)'

-- Hunt: USB Android device network interfaces (tethering / RNDIS from mobile devices)
SELECT Pid, Name, LocalAddress, LocalPort, RemoteAddress, RemotePort, Status
FROM netstat()
WHERE LocalAddress =~ '^172\\.(1[6-9]|2[0-9]|3[0-1])\\.'
   OR LocalAddress =~ '^192\\.168\\.42\\.'

Remediation Script — Fleet Patch Verification via ADB

For teams managing Pixel devices through ADB-capable tooling, lab benches, or during DFIR triage, this Bash script verifies the security patch level and build fingerprint of connected devices and flags any device below the remediation SPL. Adjust REQUIRED_SPL to the patch string from the current Pixel security bulletin.

#!/usr/bin/env bash
# CVE-2026-58704 - Pixel fleet security patch level verification
# Requires: adb in PATH, devices authorized for USB debugging (or run in MDM-adjacent tooling)
# Set REQUIRED_SPL to the security patch level that remediates CVE-2026-58704
# per the current Google Pixel security bulletin (YYYY-MM-DD format).

REQUIRED_SPL="2026-09-05"
REPORT="pixel_cve_2026_58704_report_$(date +%Y%m%d).csv"

echo "serial,model,build_fingerprint,security_patch,spl_status" > "$REPORT"

if ! command -v adb &>/dev/null; then
  echo "[!] adb not found. Install Android platform-tools first." >&2
  exit 1
fi

adb start-server &>/dev/null

SERIALS=$(adb devices | awk 'NR>1 && $2=="device" {print $1}')

if [[ -z "$SERIALS" ]]; then
  echo "[!] No authorized devices detected. Check USB connections and debugging authorization." >&2
  exit 1
fi

for SERIAL in $SERIALS; do
  MODEL=$(adb -s "$SERIAL" shell getprop ro.product.model 2>/dev/null | tr -d '\r')
  FINGERPRINT=$(adb -s "$SERIAL" shell getprop ro.build.fingerprint 2>/dev/null | tr -d '\r')
  SPL=$(adb -s "$SERIAL" shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')

  if [[ -z "$SPL" ]]; then
    STATUS="UNKNOWN - could not read SPL"
  elif [[ "$SPL" < "$REQUIRED_SPL" ]]; then
    STATUS="VULNERABLE - below required SPL $REQUIRED_SPL"
  else
    STATUS="PATCHED"
  fi

  echo "$SERIAL,$MODEL,$FINGERPRINT,$SPL,$STATUS" | tee -a "$REPORT"
done

echo
echo "[*] Report written to $REPORT"
echo "[*] Any device marked VULNERABLE must be updated via Settings > System > System update"
echo "    or sideloaded from https://developers.google.com/android/images per Google guidance."

# Optional: capture modem/radio logs for forensic triage per CISA Forensics Triage Requirements
# for SERIAL in $SERIALS; do
#   adb -s "$SERIAL" bugreport "bugreport_${SERIAL}_$(date +%Y%m%d%H%M).zip"
#   adb -s "$SERIAL" logcat -b radio -d > "radio_log_${SERIAL}.txt"
# done

Run the commented bugreport capture on any device flagged for investigation — per CISA's Forensics Triage Requirements referenced in the KEV action, preserve evidence before wiping or reimaging a potentially exploited device.

Remediation

1. Patch immediately. Apply the current monthly Pixel security update containing the CVE-2026-58704 fix via Settings → System → System update, or sideload the full OTA/factory image from Google's factory image repository. Verify the device's security patch level matches or exceeds the SPL listed in the current Google Pixel Security Bulletin. Carrier-locked devices must be tracked separately — their update cadence lags unlocked devices.

2. Meet the BOD 26-04 deadline. Federal civilian agencies must remediate by the due date on the KEV catalog entry and comply with the referenced Forensics Triage Requirements. Private-sector organizations should adopt the same deadline internally — KEV due dates are a defensible, externally validated SLA for your vulnerability management program.

3. Reduce the radio attack surface on unpatched devices. Until the patch lands: disable 2G connectivity (Settings → Network & Internet → SIMs → Allow 2G → Off) to eliminate the weakest cellular generation as a rogue-base-station vector; disable Wi-Fi calling if operationally acceptable in high-risk scenarios; and avoid untrusted cellular environments for high-value users.

4. Enable Lockdown Mode and verify device integrity. Require Lockdown Mode (disables biometric unlock and notifications on lock screen) for sensitive users, confirm Google Play Protect and verified boot are intact, and verify devices are not rooted or running developer/unlocked bootloaders — ro.boot.flash.locked and ro.boot.verifiedbootstate should report locked/green.

5. Restrict high-risk exposure. For executive, government, or other targeted populations, evaluate whether Pixel devices with unpatched modems should be temporarily replaced, and whether those users should operate on devices with current SPLs only. If mitigations cannot be applied, the KEV directive is explicit: discontinue use of the product for affected use cases.

6. Preserve forensic evidence before remediation on suspected devices. Pull a bug report and radio log via ADB before factory reset or reflash. Document IMEI, build fingerprint, SPL, and timeline. A KEV-listed mobile exploit against one of your devices is an incident, not a patch ticket — treat it with IR discipline, because the question "was this device already compromised?" cannot be answered after you've wiped it.

7. Close the telemetry gap. If this KEV entry caught you without Android device inventory, patch-level visibility, or MTD alerting, that is the durable lesson. Mobile devices hold corporate credentials, MFA sessions, and email — they are endpoints, and they belong in your asset inventory, your SIEM, and your patch SLAs.

Baseband exploitation is the domain of well-resourced adversaries, and CISA does not add vulnerabilities to the KEV on speculation. Treat CVE-2026-58704 as what it is: a confirmed, actively exploited path into devices your organization trusts with its most portable secrets.

Related Resources

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