A Call That Asks for Nothing
A phone lights up with an incoming video call over VoLTE, the voice-over-LTE standard that now carries most calls on modern networks. The person holding it has not yet tapped anything. Somewhere beneath the operating system, in a part of the chip most owners have never heard of, the modem is already parsing the call setup and beginning to process video-call signaling data on its own separate processor core.
That separate core is the target. Security researchers at SSD Secure Disclosure published an advisory on August 17, 2026 describing a working exploit chain against the Unisoc T612, a chipset built into a wide range of budget and mid-range Android phones. The path in runs through the modem's handling of VoLTE video-call signaling, not through the Android operating system the user actually sees.
The Hacker News, which also covered the advisory, framed the significance plainly: this is not a theoretical weakness in a lab writeup, it is a demonstrated chain that a working exploit can walk from a phone call to kernel-level control of the device, without the user needing to open an app, click a link, or grant a permission beyond letting the phone ring.
Inside the Three-Stage Chain
The researchers describe the exploit as three linked stages. The first is what they call an egg hunter, a technique that scans memory for a small planted payload once the attacker has any kind of write access, rather than needing to know exact memory addresses ahead of time. It is a reconnaissance step that turns a narrow foothold into a usable one.
The second stage is the one that matters most: a bypass of the chip's MPU, or memory protection unit, the hardware feature that is supposed to keep the modem's execution context walled off from sensitive memory. SSD Secure Disclosure says the exploit disables that protection and then writes kernel shellcode directly, giving the attacker unrestricted physical memory access from inside the modem's own execution environment, a zone that was never supposed to reach that far.
The third stage is a trampoline through do_sys_open, a low-level kernel function used to open files, which the chain repurposes to pivot from raw memory access into full kernel control on the Android side. Chained together, the three stages take an attacker from a received VoLTE video call to control of the operating system kernel itself, which is close to the maximum level of access a device can grant.
A Chip Family, Not a Single Phone
SSD Secure Disclosure and The Hacker News both name two confirmed affected devices: the Xiaomi Redmi A5 and the Motorola E13, two of the most common entry-level Android phones sold in Europe and elsewhere. Both are exactly the kind of device a company buys in bulk for staff who need a working phone, not a flagship.
The exposure is not limited to those two models. Unisoc chipsets account for roughly 14 percent of the global smartphone system-on-chip market, a share built almost entirely on budget and mid-range devices, and the T612 in particular ships inside phones sold under brands including Honor, Realme, vivo, Samsung and Motorola. Not every Unisoc-powered phone uses the T612, but the chip family's reach across multiple major brands means the practical footprint is larger than two model names suggest.
That combination, a widely used chip in an unglamorous market segment, is precisely why the flaw matters commercially rather than only academically. Budget and mid-range Android devices are the default choice for fleets, delivery, retail, warehouse and field-service roles, exactly the categories of hardware that get purchased in volume and updated the least often.
Why the Normal Patch Workflow Does Not Apply Yet
Here is the detail that separates this story from a routine chip vulnerability: as of publication, no CVE identifier has been assigned to the flaw, and no patch exists from Unisoc. SSD Secure Disclosure said plainly that it reached out to the vendor through two separate channels, email and LinkedIn, and "we have not been able to receive any response." That silence is now part of the disclosure itself.
Standard corporate vulnerability management runs on CVE numbers. Scanners check known-vulnerability databases, procurement checklists reference CVE identifiers, and patch cadences get tracked against them. A flaw with no CVE simply does not appear in any of that tooling, which means an organization can run a fully compliant vulnerability-management process and still have zero visibility into a live, remotely triggerable kernel exploit sitting in its device fleet.
For a European business with a BYOD policy, or one that issues budget or mid-range Android handsets to staff, the practical response cannot wait for a scanner alert that has nothing to scan for. Procurement and device-management teams should check today, by device model and chipset, whether any Unisoc T612 hardware is in use, rather than waiting for a CVE entry that may not arrive on any predictable schedule.
None of this means a patch will never come. It means that, for now, the only reliable way to know whether a fleet is exposed is to look directly at what hardware is deployed, because the usual early-warning system has nothing to warn on.
Read next: Google Stopped Absorbing Your Memory Price | Two Open-Source Tools Fell Within Hours
