Most mobile threat models still assume an attacker needs you to install something or tap a link. The chain that security firm SSD Secure Disclosure published on August 17 skips all of that. On a phone built around a Unisoc modem, answering a video call is enough to put an attacker inside the Android kernel, the most privileged code on the device. There is no patch, and the reason there is no patch is the part worth your attention.
The research comes from an independent researcher publishing through SSD, and it lands in two stages. The first, disclosed in March 2026, is remote code execution inside the modem itself, reached through a malformed video-call setup message. The second, published last week, is the escalation that turns that modem foothold into full control of the phone. Neither stage has been assigned a CVE identifier, and both outlets that covered the research report the same core facts.
What actually happens when the call connects
Voice over LTE, or VoLTE, carries calls as data over the 4G network, and the modem parses the signaling that sets each call up. The March flaw let a crafted video-call message corrupt the modem's memory and run attacker code there. That alone is bad, but a modem is meant to be a sandbox: even if it is compromised, it should not be able to touch the main processor that runs Android.
On the affected Unisoc parts, that boundary does not hold. The modem and the application processor share physical memory, and the escalation reprograms the modem's memory protection unit, the hardware that is supposed to fence off regions of memory, so the entire address space becomes readable, writable, and executable from the modem's side. The kernel lives in that space. Once the fence is down, modem code can rewrite kernel code directly. SSD classifies the root cause as improper isolation of shared resources on a system-on-a-chip (CWE-1189), a precise way of saying the silicon never enforced the wall the software design assumed was there.
The shape of the attack matters for how worried you should be. The full chain needs the attacker to run their own cellular infrastructure, a rogue base station the target's phone will attach to, and it needs the target to answer the incoming video call. That is not a mass-exploitation profile. It is a proximity and targeting capability, the kind of thing that matters at a border crossing, a protest, or against one high-value person, not a spray-and-pray campaign against a whole carrier. That threat model sits closer to the mobile device security concerns of people who cross borders than to everyday malware.
Who is actually exposed
The confirmed chip is the Unisoc T612, and researchers say the same firmware ships on at least two more parts, the T606 and the T7250. These are not flagship components. They sit at the cheap end of the market, in phones like the Realme C33, the Motorola E13, and the Xiaomi Redmi A5, the handsets a company hands to field staff, buys in bulk, or that employees bring from home without anyone knowing what silicon is inside.
| Unisoc chipset | Example phone | Status |
|---|---|---|
| T612 | Realme C33 | Confirmed vulnerable |
| T606 | Motorola E13 | Same firmware, no fix |
| T7250 | Xiaomi Redmi A5 | Same firmware, no fix |
That last point is the exposure most teams will miss. Mobile device management inventories record the Android version and the security patch level. Almost none of them record the modem chipset. So the question this research forces, do we run Unisoc modems and where, is one most organizations cannot answer from the data they already collect. The vulnerable surface is invisible to the tools meant to see it, the same blind spot behind most kernel-level privilege escalation that starts below the application layer.
Why there is no fix, and why that is the story
Android ships a monthly patch bundle, the Android Security Bulletin. The August 2026 bulletin does not address this escalation, and it structurally cannot: the flaw is in the chipset vendor's modem firmware and in the silicon's memory design, both below the layer Google patches. A fix has to originate with Unisoc, flow to each device maker, and then reach the phone as a firmware update, a path that barely exists for budget hardware. SSD says it tried to reach Unisoc by email and LinkedIn and received no response, and no Unisoc advisory covers the escalation.
This pipeline has worked before. A 2022 flaw in Unisoc modems, reported by Check Point, was fixed through the Android Security Bulletin as CVE-2022-20210. The machinery to remediate a modem bug at scale exists. As of this writing, SSD reports Unisoc has not published an advisory or responded to its disclosure attempts, so no vendor fix has begun. That is why the remediation gap, not the exploit, is the part defenders should sit with. It is the same trap behind unpatchable mobile hardware: when the bug is in silicon or in firmware nobody updates, "patch it" is not on the table.
What a defender can do this week
There is no patch to deploy, so the work is inventory and exposure reduction, prioritized by who actually holds these devices.
-
Find the Unisoc devices. Treat "which of our phones use a Unisoc modem" as a real inventory question. In practice it means checking the chipset for each budget model in your fleet, because the standard device-management field does not carry it.
-
Prioritize by role, not by count. Because the attack needs rogue cellular infrastructure and an answered call, the people who matter are those who travel to hostile environments or hold sensitive access, not the whole device population.
-
Reduce the trigger where you can. Where the platform allows it, disabling VoLTE or restricting video calling on high-risk devices removes the entry point. On many budget phones that control does not exist, which is itself a reason to move sensitive roles onto hardware with a living firmware pipeline.
-
Watch for the manufacturer update. The only durable fix is a firmware update from the device maker. Track it per model, and set the expectation that for the cheapest handsets it may never arrive.
The pattern underneath
The modem is the least-inventoried and least-updatable part of a phone, and it processes attacker-reachable input the moment the device is on a network. This chain is a clean demonstration of what that combination costs: a hardware trust boundary that was assumed rather than enforced, reachable from an answered call, on silicon that ships in millions of devices with no way to push a fix. The specific bug will fade. The structural problem, cheap radios in cheap devices with no patch path, will keep producing these, and the teams that come out ahead are the ones that start inventorying the modem now.