Unisoc modem RCE: two chained CVEs that turn a VoLTE video call into full Android kernel control

The exploit chain that does not need the user to install anything

On August 17, 2026, SSD Secure Disclosure published the second stage of an exploitation chain affecting Unisoc modem firmware. The first stage was published in March 2026. Combined, the two stages turn a malicious VoLTE video call into Android kernel code execution, with no patch available and no response from the manufacturer.

The case was covered by Swati Khandelwal at The Hacker News, HackNews, multiple analysts on LinkedIn and Mallory. What makes this case unique is not just the technical depth —kernel access from the modem is territory reserved for elite research— but the fact that the initial vector is a VoLTE video call, something any mobile user answers daily without thinking about it. The chain converts a trivial user action into total device compromise.

What is most concerning about the case is what it reflects about the industry. SSD Secure Disclosure attempted to contact Unisoc through multiple channels —email and LinkedIn— without receiving a response. The March 2026 disclosure also received no response. The pattern is familiar: manufacturer silence when the issue is at low-level SoC components.

Technical anatomy: from the video call to the kernel

The chain has two clearly differentiated stages, published by SSD Secure Disclosure in March and August 2026 respectively. The independent researcher behind the finding uses the handle 0x50594d.

### Stage one — RCE in modem firmware via SIP

The first phase, disclosed in March 2026, is a remote code execution vulnerability in Unisoc modem firmware. The vector is a malformed SIP video call. When the target device receives the video call, the modem firmware processes the incoming SIP data and the vulnerability allows execution of arbitrary code in the context of the modem processor.

This phase alone is already serious —the attacker has control over modem firmware, which on most devices is an opaque zone to the main operating system— but it is stage one of a chain. On its own, execution in the modem does not directly compromise the Android operating system running on the application processor.

### Stage two — escalation from modem to Android kernel

The second phase, published on August 17, 2026, is what carries the chain to its final consequences. The vulnerability is classified as CWE-1189: Improper Isolation of Shared Resources on System-on-a-Chip. No CVE has been assigned yet and Unisoc has not issued any security bulletin covering it.

The technical root cause is that the modem processor and the application processor (where Android runs) share the same physical memory space inside the Unisoc SoC, without a hardware-enforced boundary preventing code executing on the modem from modifying Android kernel memory.

The attack exploits this architecture as follows. Once the attacker has code execution in the modem (thanks to stage one), they reconfigure the modem's ARM Memory Protection Unit (MPU) by writing to coprocessor registers. The new configuration maps the entire 32-bit physical address space as readable, writable and executable from modem context, including the pages where the Android kernel resides.

With that configuration, code executing in the modem can read, write and execute kernel memory. The SSD researchers confirmed this experimentally by observing in Android kernel logs how their injected payload ran in kernel context.

### Affected chipsets and devices

The researchers confirmed the chain on devices with three specific chipsets:

- Unisoc T606, found in the Motorola E13 - Unisoc T612, found in the Realme C33 - Unisoc T7250, found in the Xiaomi Redmi A5

Testing was performed on a Motorola E13 with the February 2025 security patch and a Xiaomi Redmi A5 with the January 2026 security patch. This confirms that even devices with relatively recent patches are vulnerable.

### Requirements for exploitation

The full chain is not trivial to execute. It requires three simultaneous conditions:

1. The attacker must control a private 4G network. The researchers built their test environment using an open-source 4G core network, a software-defined radio for the 4G radio interface, and specialized SIM cards. 2. The target device must be within range of that attacker-controlled 4G network. This rules out mass-scale internet attacks and limits the scenario to state actors, corporate espionage, or targeted physical attack scenarios. 3. The victim must answer the incoming VoLTE video call. If the victim does not answer, the chain does not progress.

These three conditions make the case unsuitable for mass exploitation but a credible scenario for attackers with resources —intelligence operators, APT attackers, targeted corporate espionage campaigns—.

