# Unisoc VoLTE Exploit Chain Gives Attackers Full Android Kernel Access — No Patch Available
## The Threat
A two-stage exploit chain targeting Unisoc modem firmware can hand an attacker complete control of the Android kernel on affected devices — and the chipmaker has yet to respond, let alone patch it. The second stage of that chain went public August 17, 2026, from SSD Secure Disclosure, completing work that began in March when the same team dropped a remote code execution vulnerability triggered by a malformed SIP video call. Together, they form a full kill chain from cellular network to kernel.
The mechanics are more alarming than the headline suggests. The attack requires an adversary to control a private 4G cellular network — not a trivial bar — and the victim to answer an incoming video call. But that physical requirement shouldn't be read as reassurance. Private 4G infrastructure built from open-source core network software and a software-defined radio is exactly the kind of setup a nation-state actor, a sophisticated criminal group, or a well-funded corporate espionage operation can assemble. The SSD researchers built their proof-of-concept environment from exactly those components.
Once code is running on the modem through the March 2026 RCE, the privilege escalation works by attacking a fundamental architectural weakness: the modem processor and the application processor inside the Unisoc SoC share physical memory with no hardware-enforced boundary between them. The attacker writes a full-access configuration to the modem's ARM Memory Protection Unit through coprocessor registers, mapping the entire 32-bit physical address space — including the pages that hold the Android kernel — as readable, writable, and executable from modem context. From there, the Android kernel is not a secured enclave but an open file. SSD confirmed kernel-level code execution by observing injected payload output in kernel logs.
## Severity and Impact
No CVE identifier has been assigned to the privilege-escalation stage as of publication. The March 2026 RCE stage is also unassigned. A separate, potentially related UNISOC advisory exists for the same chipset family.
| Identifier | Description | CVSS Score | Vector / Complexity | CWE |
|---|---|---|---|---|
| Unassigned (Aug 2026) | Modem-to-kernel privilege escalation via ARM MPU | Not scored | Network / High complexity, no auth required | CWE-1189 |
| Unassigned (Mar 2026) | Remote code execution via malformed SIP video call | Not scored | Network / High complexity | Not specified |
| CVE-2025-31718 | Modem input-validation flaw, same chipset family | 7.5 | Not published | Not specified |
The absence of CVE assignments here is itself a story. Without vendor cooperation, researchers cannot trigger the formal disclosure process that gets CVEs issued and forces the issue into security bulletins.
## Affected Products
The privilege-escalation flaw was confirmed on devices running the following Unisoc chipsets. Unisoc supplies components to manufacturers across more than 140 countries, and the shared-memory architecture is present across the chipset family.
Confirmed affected chipsets and reference devices:
Broader exposure:
The August 2026 Android Security Bulletin, published before this disclosure, does not address either stage of this chain.
## Mitigations
There are no patches available. Unisoc has not responded to SSD's outreach attempts — the same situation that existed when stage one dropped in March. Device manufacturers (Motorola, Realme, Xiaomi) have not issued updated firmware addressing either vulnerability.
Until patches arrive, the options are limited:
## References
---
## HackWire Analysis
What makes this research genuinely uncomfortable is not the sophistication of the exploit — it's the architecture. CWE-1189, Improper Isolation of Shared Resources on System-on-a-Chip, is not a coding bug someone left in a function. It's a design decision baked into silicon. You cannot patch it with a software update the way you'd fix a buffer overflow; at best, you can work around the absence of hardware enforcement through firmware-level constraints that are themselves potentially bypassable. That's a deeply unsatisfying position for anyone responsible for securing devices built on this chipset.
The vendor silence is its own red flag. Two disclosures five months apart, both with no response from Unisoc, suggests one of three things: the company lacks a functional security response process, it's aware and has no viable fix to offer, or it's deliberately running out the clock hoping the research fades. None of those scenarios reflects well on the chipmaker or on the brands shipping Unisoc silicon in consumer devices.
The Kaspersky parallel from November 2025 deserves more attention than it's getting. When two independent research teams, working on different Unisoc chips, reach the same architectural conclusion through different initial vulnerabilities, that's not coincidence — it's a structural security property of this product line. The fact that one of those chips is running in vehicle head units should prompt automotive security teams to ask hard questions of their suppliers right now, not after a public incident.
For defenders in enterprise or government environments: the immediate question isn't just "do we have Motorola E13s in the building?" It's "what is our process for identifying and quarantining devices from chipset vendors with no disclosed vulnerability response program?" That process, for most organizations, doesn't exist yet.
— HackWire Editorial
## Related Coverage