Unisoc VoLTE exploit chain gives attackers full Android kernel access — and Unisoc is not responding

In brief

This article walks through the full chain, the affected chipsets, and why this case reframes the conversation about silicon vendor accountability in the mobile supply chain.

Context: why Unisoc matters

Unisoc, formerly known as Spreadtrum, is a Shanghai-based chipset vendor that supplies SoCs for phones from brands including Motorola, Realme, and Xiaomi. Per the SSD advisory, its chips are present in devices sold in more than 140 countries. Specifically confirmed as affected are the Motorola E13 (T606 chipset), the Realme C33 (T612), and the Xiaomi Redmi A5 (T7250).

The point is not just Unisoc's market share — it is its position in the entry-level Android segment. These phones are the default choice in emerging markets, secondary devices for executives, and in some cases the only option for employees with budget constraints. The attack surface is not limited to individual users: any corporate fleet using these devices, intentionally or through shadow IT, is at risk.

The two-stage chain

The SSD Secure Disclosure is split into two separate publications:

**Stage 1 (March 2026)**: remote code execution in the modem firmware via a malformed SIP VoLTE (Voice over LTE) video call. The vulnerability allowed an attacker to execute code in the modem context simply by sending a manipulated VoLTE video call to the victim device.

**Stage 2 (August 2026)**: local privilege escalation from the modem context into the Android kernel. This second stage is what was disclosed in August and what converts the initial RCE into full device compromise.

The full chain requires the attacker to meet three conditions:

1. Control a private 4G network (an open-source 4G core works). 2. Have a software-defined radio (SDR) for the 4G radio interface. 3. Have the victim answer the incoming VoLTE video call.

Condition 3 matters: unlike many mobile exploits, this one is not completely silent. The victim must see an incoming call and decide to answer it. That said, social engineering directed at a high-value target (CISO, security researcher, executive with a low-end device) remains trivial.

The technical vulnerability: CWE-1189

The privilege-escalation flaw is classified as CWE-1189, "Improper Isolation of Shared Resources on System-on-a-Chip." The SSD advisory does not assign a CVE identifier yet, which is problematic on its own: any vulnerability management tooling based on NVD will not detect this class of exposure.

The technical detail deserves attention. Modern SoCs have at least two distinct processors: the application processor (where Android and the kernel run) and the modem processor (where the baseband firmware runs). In a correct architecture, hardware-enforced boundaries prevent the modem processor from reading or modifying the application processor's memory. Those boundaries are critical: kernel memory is where the entire system state lives.

The affected Unisoc chipset shares physical memory space between the modem processor and the application processor, without a hardware-enforced boundary. That means any code already executing in the modem context (thanks to the stage 1 RCE) can, in principle, read and write the physical memory corresponding to the Android kernel.

The SSD exploit takes that capability to the limit: the escalation works by rewriting the configuration of the modem processor's ARM Memory Protection Unit (MPU). The MPU is the hardware component that defines which memory regions are readable, writable, and executable. By rewriting its configuration through coprocessor registers, the exploit maps the entire 32-bit physical address space as readable, writable, and executable from the modem context — including the pages where the Android kernel resides.

Once the MPU is reconfigured, the attacker writes directly into kernel memory from the modem context. SSD researchers confirmed kernel-level code execution by observing kernel logs that showed the injected payload's output.

Why there is no patch

This is the uncomfortable part. SSD tried multiple channels to reach Unisoc before disclosure: email and LinkedIn. None received a response. The March 2026 disclosure carried exactly the same statement. There is no Unisoc security advisory covering this vulnerability, and the August 2026 Android Security Bulletin (published before this disclosure) does not address it either.

For security professionals this is the worst possible scenario. SSD's coordinated disclosure policy is standard: contact the vendor, wait a reasonable period, publish with an advisory describing the risk. But when the vendor does not respond, disclosure becomes a public security event with no available remediation.

Useful historical comparison: in 2022, Check Point Research uncovered a coordinated Unisoc modem vulnerability, CVE-2022-20210, which was patched and distributed through the Android Security Bulletin. The precedent shows Unisoc can respond when it chooses to. The lack of response in 2026 is not a technical problem — it is an organizational problem.

Related work from Kaspersky: the pattern repeats

This is not the first time the architectural condition of mobile chipsets lacking memory separation between modem and application processors has surfaced. In November 2025, Kaspersky ICS CERT published research on a different Unisoc chip, the UIS7862A, found in vehicle head units. After gaining modem code execution via a separate vulnerability, the Kaspersky team was also able to reach and modify the running Android kernel by exploiting the modem and application processor's shared physical address space.