Why this case is a case study for DevSecOps

Reason one — the chain crosses isolation layers that were assumed to be safe. The modem and the operating system are conceptually separated in any modern mobile security model. The Unisoc chain demonstrates that separation is illusory when the SoC manufacturer does not properly implement isolation between processors.

Reason two — no patch is available. The August 2026 Android Security Bulletin, published before the SSD disclosure, does not cover the stage-two vulnerability. Unisoc has not issued any security bulletin covering it. For affected devices, the only "mitigation" is waiting for the device manufacturer (Motorola, Realme, Xiaomi) to distribute an updated firmware that includes the Unisoc firmware fix —something that may never arrive.

Reason three — the manufacturer does not respond to responsible disclosure. SSD tried to contact Unisoc by email and LinkedIn without response. The March 2026 disclosure had the same problem. The pattern of manufacturer silence is a risk in itself: it indicates that other similar vulnerabilities may exist and will not be disclosed because the responsible-disclosure channel does not work.

Reason four — the threat is credible for targeted attack scenarios. Although the chain is unsuitable for mass attacks, the requirements (controlled 4G network, physical proximity, victim answers) are within reach of intelligence operators, APT attackers and corporate espionage campaigns. Devices at risk include phones of executives, journalists, dissidents, officials and operators of critical infrastructure traveling to regions with compromised telecommunications infrastructure.

DevSecOps playbook for this week

### Phase 1 — Exposure inventory (days 1 to 3)

The first move is to know which devices in your organization are at risk.

- Identify all mobile devices in the corporate inventory that use Unisoc chipsets. The list of confirmed vulnerable chipsets from SSD includes T606, T612 and T7250. Also check other Unisoc models that may share the same architecture. - For each identified device, document the exact model, chipset, modem firmware version and Android security patch level. - Check whether the device has recent modem firmware updates. Some manufacturers publish modem firmware updates independently from Android security patches. - Identify users of those devices. Unisoc devices tend to be mid- and low-range models, frequently assigned to operational staff, field technicians, or as secondary devices. Determine the risk level each user represents.

### Phase 2 — Risk assessment (days 3 to 7)

For each identified device, assess risk based on user profile and operating environment.

- High-risk users: executives, staff with access to sensitive information, journalists, dissidents, officials operating in regions with compromised telecommunications infrastructure. These devices should be replaced or receive additional protections. - Medium-risk users: technical staff, operations that may be targeted for corporate espionage. Evaluate replacement need case by case. - Low-risk users: general operational staff. Document the risk and monitor for firmware updates. - For high-risk users who must keep their Unisoc devices for operational reasons, consider using alternative communications (calls via end-to-end-encrypted apps over mobile data, not VoLTE) to reduce attack surface.

### Phase 3 — Temporary mitigations (days 7 to 14)

- Disable VoLTE on affected devices if the carrier allows. The chain requires an incoming VoLTE video call; without VoLTE, the chain cannot execute. The mitigation reduces call quality but eliminates the vector. - Consider using SIMs from carriers that do not easily allow handover to fake networks. Some carriers implement additional protections against IMS catchers and fake networks. - For high-risk users, provide alternative devices with Qualcomm or MediaTek chipsets that have a better track record of responding to security disclosures and more mature isolation architectures. - If the organization operates its own telecommunications infrastructure or corporate PBX, assess whether configurations allow redirecting VoLTE calls to untrusted networks.

### Phase 4 — Monitoring and response (ongoing)

- Monitor Unisoc and device manufacturer security bulletins for when updated firmware is published. - Subscribe to security feeds from Unisoc and affected manufacturers. - Document vulnerable devices in the risk register for future audits. - Coordinate with the incident response team so they know the attack vector and can recognize indicators of compromise if they appear. - If a user reports anomalous behavior on a Unisoc device after receiving suspicious video calls, treat the device as possibly compromised and isolate it from the corporate network.

Systematic mistakes teams make

