UNISOC Modem Video-Call RCE: Defending Against Unauthenticated Baseband Code Execution

Security researchers have disclosed a critical vulnerability in UNISOC modem firmware that permits unauthenticated, kernel-level remote code execution — triggered simply by placing a video call to a target device. No user interaction is required beyond the device's modem processing the incoming call signaling. If you manage a mobile fleet that includes budget and mid-range Android devices, this is not a theoretical exercise: UNISOC chipsets ship in hundreds of millions of devices worldwide, including handsets sold under Samsung, Motorola, Realme, Nokia, and numerous regional brands.

This is the class of vulnerability that keeps mobile security teams up at night. The baseband processor operates below the operating system, enjoys privileged access to memory, and historically receives far less scrutiny — and far slower patching — than the application layer. A modem-level RCE is a foothold that can bypass Android's sandboxing, SELinux enforcement, and most endpoint detection tooling entirely.

No CVE identifier has been published in the reporting to date, and a CVSS score has not been formally assigned. Based on the attack characteristics — unauthenticated remote execution, no user interaction, kernel-level impact — this maps squarely to critical severity. Treat it accordingly.

Technical Analysis

Affected Component and Attack Surface

The flaw resides in the UNISOC modem firmware's handling of video call signaling, which traverses the IMS (IP Multimedia Subsystem) stack used for VoLTE (Voice over LTE) and ViLTE (Video over LTE). When a device receives an incoming video call, the modem parses session signaling and media negotiation parameters before the user ever answers — or even sees a notification.

The exploitation chain, from a defender's perspective:

Delivery vector: The attacker initiates a video call to the victim's phone number over the carrier IMS network. Only the target's MSISDN (phone number) is required — no phishing, no link, no app install.
Vulnerable parser: Malformed or specially crafted signaling/media parameters in the call setup reach the modem's IMS handling code, triggering memory corruption in the baseband.
Execution: The corruption yields code execution within the modem/baseband context. Reporting indicates this can be escalated to kernel-level execution on the application processor side, giving the attacker control of the device below the OS security model.
Persistence potential: A compromise at this layer can survive app reinstalls and is largely invisible to Android-level EDR. Only a full firmware reflash or factory-level remediation reliably evicts an implant at this depth.

Affected Products

Devices built on UNISOC (formerly Spreadtrum) SoCs and modem platforms across 2G/3G/4G/5G product lines.
Predominantly budget and mid-range Android smartphones and tablets, plus UNISOC-based feature phones, IoT modules, and some connected-vehicle telematics units.
Enterprise exposure concentrates in organizations issuing lower-cost Android handsets, and in BYOD fleets common in emerging markets where UNISOC-based devices dominate.

Exploitation Requirements and Status

Authentication: None. The attacker needs only the victim's phone number and the ability to reach them via carrier IMS video calling.
User interaction: None required at the signaling-parsing stage.
Exploitation status: Per the reporting, the flaw was demonstrated by researchers. Public proof-of-concept code and confirmed in-the-wild exploitation have not been reported at time of writing, and the issue does not yet appear in the CISA Known Exploited Vulnerabilities catalog. However, baseband vulnerabilities of this class historically attract rapid interest from commercial surveillance vendors and nation-state actors — the window between disclosure and weaponization for zero-interaction mobile bugs is measured in weeks, not months.

Why This Matters Beyond Phones

UNISOC modems also appear in IoT gateways, asset trackers, and industrial telemetry units. Those devices almost never receive firmware updates on a security cadence. If your OT/IoT inventory includes cellular modules, you likely have unpatchable exposure that requires compensating controls rather than patching.

Detection & Response

Detection of baseband exploitation is genuinely hard — the compromise happens below where most telemetry lives. The honest defensive strategy is three-layered: (1) detect exploit delivery attempts at the network/signaling layer, (2) detect post-exploitation behavior where the attacker pivots into the OS, and (3) hunt for crash and instability telemetry that indicates exploitation attempts against the modem.

SIGMA Detections

The first rule targets post-exploitation pivoting: on Linux-based systems (including Android devices enrolled in enterprise logging via auditd or MDM-ingested telemetry), radio/telephony service processes spawning shells or interpreters is a high-fidelity indicator of a baseband-to-OS pivot. The second rule targets exploit delivery: malformed or anomalous SIP/IMS video call signaling observable in Zeek or Suricata logs for organizations running their own IMS infrastructure (enterprises with private LTE/5G, carriers, and MVNOs).

YAML

---
title: Telephony or Radio Service Spawning Shell or Interpreter
tid: 3f8a2c41-7d6e-4b19-a2c5-9e1f4d8b6a30
status: experimental
description: Detects radio, telephony, or modem-related service processes spawning shells or script interpreters on Linux/Android systems, consistent with post-exploitation pivoting from a baseband compromise such as the UNISOC modem video-call RCE.
references:
  - https://www.infosecurity-magazine.com/news/unisoc-modem-flaw-rce-calls/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/rild'
      - '/radio_daemon'
      - '/com.android.phone'
      - '/telephony'
      - '/ims'
      - '/modemd'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/python'
      - '/perl'
      - '/busybox'
  condition: selection_parent and selection_child