Kaspersky described one of its lateral movement paths, involving a hidden Direct Memory Access peripheral, as a hardware-level issue not fixable through a software update. That is important: even if Unisoc wanted to patch this case, the DMA route mentioned by Kaspersky is not patchable. The MPU route used in the SSD chain is in principle addressable through a firmware change, but Unisoc has not committed to one.

Devices confirmed as vulnerable

The advisory confirms exploitation on the following devices:

- **Motorola E13**: February 2025 security patch level. Confirmed vulnerable. - **Xiaomi Redmi A5**: January 2026 security patch level. Confirmed vulnerable.

A device with a January 2026 security patch is still vulnerable, which indicates the flaw is in the modem firmware layer (which does not update with the monthly Android Security Bulletin) or in the hardware architecture (which cannot be changed without an SoC redesign).

Researchers also mention the T612 chipset (Realme C33) as vulnerable, although the confirmed test case is against the T606 and T7250. Realme C33 users should assume the same risk until Unisoc publishes clarification.

Implications for DevSecOps teams

**1. Mobile device inventory.** The first step is auditing how many Unisoc devices are in your fleet. The most direct way is to query the MDM (Intune, Jamf, Kandji, VMware Workspace ONE) and filter by model. The Motorola E13 and Xiaomi Redmi A5 are the most common; any matching device must be flagged as high risk.

**2. Network segmentation.** If you have employees with Unisoc devices in the fleet, make sure they do not have direct access to sensitive resources from the mobile network. Forcing corporate VPN with strong authentication before accessing internal services is a viable compensating control.

**3. Acceptable use policy.** Explicitly document which devices are approved for corporate use. Uncertified Unisoc chipsets should fall outside the scope of confidential data.

**4. Incoming VoLTE monitoring.** On critical devices consider disabling VoLTE in favor of CSFB (Circuit-Switched Fallback) calls or services like WhatsApp/Signal that do not depend on the modem's SIP infrastructure. The tradeoff: loss of audio call quality.

**5. Incident response plan.** If your organization has high-risk employees (executives, researchers, M&A teams) with Unisoc devices, develop a response plan that assumes total device compromise. Include immediate device replacement, credential rotation across all services the device had access to, and a forensic review of the event chain.

What it means for the industry

The Unisoc case exposes three systemic problems:

**The mobile supply chain has no accountability.** Unlike the server ecosystem, where Intel, AMD, and ARM respond to CVEs and ship microcode updates, mobile chipset vendors do not carry the same contractual obligation. An enterprise buyer can demand CVE patches from its server vendor within defined SLAs; with a phone vendor that contract does not exist.

**Coordinated disclosure fails when the vendor does not respond.** SSD did everything correctly. Responsible disclosure policy requires contact, wait, and publish. But the model assumes a responsive vendor. When there is no response, the result is public disclosure without remediation, which is worse for everyone: attackers get the exploit, defenders have no patch.

**Mobile firmware security testing is opaque.** In the Android ecosystem, users trust the OEM (Motorola, Realme, Xiaomi) to distribute chipset vendor patches. When that vendor does not respond, the OEM is left unable to act. The dependency chain is invisible to the final buyer.

What to do now

If you run a mobile fleet, the immediate actions are:

- Audit the MDM inventory for affected Unisoc chipsets. - Block access to sensitive resources from identified devices. - Disable VoLTE on critical devices as a temporary measure. - Document the risk decision in the security exception register. - Request written confirmation from your OEM of the exposure status.

There is no patch to apply. The control is in the management layer, not the technical layer.

Call to action

Want to go deeper on how your organization should evaluate silicon vendor risk in mobile fleets? Follow X-Ops on X, Instagram, LinkedIn, and YouTube, and Hacker Dreams on X, Instagram, and LinkedIn. Every week we publish a technical analysis of a critical vulnerability with actionable context for your DevSecOps team. Upcoming topics: exploit chain in the GeoServer zero-day, the China-nexus APT campaign against VMware infrastructure, and the state of SAP Commerce Cloud patching after CVE-2026-58231.

---

*Sources: SSD Secure Disclosure advisory (ssd-disclosure.com/unisoc-t612-lpe/), prior RCE disclosure (ssd-disclosure.com/unisoc-t612-rce/), The Hacker News original report, prior Kaspersky ICS CERT research (ics-cert.kaspersky.com).*