SHANGHAI, 18 AUG 2026 — Researchers have published the second half of an exploit chain that turns an answered video call into full Android kernel access on handsets using Unisoc modem firmware. There is no patch, and the disclosing team says the chipmaker did not answer its messages.

The flaw is not in Android. It is in the boundary between the modem and the rest of the phone, which on these devices is not much of a boundary at all.

The chain

CWE-1189Improper isolation of shared resources on a system-on-chip
Two stagesMarch 2026 remote code execution, August 2026 kernel access
PrerequisitesA private 4G network under the attacker's control, and an answered video call
No fixVendor unreachable by email and LinkedIn; no patch or mitigation

SSD Secure Disclosure published the advisory on 17 August. It completes work begun in March, when the same team disclosed remote code execution in Unisoc modem firmware through a malformed SIP video call. The research is credited to an independent researcher using the handle 0x50594d, and the advisories name the UNISOC T612 platform.

The second stage escalates from that foothold. Because the modem and the Android kernel do not have proper memory isolation, code running in the modem context can reach memory belonging to the kernel — which is how an exploit that starts in a phone's radio ends up owning the phone.

Why the modem boundary matters more than most people think

Every mobile phone contains two computers. One runs Android and the applications, and gets the security attention: sandboxes, permissions, monthly patches, a review process for the store. The other runs the cellular radio, speaks to whatever tower it can hear, and is largely invisible.

The security model depends on the second computer being unable to reach into the first. That separation is what makes it acceptable for the radio to process untrusted input from any base station in range, because even a compromised modem should be contained.

The advisory describes this separation failing at the silicon and firmware level. A hostile network can reach past the radio into the operating system, bypassing all of Android’s own defences: the permission model, the sandbox, and the store review process.

Calibrating the risk honestly

The attack has two prerequisites: the attacker must operate a private 4G network that the target device attaches to, and the victim has to answer the video call.

That is not a mass-exploitation profile. It rules out remote attacks at scale, and it is a poor fit for ordinary criminal activity, which needs volume. What it fits is targeted work against a specific person in a specific place: a rogue base station in a hotel, a conference venue, a border post, an office car park. The equipment for that is neither exotic nor expensive any more.

This does not mean every affected handset is in danger this week. It means a category of device now has a known, unpatched path from the radio to the kernel, available to an attacker willing to bring their own network. For most people that is a low risk. For a journalist, an activist, a negotiator or a senior official carrying one of these handsets, it is not.

The patching problem is the ASEAN problem

Unisoc silicon is concentrated at the affordable end of the Android market, and the affordable end of the Android market is where much of Southeast Asia buys its phones.

That matters because of how fixes travel. A modem firmware defect is repaired by the chipmaker, integrated by the device manufacturer, and shipped as a firmware update to the handset. Every link in that chain has to work, and in the budget segment the last two frequently do not: many devices receive no firmware updates at all after the first year, and some never receive one.

In this case, the fix chain has not started. The disclosing team says it tried email and LinkedIn and got no response from Unisoc. Without a patch from the chipmaker, device manufacturers have nothing to integrate and owners have nothing to install. The advice in the advisory — watch for a firmware update from your device maker — is honest and, for a large share of affected owners, empty.

This is less a scandal about one company than a structural feature of cheap hardware. The economics that put a capable phone in more hands also remove the update path that would keep it safe, and no regulator in the region currently requires a minimum support period for handsets.

What an organisation can actually do

Very little of the usual advice applies, because the compromise happens below the layer any mobile management tool can see.

The practical measures are unglamorous and specific. Know which chipset your organisation's phones use, which is not something most asset inventories record. Treat unexpected video calls on the affected handsets as a threat rather than a nuisance, since the chain requires the call to be answered. For staff who plausibly attract targeted attention, put them on hardware with a maintained firmware path and a named support window, and accept the cost as the price of a patchable device.

The wider lesson is one we keep arriving at from different directions. We wrote yesterday that AI-generated code fails security tests about 44 per cent of the time and that the exposure falls hardest on organisations without a review function. This is the hardware version: the defect is upstream, invisible, and the ability to do anything about it depends entirely on a supply chain the buyer never sees.

What we could not establish

It is not known which specific devices are affected. The advisories name the UNISOC T612 platform, but neither the researchers nor the vendor has published a list of handsets or firmware versions with the vulnerable code.

It also remains unclear whether a CVE has been assigned, whether Unisoc has acknowledged the report, if newer platforms share the defect, if the exploit has been used in the wild, how long the disclosure timeline ran, or if device manufacturers were notified independently.

We also could not verify the technical claims first-hand. This account rests on the disclosing team's advisory and reporting of it, and no independent reproduction has been published.

What to watch

The first thing to watch for is a vendor response. Silence from a chipmaker after a published chain of this severity is unusual. An acknowledgement, particularly one with a list of affected devices, would give owners and manufacturers a path forward.

Then watch whether any handset maker ships a firmware update naming this issue. That would prove the chain from chipmaker to device to owner can still function in the budget segment, which is currently an open question.

Finally, watch whether a regulator anywhere in this region asks about minimum support periods. Europe now requires a defined security-update window for connected devices sold there. No ASEAN market does, and a hardware defect with no patch path is exactly the case that argument gets made on.