falsepositives:
  - Vendor diagnostic tooling on carrier test devices
  - OEM engineering builds with debug shells enabled
level: high
---
title: Anomalous SIP Video Call Signaling Over IMS
tid: 8b4e6d02-1a3f-4c78-b5d2-2f9a7e3c1b84
status: experimental
description: Detects SIP INVITE messages advertising video media sessions from external or unexpected sources, indicative of potential exploit delivery attempts against IMS/VoLTE/ViLTE stacks such as the UNISOC modem video-call vulnerability. Correlate on volume from a single source for higher fidelity.
references:
  - https://www.infosecurity-magazine.com/news/unisoc-modem-flaw-rce-calls/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  product: zeek
  service: sip
detection:
  selection:
    method: 'INVITE'
    content_type|contains:
      - 'application/sdp'
  filter_internal:
    id.orig_h:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter_internal
falsepositives:
  - Legitimate external video calls traversing monitored IMS boundaries
  - Inter-carrier peering traffic on carrier networks
level: medium

Tuning guidance: The SIP rule will be noisy on carrier networks where external video calls are the norm — deploy it as a correlation seed (count INVITEs per source per destination number over short windows) rather than a standalone alert. The process-pivot rule is the higher-fidelity detection; a telephony service spawning a shell on a production device is essentially never legitimate.

Microsoft Sentinel / Defender KQL Hunt

This query hunts Syslog-ingested mobile device and network telemetry for two signals: repeated modem/baseband crash events on device fleets (exploitation attempts against memory-corruption bugs frequently cause visible instability before a successful exploit), and anomalous SIP INVITE volume from single sources in environments ingesting SBC or firewall logs via CommonSecurityLog.

KQL — Microsoft Sentinel / Defender

// Hunt for baseband crash telemetry and anomalous video-call signaling
// Part 1: Modem/baseband crash loops from MDM or syslog-ingested Android fleets
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("baseband", "modem", "rild", "ims_crash", "modem_crash", "radio crash")
    or ProcessName has_any ("rild", "modemd", "ims")
| summarize CrashCount = count(), DistinctHosts = dcount(Computer) by Computer, bin(TimeGenerated, 1h)
| where CrashCount >= 3
| sort by CrashCount desc
;
// Part 2: SIP INVITE anomalies from ingested SBC/firewall logs (CEF)
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where ApplicationProtocol =~ "SIP" or Message has "INVITE"
| where Message has "INVITE"
| extend IsVideo = Message has "m=video"
| summarize InviteCount = count(), VideoInvites = countif(IsVideo), UniqueDestinations = dcount(DestinationIP)
  by SourceIP, bin(TimeGenerated, 15m)
| where VideoInvites >= 10 or (InviteCount >= 50 and UniqueDestinations >= 20)
| sort by VideoInvites desc

Thresholds assume an enterprise network; carriers and private-LTE operators should baseline their own signaling rates first. A single external source placing many video calls to distinct internal numbers in a short window is the classic signature of exploit spraying against a phone-number range.

Velociraptor VQL Hunt

For Linux-based endpoints under your control (engineering devices, Android-x86 test fleets, IoT gateways, telematics units), this artifact hunts for the post-exploitation pivot: processes spawned by radio/modem service contexts, plus unexpected listeners established by telephony-adjacent processes.

VQL — Velociraptor

-- Hunt for modem/baseband post-exploitation pivots on Linux-based devices
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       getppid(pid: Pid) AS ParentChain
FROM pslist()
WHERE CommandLine =~ '(rild|modemd|ims|telephony|radio_daemon|com\\.android\\.phone)'
   OR Exe =~ '(rild|modemd|radio_daemon)'

-- Correlate: shells or interpreters whose parent is a radio/modem service
SELECT p.Pid, p.Name AS Child, p.Exe AS ChildExe, p.CommandLine,
       parent.Name AS Parent, parent.Exe AS ParentExe, p.Username, p.CreateTime
FROM pslist() AS p
JOIN pslist() AS parent ON p.Ppid = parent.Pid
WHERE (parent.Exe =~ '(rild|modemd|radio_daemon|ims)'
    OR parent.Name =~ '(phone|telephony|ims)')
  AND p.Exe =~ '(sh$|bash$|dash$|python|perl|busybox|nc$|netcat)'

Any hit on the second query warrants immediate device isolation and forensic acquisition — there is no legitimate reason for a production telephony service to spawn an interactive shell.

Inventory and Verification Script

You cannot patch what you haven't inventoried. This Bash script uses ADB to enumerate connected Android devices, identify UNISOC/Spreadtrum chipsets, and pull baseband versions and security patch levels for exposure assessment.

Bash / Shell