Mistake one — trusting modem-OS isolation as a security guarantee. Modern mobile security models assume the modem and operating system are separated. That separation is logical and software-based, but not always hardware-reinforced. When the SoC manufacturer does not properly implement isolation, the separation is illusory.

Mistake two — ignoring low- and mid-range devices. Mobile device management tends to focus on high-end flagship models. Unisoc devices are mid- and low-range, frequently assigned to operational staff or used as secondary devices. The attack surface exists even on devices nobody is watching.

Mistake three — underestimating the threat of resource-equipped attackers. The Unisoc chain is unsuitable for mass attacks but perfectly credible for targeted attack scenarios. If your threat model excludes resource-equipped attackers, this case invalidates that assumption.

Mistake four — treating modem firmware as an immutable black box. Modem firmware is updatable, but many users and organizations never update modem firmware even when they do update the operating system. That means even after a patch, many devices remain exposed.

The paragraph for leadership

If you need the paragraph for a security committee: SSD Secure Disclosure published on August 17, 2026 a two-stage exploit chain that allows remote code execution at the Android kernel level on devices with Unisoc chipsets through a malicious VoLTE video call. Stage one is an RCE in modem firmware disclosed in March 2026. Stage two is a processor-isolation vulnerability (CWE-1189) with no CVE assigned and no patch. Unisoc has not responded to disclosure. Exploitation requires the attacker to control a private 4G network and for the victim to answer the video call, limiting the scenario to resource-equipped attackers but making it credible for targeted espionage campaigns. Confirmed vulnerable chipsets include Unisoc T606, T612 and T7250. Immediate mitigation is to inventory Unisoc devices in the organization, assess risk by user profile, disable VoLTE where possible and consider replacing devices for high-risk users.

Structural changes after this incident

Change one — Unisoc as a high-risk manufacturer in the threat model. If your inventory treats Unisoc chipsets as equivalent to Qualcomm or MediaTek, this case invalidates that assumption. Unisoc chipsets deserve additional scrutiny in any organization that handles sensitive information.

Change two — review of low-end device management. Mobile device management tends to focus on flagships. This case documents that low- and mid-range devices are credible attack vectors for high-risk scenarios.

Change three — VoLTE as a vector to assess in mobility threat modeling. VoLTE is the default option on most modern carriers. Treating VoLTE as an attack vector and evaluating mitigations (selective disabling, encrypted communication alternatives) is a practice most organizations have not yet incorporated.

Change four — responsible-disclosure process as a procurement criterion. If your organization purchases devices for high-risk personnel, the SoC manufacturer's disclosure-response history should be a selection criterion. Unisoc has demonstrated in this case that it does not respond to responsible disclosure, which is a disqualifying criterion for that usage profile.

Verified sources

- The Hacker News, "Unisoc VoLTE Video Call Exploit Chain Can Give Attackers Full Android Kernel Access", Swati Khandelwal, August 17, 2026. https://thehackernews.com/2026/08/unisoc-volte-video-call-exploit-chain.html - HackNews, "Unisoc VoLTE Video Call Exploit Chain Can Give Attackers Full Android Kernel Access", August 2026. https://hacklido.com/news/unisoc-volte-video-call-exploit-chain-can-give-attackers-full-android-kernel-access - SSD Secure Disclosure, advisory published August 17, 2026 (referenced in the sources above). - Mallory, "Unisoc VoLTE Video Call Chain Enables Full Android Kernel Access", August 2026. https://mallory.ai/stories/01a00fda-193c-73ef-acec-4c357e6743b6

Closing recommendations

Inventory every Unisoc-chipseted device in your organization. Assess risk by user profile. Disable VoLTE where possible as a temporary mitigation. Consider replacing Unisoc devices for high-risk users. And finally, incorporate the SoC manufacturer as a selection criterion in future mobile device procurement. The difference between those two frameworks is what separates organizations that contain a targeted espionage incident from those that discover the compromise when the damage is already done.