Researchers have disclosed a serious attack chain affecting Android devices built on Unisoc (formerly Spreadtrum) cellular modems. By combining two separate vulnerabilities in the modem's handling of video call traffic, an attacker can achieve full device compromise with a startlingly low bar for user interaction: deliver malicious content and get the victim to answer an incoming video call. No link clicks, no sideloaded apps, no phishing pages — the attack rides in through the legitimate telephony stack that every user implicitly trusts.
This is the class of vulnerability that keeps mobile defenders up at night. Baseband and modem flaws sit beneath the operating system, below the reach of most endpoint security tooling, and they process attacker-influenced data from the cellular network itself. When that processing can be chained into code execution that pivots into the application processor, the entire device — and every corporate credential, MFA token, and messaging app on it — is exposed.
Unisoc chipsets are not a niche concern. They ship in a large volume of budget and mid-range Android devices across Asia, Africa, Latin America, and increasingly in low-cost handsets and IoT hardware sold globally, including devices brought into enterprises as BYOD endpoints. If your mobile fleet includes affordable Android devices, assume some percentage of them are running Unisoc silicon until you prove otherwise.
Technical Analysis
Affected Component
The vulnerability chain targets the Unisoc modem firmware — the baseband stack responsible for handling cellular signaling, including IMS (IP Multimedia Subsystem) services that carry VoLTE and ViLTE (Video over LTE) traffic. The modem parses incoming video call signaling and media before the Android OS ever sees the data.
Attack Chain
From a defender's perspective, the exploitation flow breaks down as follows:
- Delivery: The attacker initiates a video call to the victim's number. Malicious content embedded in the call's signaling or media stream reaches the modem's parser automatically — this is the delivery vehicle for the malicious code.
- First flaw — modem compromise: The malicious payload triggers the first vulnerability in the modem firmware, giving the attacker code execution within the baseband processor context.
- Second flaw — privilege escalation: The second vulnerability is chained to escape the modem's isolation and gain control over the Android device itself (the application processor where user data, apps, and credentials live).
- Trigger condition: The victim answers the incoming video call. This is the only user interaction required — no exploit delivery via browser, MMS gallery, or app install is involved.
This two-flaw chaining pattern is characteristic of how real-world baseband attacks work: one bug to get a foothold in the constrained modem environment, a second to cross the trust boundary into the main OS. Defenders should treat the modem-to-AP boundary as a critical security perimeter that this chain demonstrates can be crossed.
Why Detection Is Hard
Baseband exploitation leaves few conventional artifacts:
- No traditional EDR coverage: Mobile EDR agents run in the Android OS, not in the modem. Code executing in the baseband is invisible to them.
- Legitimate channel abuse: The attack arrives over normal telephony signaling. Network firewalls and web proxies never see it — it traverses the carrier's IMS core.
- Volatile evidence: Modem crashes may present to the user as a dropped call or a brief loss of signal, easily dismissed as network flakiness.
The observable residue tends to be behavioral and indirect: modem or radio interface crashes correlated with incoming calls, telephony service instability, SELinux denials as the exploit attempts to cross process boundaries, and — after successful compromise — anomalous activity on the device itself (unexpected processes, persistence artifacts, abnormal outbound connections).
Exploitation Status
The research demonstrates a viable, working exploit chain. At the time of writing, no specific CVE identifiers have been published in the reporting for these flaws, and there is no confirmed public evidence of mass in-the-wild exploitation. However, the barrier to weaponization for a capable adversary is low: the delivery mechanism is a phone call, target selection requires only a phone number, and Unisoc's install base provides a large pool of unpatched devices. Treat this as pre-weaponization intelligence and act accordingly — patching and mitigation should not wait for confirmed exploitation.
Detection & Response
Detection for baseband attacks is about catching the crash-and-escalation residue on the Android side and aggressively inventorying your exposure. The following detections are designed to be high-signal, not exhaustive.
Sigma Rules
These rules assume Android logcat telemetry is being collected (via MDM log collection, Android Enterprise, or a mobile EDR that forwards system logs) into a SIEM that applies Sigma. They target the crash-and-boundary-crossing behavior the exploit chain produces.
---
title: Android Radio/Baseband Process Crash Following Telephony Activity
id: 3f8c2a71-9b4e-4d1a-a7c2-6e5f0b3d8a91
status: experimental
description: Detects crash signals (SIGSEGV/SIGABRT) in Android radio interface or telephony processes, a potential indicator of baseband exploitation attempts triggered by malicious call signaling such as crafted video calls.
references:
- https://www.darkreading.com/mobile-security/video-call-exploit-chains-two-flaws-unisoc-modems
author: Security Arsenal
date: 2026/03/10
tags:
- attack.initial_access
- attack.t1656
logsource:
product: android
service: logcat
detection:
selection_process:
Message|contains:
- 'rild'
- 'com.android.phone'
- 'radio'
- 'modem'
selection_crash:
Message|contains:
- 'SIGSEGV'
- 'SIGABRT'
- 'signal 11'
- 'Fatal signal'
- 'tombstone'
condition: selection_process and selection_crash
falsepositives:
- Genuine modem firmware instability on buggy builds; investigate recurrence correlated with incoming call events
level: high
---
title: Android SELinux Denial Involving Radio or Telephony Domain
id: 7c1d4e92-5a3b-48f6-b2d9-1e8a0c6f4b27
status: experimental
description: Detects SELinux avc denials where the radio, rild, or telephony process context attempts actions outside its normal policy domain, consistent with an exploit attempting to escape the baseband/telephony sandbox into the main OS.
references:
- https://www.darkreading.com/mobile-security/video-call-exploit-chains-two-flaws-unisoc-modems
author: Security Arsenal
date: 2026/03/10
tags:
- attack.privilege_escalation
- attack.t1068
logsource:
product: android
service: logcat
detection:
selection:
Message|contains:
- 'avc: denied'
selection_context:
Message|contains:
- 'scontext=u:r:radio'
- 'scontext=u:r:rild'
- 'comm="rild"'
- 'comm="com.android.phone"'
condition: selection and selection_context
falsepositives:
- OEM-specific policy gaps on heavily customized Android builds; baseline per device model
level: medium
KQL (Microsoft Sentinel / Defender)
Two queries: one to inventory your exposure (devices with outdated Android security patch levels, which is where unpatched modem firmware lives), and one to hunt crash telemetry indicative of exploitation attempts against ingested mobile logs.
// Inventory: Android devices with stale security patch levels
// Uses Defender for Endpoint device inventory; correlate stale patch levels with elevated mobile risk
DeviceInfo
| where OSPlatform startswith "Android"
| summarize arg_max(Timestamp, *) by DeviceId
| extend OSVersionInfo = tostring(OSVersionInfo)
| project DeviceName, Model, OSPlatform, OSVersionInfo, OSBuild, LastSeen
| order by OSVersionInfo asc
;
// Hunt: Android crash/denial telemetry forwarded via Syslog/CEF (MDM or mobile EDR ingestion)
// Looks for radio/telephony process crashes and SELinux denials tied to telephony contexts
union Syslog, CommonSecurityLog
| where TimeGenerated > ago(7d)
| extend Msg = coalesce(SyslogMessage, Message)
| where Msg has_any ("rild", "com.android.phone", "radio", "modem")
| where Msg has_any ("SIGSEGV", "SIGABRT", "Fatal signal", "tombstone", "avc: denied")
| summarize EventCount = count(), SampleMessages = take_any(Msg, 3) by Computer, bin(TimeGenerated, 1h)
| where EventCount >= 3 // crash loops, not one-off instability
| order by EventCount desc
Velociraptor VQL
Velociraptor does not run on Android handsets, but it is well-suited to auditing your MDM inventory exports on collection servers to identify exposed devices — an essential first step when modem firmware is the vulnerable layer. This artifact parses a standard MDM device export (CSV) for Android devices with outdated security patch levels or known Unisoc-based models.
-- Hunt MDM export for Android devices with stale security patch levels or Unisoc chipsets
-- Point glob() at your MDM/Intune device inventory export location
LET export_files = SELECT FullPath FROM glob(globs='C:\MDMExports\*device*inventory*.csv')
SELECT DeviceName, Model, OSVersion, SecurityPatchLevel, Chipset, LastSync
FROM foreach(row=export_files,
query={
SELECT * FROM parse_csv(filename=FullPath)
})
WHERE OSVersion =~ 'Android'
AND (
SecurityPatchLevel < '2025-01'
OR Chipset =~ '(?i)unisoc|spreadtrum|sc9863|t610|t760|ums'
OR Model =~ '(?i)unisoc'
)
ORDER BY SecurityPatchLevel ASC
Exposure Assessment & Mitigation Script
For devices you can reach via ADB (lab devices, kiosk fleets, enterprise-owned handsets), this script checks the Android security patch level and chipset, and — where permitted by policy — disables IMS video calling (ViLTE) and VoLTE as a temporary mitigation. Disabling IMS-based video calling removes the primary delivery vector described in this research, at the cost of falling back to legacy circuit-switched voice.
#!/bin/bash
# unisoc_exposure_check.sh — assess Android devices via ADB for modem exploit exposure
# Usage: ./unisoc_exposure_check.sh (device must be connected with USB debugging authorized)
echo "=== Device Exposure Assessment ==="
# Pull chipset / baseband hardware info
echo "[+] Chipset / hardware platform:"
adb shell getprop ro.hardware.chipname
adb shell getprop ro.board.platform
adb shell getprop ro.hardware
# Check baseband version (identify Unisoc/Spreadtrum modem firmware)
echo "[+] Baseband version:"
adb shell getprop gsm.version.baseband
# Check Android security patch level — the single most important exposure indicator
echo "[+] Security patch level:"
adb shell getprop ro.build.version.security_patch
# Check whether IMS / video calling (ViLTE) is provisioned and enabled
echo "[+] IMS video calling status:"
adb shell settings get global vt_enabled 2>/dev/null
adb shell dumpsys telephony.registry 2>/dev/null | grep -i -E "ims|video" | head -20
# MITIGATION (enterprise-owned devices only — verify MDM policy first):
# Disable video calling and VoLTE to remove the IMS delivery vector until patched
# adb shell settings put global vt_enabled 0
# adb shell settings put global volte_feature_disabled 1
# NOTE: On most modern devices, toggling IMS requires carrier provisioning or
# MDM control (e.g., Android Enterprise restrictions). Use your MDM to enforce
# "no video calling" policy where available rather than local settings.
echo "=== Assessment complete. Flag any Unisoc/Spreadtrum baseband with patch level older than the current Android bulletin. ==="
Remediation
Because no CVE identifiers or specific patch versions have been published in the initial reporting, remediation follows the standard baseband-flaw playbook — with urgency:
-
Inventory your mobile fleet for Unisoc silicon. You cannot patch what you haven't identified. Pull chipset and baseband data from your MDM (Intune, Workspace ONE, etc.) or via ADB for managed devices. Budget Android devices from brands using Unisoc SoCs (common in entry-level phones and tablets across emerging markets and value-tier channels) are the exposure surface.
-
Apply the latest Android Security Bulletin patches and OEM firmware updates immediately. Modem firmware fixes ship through device OEM updates, not directly from Unisoc. Prioritize any device whose security patch level lags the current bulletin. Monitor the Android Security Bulletins and your OEM advisories for the fix disclosure.
-
Disable IMS video calling (ViLTE) as a compensating control on unpatched devices. The attack's delivery vector is an incoming video call. Where MDM policy allows, disable video calling — and consider disabling VoLTE/IMS entirely on high-risk devices — until firmware updates are applied. Understand the trade-off: this degrades devices to legacy voice service.
-
Treat unrecognized incoming video calls as a threat vector. Update security awareness guidance: users on affected devices should not answer video calls from unknown numbers. This is imperfect advice — the exploit requires answering, and screening is the human control available until patches land.
-
Isolate high-risk devices from sensitive workloads. Unpatched Unisoc-based devices should not hold corporate email, MFA apps, or access to sensitive systems. Enforce this via conditional access policies that factor device patch level into trust decisions.
-
Plan device lifecycle replacement. Devices that no longer receive OEM security updates are permanently exposed to this and future baseband flaws. Budget Android devices frequently reach end-of-support quickly — build that into procurement decisions. Prefer vendors with committed multi-year security update guarantees.
-
Feed mobile telemetry into your SIEM. Baseband exploitation is detectable primarily through crash residue and post-compromise behavior. If Android logs aren't reaching your SOC today, this is the incident that justifies the investment.
Bottom Line
Answer-the-phone exploitation is the nightmare scenario for mobile security: near-zero user interaction, a delivery channel that bypasses every network control you own, and a target layer — the modem — that your EDR cannot see. The defensive response is unglamorous but effective: know your chipset exposure, patch relentlessly, strip the attack surface (video calling) from devices you can't patch, and watch for the crash signatures that indicate someone is probing your fleet's basebands. Organizations that treat mobile devices as first-class citizens of their detection and vulnerability management programs will weather this; those that treat phones as opaque appliances will not know they've been hit.
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.