#!/usr/bin/env bash
# UNISOC modem exposure inventory via ADB
# Requires: adb in PATH, devices with USB debugging or MDM-managed adb access

REPORT="unisoc_exposure_$(date +%Y%m%d).csv"
echo "serial,model,hardware,baseband,soc,security_patch,sdk" > "$REPORT"

adb devices | awk 'NR>1 && $2=="device" {print $1}' | while read -r SERIAL; do
  MODEL=$(adb -s "$SERIAL" shell getprop ro.product.model 2>/dev/null | tr -d '\r')
  HW=$(adb -s "$SERIAL" shell getprop ro.hardware 2>/dev/null | tr -d '\r')
  BASEBAND=$(adb -s "$SERIAL" shell getprop gsm.version.baseband 2>/dev/null | tr -d '\r')
  SOC=$(adb -s "$SERIAL" shell getprop ro.board.platform 2>/dev/null | tr -d '\r')
  PATCH=$(adb -s "$SERIAL" shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')
  SDK=$(adb -s "$SERIAL" shell getprop ro.build.version.sdk 2>/dev/null | tr -d '\r')

  echo "$SERIAL,$MODEL,$HW,$BASEBAND,$SOC,$PATCH,$SDK" >> "$REPORT"

  # Flag UNISOC/Spreadtrum silicon (common identifiers: sprd, ums, sc, tiger, sharkl)
  if echo "$HW $SOC $BASEBAND" | grep -qiE 'sprd|ums|unisoc|sc[0-9]{3,4}|tiger|sharkl|sc9863|t606|t610|t618|t760'; then
    echo "[!] EXPOSED: $SERIAL ($MODEL) — UNISOC platform, patch level $PATCH" >&2
  fi
done

echo "Inventory written to $REPORT"

# Cross-reference flag: any device with a security patch older than the current
# disclosure remediation date should be prioritized for isolation or replacement
grep -E 'sprd|ums|unisoc|tiger|sharkl' "$REPORT" | awk -F, '$6 < "2026-01" {print "STALE PATCH: "$1" "$2" patch="$6}'

For MDM-managed fleets, replicate this logic via your MDM's API — most platforms (Intune, Workspace ONE, SOTI, ManageEngine) expose hardware platform and security patch attributes you can query at scale without per-device ADB.

Remediation

1. Patch through OEM channels — immediately and on an enforced cadence. UNISOC distributes modem firmware fixes to device manufacturers, who ship them via Android security updates. The fix reaches end users only as fast as the OEM's update pipeline allows. Prioritize devices from manufacturers with committed monthly patch cadences; budget devices on quarterly or sporadic cycles will lag dangerously. Enforce minimum security patch levels through your MDM compliance policies and quarantine non-compliant devices from corporate resources.

2. Disable ViLTE/video calling as a workaround where operationally feasible. The exploit vector is the video call signaling path. On managed devices, disable video calling at the carrier/SIM provisioning level (contact your carrier to disable ViLTE on enterprise lines) or restrict IMS features via OEM-specific device management controls where available. This is a mitigation, not a fix — but it removes the delivery vector while patches propagate.

3. Segment and restrict high-risk devices. UNISOC-based devices pending patching should be barred from accessing sensitive corporate data, placed on isolated network segments, and stripped of privileged access (VPN to production, admin credentials, payment systems). Apply zero-trust principles: assume the modem is a compromised network peer.

4. Audit your IoT/OT cellular inventory. Identify every UNISOC-based module in gateways, trackers, and telemetry units. Most will never receive a patch. Compensate with carrier-level private APNs, inbound connection restrictions, and network-layer monitoring of signaling anomalies.

5. Monitor for exploitation indicators. Deploy the detections above. Watch for device instability patterns — repeated modem resets, IMS registration failures, and unexplained reboots clustered across a phone number range are the smoke that precedes the fire with memory-corruption exploitation.

6. Demand vendor transparency. Escalate to your device OEMs and carriers for written confirmation of affected model lists and patch timelines. Reference the public reporting at Infosecurity Magazine in your inquiries. Organizations with leverage — large fleet buyers, government contracts — should make baseband patch cadence a procurement requirement going forward.

7. Plan for the worst case. If you suspect active exploitation against an executive or high-value target's device, treat it as a full compromise: replace the device, rotate all credentials ever present on it, and review account activity for the exposure window. Forensic assurance at the baseband layer is effectively unattainable in the field — replacement is the only reliable eviction.

The Bottom Line

Zero-interaction baseband vulnerabilities are the apex of the mobile threat landscape, and UNISOC's footprint means this one has enormous blast radius even if exploitation hasn't yet been confirmed in the wild. The defensive playbook is unglamorous but effective: inventory aggressively, patch relentlessly, kill the video-call vector where you can, and watch your telemetry for the instability that betrays exploitation attempts. The organizations that get hurt by bugs like this are the ones that didn't know what was in their fleet.

Related Resources

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