Security researchers at SSD Secure Disclosure have published the second stage of a two-part exploit chain that achieves full Android kernel access on devices running Unisoc modem firmware — delivered through an incoming VoLTE video call. The advisory, published August 17, 2026, builds on an unauthenticated code execution vulnerability in the Unisoc modem stack that SSD first disclosed in March 2026. The critical fact for defenders: Unisoc has not released a fix.
This is a baseband-side attack path, which makes it categorically worse than a typical app-level vulnerability. The modem processor sits below the Android OS, outside the visibility of endpoint security agents, and — as this chain demonstrates — can be leveraged as a pivot point into the application processor's kernel. The attack surface is reachable over the mobile network: an attacker who can deliver SIP/RTP signaling to the target device (via a rogue base station, compromised carrier infrastructure, or in some configurations simply by placing a malicious video call) can trigger the initial modem compromise without user authentication and, depending on call-answering behavior, with minimal to zero user interaction.
Unisoc (formerly Spreadtrum) chipsets power a large share of budget and mid-range Android devices sold across Africa, Asia, Latin America, and emerging markets — including devices from Motorola, Nokia/HMD, Realme, Itel, Tecno, and dozens of regional OEMs. If your organization supports BYOD, operates in those regions, or has field staff carrying low-cost Android handsets, this is your problem even if your fleet standard is Samsung or Pixel.
This post breaks down the chain from a defender's perspective, gives you hunt logic for the post-exploitation phase (the only phase where defenders have telemetry), and lays out concrete mitigations while we wait for a vendor patch that may never arrive.
Technical Analysis
Affected Products and Platforms
- Component: Unisoc modem/baseband firmware (the cellular baseband stack running on Unisoc SoCs)
- Trigger vector: VoLTE (Voice over LTE) video call signaling — specifically the video telephony media path handled by the modem firmware
- Affected devices: Android smartphones and tablets built on Unisoc SoCs. This spans a broad range of budget-tier devices from global and regional OEMs; there is no authoritative affected-model list from the vendor, which is itself a problem
- Patch status: No fix available from Unisoc as of the advisory date (August 17, 2026). The first-stage issue was disclosed in March 2026 — five months of exposure with no vendor remediation
No CVE identifier was published in the SSD disclosure summary or the accompanying coverage. Track the SSD Secure Disclosure advisory directly for updates and any future CVE assignment.
How the Chain Works (Defender's View)
Based on the published disclosure structure, the attack operates in two stages:
Stage 1 — Unauthenticated remote code execution in the modem (disclosed March 2026). A memory corruption vulnerability in the Unisoc modem firmware's handling of VoLTE media streams allows an attacker to execute code on the baseband processor by sending crafted content during a VoLTE video call. No authentication, no app installation, no physical access. The prerequisite is the ability to establish or inject into a video call session with the target — achievable through malicious call origination, IMS/VoLTE network access, or rogue cellular infrastructure (IMSI catcher / fake base station scenarios).
Stage 2 — Baseband-to-application-processor escalation to full kernel access (disclosed August 2026). Code execution on the modem is chained into the Android kernel running on the application processor. Historically, baseband-to-AP escalation exploits weaknesses in the shared-memory interface, IPC mailbox drivers, or vendor kernel drivers that trust modem-supplied data without adequate validation. The result: the attacker crosses the hardware trust boundary and obtains kernel-level control of the Android OS itself.
At kernel level, the entire Android security model is void: SELinux can be disabled or policy-neutralized, the keystore can be abused, full disk encryption keys in memory can be extracted, microphone/camera/GPS can be accessed without indicators, and persistence can be established below the OS. This is surveillance-grade capability — the same class of access sold by commercial spyware vendors.
Exploitation Status
- Public disclosure: Yes — SSD Secure Disclosure published both stages (March 2026 and August 17, 2026)
- Patch availability: None from Unisoc as of publication
- Confirmed in-the-wild exploitation: Not publicly confirmed at the time of the advisory — but treat this as an elevated-risk assumption, not a comfort. Zero-click baseband chains are disproportionately used by targeted-surveillance actors precisely because they leave almost no forensic trace. Absence of evidence is not absence of exploitation
- CISA KEV: Not listed at time of writing; monitor the KEV catalog for additions
The realistic threat model: nation-state and commercial surveillance actors targeting journalists, activists, executives, government personnel, and field staff in regions where Unisoc-based devices dominate. Mass opportunistic exploitation is less likely (delivery requires telephony-side positioning), but targeted exploitation is highly plausible.
Detection & Response
Let me be blunt about the telemetry problem first: you will not detect the baseband compromise itself. The modem crash or code execution happens on a separate processor running closed firmware. Your detectable surface begins at Stage 2 — when the attacker lands in the Android kernel and starts operating on the application processor. Focus your hunting on post-exploitation artifacts: anomalous kernel behavior, unexpected privileged processes, telephony-adjacent processes spawning children, and persistence artifacts.
The rules below assume you have Android fleet visibility via Microsoft Defender for Endpoint on Android (which surfaces process/network telemetry into Sentinel) or an EDR/MDM that forwards Android audit logs as Syslog/CEF. If you have neither, skip to the Remediation section — mitigation is your only control.
Sigma Rules
---
title: Unexpected Child Process Spawned by Android Radio or Telephony Components
id: 3b7e2a91-4c5d-4f8a-9b21-7e6d5c4a3b21
status: experimental
description: Detects shell or binary execution parented by Android baseband/telephony daemons (rild, vendor radio services). Baseband exploitation chains that escalate to the application processor frequently pivot through or near radio-adjacent processes before establishing kernel-level persistence. Legitimate radio daemons do not spawn interactive shells or arbitrary binaries.
references:
- https://thehackernews.com/2026/08/unisoc-volte-video-call-exploit-chain.html
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/18
tags:
- attack.execution
- attack.t1059
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|contains:
- '/vendor/bin/hw/rild'
- '/system/bin/rild'
- '/vendor/bin/hw/android.hardware.radio'
- 'vendor.qti.hardware.radio'
selection_child:
Image|contains:
- '/system/bin/sh'
- '/vendor/bin/sh'
- '/data/local/tmp/'
- '/system/bin/su'
- '/magisk'
- 'busybox'
condition: selection_parent and selection_child
falsepositives:
- OEM diagnostic tooling executed under radio contexts (rare; validate against known vendor package signatures)
level: high
---
title: Execution From World-Writable Android Data Directories by Privileged Context
id: 9c1d4f72-8a3b-4e6f-a2c1-5d8e7f6a9b0c
status: experimental
description: Detects execution of binaries staged in /data/local/tmp or /sdcard by root or system contexts. Stage-2 payloads and privilege-escalation tooling in Android exploit chains are commonly dropped to world-writable staging paths before execution. Post-kernel-compromise operators frequently reuse these paths for tooling.
references:
- https://thehackernews.com/2026/08/unisoc-volte-video-call-exploit-chain.html
- https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/08/18
tags:
- attack.command_and_control
- attack.t1105
logsource:
category: process_creation
product: linux
detection:
selection_path:
Image|startswith:
- '/data/local/tmp/'
- '/sdcard/Download/'
- '/storage/emulated/0/Download/'
selection_user:
User|contains:
- 'root'
- 'system'
- 'radio'
condition: selection_path and selection_user
falsepositives:
- Developer devices with ADB-installed test tooling (restrict scope to production fleet)
level: high
---
title: Android Kernel Tampering Indicators - SELinux Enforcement Change or Module Load
id: 5f2a8c43-1d9e-4b7a-8c3f-2e4d6a1b7c90
status: experimental
description: Detects commands that disable SELinux enforcement or load kernel modules on Android devices. An attacker with kernel access via a baseband chain will commonly neutralize SELinux (setenforce 0 or direct policy manipulation) and may load kernel modules for persistence or capability expansion. Neither occurs in normal device operation.
references:
- https://thehackernews.com/2026/08/unisoc-volte-video-call-exploit-chain.html
- https://attack.mitre.org/techniques/T1562/
author: Security Arsenal
date: 2026/08/18
tags:
- attack.defense_evasion
- attack.t1562.001
logsource:
category: process_creation
product: linux
detection:
selection_cmd:
CommandLine|contains:
- 'setenforce 0'
- 'setenforce permissive'
- 'insmod '
- 'modprobe '
- '/proc/sys/kernel/'
- 'sepolicy-inject'
condition: selection_cmd
falsepositives:
- Rooted developer devices; enterprise fleet devices should have zero legitimate hits
level: critical
KQL (Microsoft Sentinel / Defender)
Microsoft Defender for Endpoint supports Android and surfaces process and network events into DeviceProcessEvents and DeviceNetworkEvents. The following query hunts for the post-exploitation behaviors described above — radio-adjacent process trees, staging-directory execution, and SELinux tampering — across your enrolled Android fleet. Scope the time window and tune the device filter to your Unisoc-device inventory (join against your MDM hardware inventory where available).
// Hunt: Android baseband exploit post-exploitation behaviors (Unisoc VoLTE chain)
// Covers: radio/telephony-spawned shells, staging-dir execution by privileged users, SELinux tampering
let Lookback = 14d;
let RadioDaemons = dynamic(["rild", "android.hardware.radio", "imsdatadaemon", "qcrild"]);
let SuspiciousPaths = dynamic(["/data/local/tmp/", "/sdcard/Download/", "/storage/emulated/0/"]);
union
(
DeviceProcessEvents
| where TimeGenerated > Lookback
| where InitiatingProcessFileName has_any (RadioDaemons)
or InitiatingProcessCommandLine has_any (RadioDaemons)
| where FileName in~ ("sh", "su", "busybox", "curl", "wget", "nc")
or FolderPath has_any (SuspiciousPaths)
| project TimeGenerated, DeviceName, FileName, FolderPath, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName, SHA256
),
(
DeviceProcessEvents
| where TimeGenerated > Lookback
| where ProcessCommandLine has_any ("setenforce 0", "setenforce permissive", "insmod", "modprobe", "sepolicy-inject")
| project TimeGenerated, DeviceName, FileName, FolderPath, ProcessCommandLine,
InitiatingProcessFileName, AccountName, SHA256
)
| order by TimeGenerated desc
For organizations forwarding Android syslog/auditd via CEF into Sentinel, hunt the modem crash artifacts that may precede Stage 2 — repeated baseband resets around VoLTE call events are a weak but worthwhile signal:
// Hunt: Repeated modem/baseband resets correlated with telephony events (Syslog/CEF ingestion)
// High crash frequency of radio daemons on a single device may indicate exploitation attempts against the modem stack
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where DeviceVendor =~ "Android" or SourceHostName in (dynamic(["android"]))
| where Message has_any ("rild", "modem", "baseband", "radio" )
and Message has_any ("crash", "reset", "fatal", "SIGSEGV", "SIGABRT", "tombstone")
| summarize CrashCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by SourceHostName, DeviceCustomString1
| where CrashCount >= 3
| order by CrashCount desc
Velociraptor VQL
Velociraptor can be deployed on rooted/enterprise Android builds or Linux-based device management nodes. This artifact hunts the endpoint-side artifacts of a Stage 2 landing: privileged processes running from staging paths, radio-daemons with unexpected children, and unauthorized su/module artifacts.
-- Hunt: Android post-exploitation artifacts from baseband-to-kernel exploit chains
-- Look for: staging-dir execution, radio-spawned shells, su/module presence, suspicious listeners
LET processes = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '/data/local/tmp/|/sdcard/Download/|setenforce|insmod|modprobe|sepolicy'
OR (Name =~ 'sh|su|busybox|nc' AND Username =~ 'root|system|radio')
LET staging_files = SELECT FullPath, Size, Mtime, Mode
FROM glob(globs=['/data/local/tmp/*', '/sdcard/Download/*.bin', '/data/local/tmp/*.ko'])
WHERE Mtime > now() - 14 * 24 * 3600
LET su_artifacts = SELECT FullPath, Size, Mtime
FROM glob(globs=['/system/bin/su', '/system/xbin/su', '/vendor/bin/su', '/sbin/su', '/system/app/*magisk*', '/data/adb/magisk/**'])
SELECT * FROM processes
UNION ALL
SELECT NULL AS Pid, NULL AS Ppid, 'STAGING_FILE' AS Name, FullPath AS CommandLine,
'' AS Exe, '' AS Username, Mtime AS CreateTime FROM staging_files
UNION ALL
SELECT NULL AS Pid, NULL AS Ppid, 'SU_ARTIFACT' AS Name, FullPath AS CommandLine,
'' AS Exe, '' AS Username, Mtime AS CreateTime FROM su_artifacts
Verification and Hardening Script
The following Bash script runs over ADB against connected Android devices to (a) fingerprint the SoC vendor so you can inventory Unisoc exposure, (b) pull patch and baseband versions, (c) check VoLTE provisioning state, and (d) collect integrity indicators. Run it in a loop across your managed/forensically acquired devices. ADB access requires the device to be developer-enabled or enterprise-provisioned — this is a fleet-assessment and triage tool, not a remote scanner.
#!/bin/bash
# unisoc_exposure_triage.sh — Inventory Unisoc SoC exposure and collect baseband integrity indicators
# Usage: ./unisoc_exposure_triage.sh (run with target device connected via ADB)
OUT="unisoc_triage_$(date +%Y%m%d_%H%M%S).log"
exec > >(tee -a "$OUT") 2>&1
echo "=== Unisoc Exposure & Baseband Triage ==="
echo "Date: $(date -u)"
echo "--- Device Identity ---"
adb shell getprop ro.product.manufacturer
adb shell getprop ro.product.model
adb shell getprop ro.serialno
echo "--- SoC / Hardware Platform (look for 'unisoc', 'sprd', 'ums', 'sc' prefixes) ---"
adb shell getprop ro.hardware
adb shell getprop ro.board.platform
adb shell getprop ro.vendor.product.cpu.abilist
adb shell cat /proc/cpuinfo | grep -i -E "hardware|model name" | head -5
echo "--- Security Patch & Build Level ---"
adb shell getprop ro.build.version.security_patch
adb shell getprop ro.build.fingerprint
echo "--- Baseband / Modem Version ---"
adb shell getprop gsm.version.baseband
adb shell getprop ro.vendor.build.version.incremental
echo "--- VoLTE / IMS Provisioning State ---"
# Carrier config: VoLTE enabled = 1 means attack surface is exposed
adb shell dumpsys telephony.registry 2>/dev/null | grep -i -E "volte|ims" | head -10
adb shell cmd phone 2>/dev/null | grep -i volte
adb shell settings get global volte_vt_enabled 2>/dev/null
echo "--- SELinux Status (anything but Enforcing is a red flag) ---"
adb shell getenforce
echo "--- Unauthorized su / Root Artifacts ---"
adb shell "ls -la /system/bin/su /system/xbin/su /vendor/bin/su /sbin/su 2>/dev/null"
adb shell "pm list packages 2>/dev/null | grep -i -E 'magisk|supersu|superuser'"
echo "--- Recently Modified Staging Directories (last 14 days) ---"
adb shell "find /data/local/tmp /sdcard/Download -type f -mtime -14 2>/dev/null"
echo "--- Loaded Kernel Modules ---"
adb shell "lsmod 2>/dev/null || cat /proc/modules 2>/dev/null"
echo "--- Modem/Radio Crash Tombstones ---"
adb shell "ls -la /data/tombstones/ 2>/dev/null | head -20"
echo ""
echo "Triage complete. Output saved to $OUT"
echo "ACTION: If ro.hardware/ro.board.platform contains unisoc/sprd/ums/sc AND security patch < 2026-08,"
echo "flag device as EXPOSED to the SSD VoLTE chain and apply mitigations (disable VoLTE video, isolate from sensitive use)."
Remediation
There is no patch. That changes the remediation conversation from "deploy update" to "reduce attack surface and reassess device risk." Prioritize in this order:
1. Inventory your Unisoc exposure immediately. Most organizations have no idea which of their Android devices run Unisoc silicon. Pull SoC data from your MDM (ro.hardware, ro.board.platform — Unisoc devices typically report sprd, ums, sc9863, sc7731, T610, T760, etc.). Every Unisoc device is in-scope until Unisoc publishes an affected-firmware list.
2. Disable VoLTE video calling on exposed devices where operationally feasible. The trigger vector is the VoLTE video media path. Disabling video telephony (VT) while retaining voice VoLTE removes the exposed parser surface for this specific chain. This can be enforced via carrier settings, OEMConfig/MDM policies on supported devices, or by toggling off video calling in the dialer settings for unmanaged BYOD (with user guidance). Confirm the disable actually sticks — carrier provisioning can re-enable it.
3. Segment high-risk users away from Unisoc devices. Executives, journalists, government personnel, incident responders, and anyone in your organization plausibly targeted by surveillance-grade actors should not carry Unisoc-based handsets, full stop. Issue Qualcomm/MediaTek/Pixel alternatives. The cost of a mid-range Pixel is trivial against the cost of a kernel-level compromise of an executive's phone.
4. Enforce Android Enterprise / MDM controls that shrink post-exploitation value: verify SELinux is Enforcing across the fleet, block unknown-source installs, disable ADB in production, enforce strong disk encryption and lock-screen policy, and enable Google Play Protect plus an EDR with Android support (e.g., Microsoft Defender for Endpoint) so the hunt queries above have telemetry to run against.
5. Treat repeat modem crashes as a triage trigger. A device showing repeated radio daemon/baseband tombstones, unexplained modem resets, or sudden battery/thermal anomalies during idle periods warrants forensic acquisition. Pull tombstones, radio logs, and IMS registration history. Preserve the device — baseband artifacts are volatile.
6. Pressure the supply chain. Open tickets with your device OEMs referencing the SSD Secure Disclosure advisories (March 2026 stage 1, August 17, 2026 stage 2). OEMs shipping Unisoc silicon have leverage you don't. Enterprise procurement should add baseband-patch SLA language to device contracts going forward — five months without vendor acknowledgment is an unacceptable security posture for a chipset in millions of devices.
7. Monitor for updates. Track the SSD Secure Disclosure advisory page, Unisoc security bulletins (if published), and the CISA KEV catalog. If a firmware fix ships, verify actual deployment — Android baseband patches travel through OEM and carrier channels and routinely lag months behind availability.
The strategic lesson: baseband security remains the soft underbelly of mobile device security, and the defense ecosystem's visibility there is near zero. Until modem firmware gets the same patch discipline and transparency as the OS layer, your controls are exposure management, device selection, and aggressive post-compromise hunting. Build all three now.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.