The Android patch does not reach the modem

When someone tells us their phone fleet is up to date, what they usually mean is that Settings shows a recent date. Yesterday a piece of research turned that date into a question: Android can carry two patch levels in the same month, the second one is what covers the modem, and the phone only shows you whichever one it was given.

Up front: we maintain IT estates and we sell that service, so the part where we say you need to inventory your handsets should be read with an eyebrow raised. Everything else is in public documents anyone can open, and the links are at the end.

What was published on 17 August

SSD Secure Disclosure published the second instalment of a chain that started in March, when the same researcher showed how to run code in the modem firmware of several Unisoc chips by sending malformed SDP inside the SIP signalling of a video call. Yesterday's instalment goes from the modem to the system: from the modem context, protection on the first region of the memory protection unit is switched off, and from there you get read and write access to physical memory, kernel code included. It is classified as CWE-1189, "improper isolation of shared resources on a system-on-chip", and the advisory's wording is as blunt as it gets: from the modem context there is no isolation between modem memory and kernel memory.

The chips listed as affected in the March advisory are the T606, the T612, the T616 and the T7250. Chaining the whole thing requires three things: March's bug as a starting point, VoLTE infrastructure controlled by the attacker, and the victim answering the incoming video call. There is no patch and no published mitigation, and the advisory itself says they tried to reach the vendor "through multiple channels (email and LinkedIn)" without getting an answer.

With those requirements, this is not a mass campaign. It is targeted-attack material — it needs a presence on the radio network — against someone worth the trouble. What stayed with us is something else, and it sits in the list of phones they tested it on.

The dates on the three test phones

The advisory lists them with their patch level: a Xiaomi Redmi A5 on 2026-01-01, a Motorola E13 on 2025-02-01, and a Realme C33 on the July 2025 patch. The first two come with the full date, and there sits the detail almost nobody looks at: both of them end in -01.

That suffix is not the day of the month. It is the level. Google publishes the full bulletins with two of them — in 2026 that means March, April and June — and explains why in plain terms: "this bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly". The first level, -01, covers the Framework and System sections: the parts common to any Android, whoever made the silicon. The second, -05, adds the kernel and the vendor components. In the June 2026 bulletin that list reads Imagination Technologies, MediaTek, Qualcomm and Unisoc.

There is a second, more awkward reading in those same dates. The Motorola E13 they tested was on the February 2025 level: eighteen months before the day the research went out. The Realme, thirteen. We do not know whether the manufacturer stopped publishing updates or nobody installed them, and both explanations have the same practical effect and the same owner: somebody who bought a phone and assumed the rest.

Seven in March, sixteen in June

Here we have to argue against the easy headline, because Unisoc is not outside the system: it has its own section in the Android bulletins, just as Qualcomm and MediaTek do. The March 2026 bulletin carries seven Unisoc CVEs and all seven are in the Modem subcomponent, every one rated High. June 2026 carries sixteen, again all modem, again all High. The modem does get patched, though not monthly: across 2026's eight bulletins, Unisoc shows up in two of them, March and June. It comes in batches.

And that is exactly why yesterday's case matters rather than being an anecdote. A bug with a CVE goes into a bulletin, has a date, can be searched for, shows up in any patching inventory and eventually closes on its own. A bug with no CVE, published by a third party with the vendor silent, matches no entry in any catalogue, raises no alert, and has no version number you can demand from anyone. Administratively it does not exist, and what does not exist does not get managed.

The fix has to pass through three hands

On a laptop the chain is short: whoever makes the operating system and whoever makes the machine. On a phone there is one more link, and it is the one that decides things here. Google collects and publishes, but about vendor components it says, word for word, that "these vulnerabilities affect Unisoc components and further details are available directly from Unisoc" and that "the severity assessment of these issues is provided directly by Unisoc". Then the phone maker has to package that into an update and ship it. Three hands, and it only takes one of them not moving.

One figure from the bulletin helps calibrate timing: Google notifies its Android partners of every issue "at least a month before publishing the bulletin". That month is the window in which a handset maker can have the update ready on day one. When they do not, the count stops being measured in weeks.

It is the same shape of problem we wrote about in who can switch off your servers: the company that decides the fate of your kit is not the one that sold you anything. There it was whoever owns the room; here it is whoever makes a chip whose name is not on the phone's box. In both cases the lever you think you have — the invoice — points at someone who cannot fix it.

How this chip gets into your company without anyone deciding

Nobody picks a modem. People pick a price. According to Counterpoint, Unisoc rose to 15% of the global smartphone chipset market in Q4 2025, up from 14% in the same quarter a year earlier, and kept growing through the first half of 2026 while Qualcomm and MediaTek shipped more than 25% fewer units year on year. The firm's explanation is straight out of a procurement manual: entry-level models are migrating to Unisoc 4G platforms to cut the bill of materials, and MediaTek took the hit in low-end 5G because of the memory price crisis. The context matters: the chipset market as a whole was down 15% year on year that half.

Translated into a mid-sized company: the eighty- or hundred-euro handset bought for the warehouse operator, the delivery van, the clock-in app or the seasonal cover. That phone almost never goes through an IT decision. It arrives on an invoice for consumables, someone drops a SIM in it, and it is working. And because it is working, it has email on it.

The other half of it is where that phone goes. Yesterday's chain needs the attacker to control the VoLTE infrastructure, which pushes the conversation back to where we left it when writing about the carrier's private APN: mobile connectivity gets bought as if it were a cable, when it is actually a network with neighbours, with equipment in between, and with configuration somebody chose on your behalf.

Before somebody sells you an audit

If the fleet is iPhones and mid-range Samsungs, this particular chain does not affect you, and we are not going to pretend otherwise in order to sell an audit. It does not affect you either if the phones carry nothing belonging to the company. And if somebody offers you a mobile security audit today quoting this story, the right question is what exactly they intend to look at, because against this bug there is no patch to apply and no setting to correct: there is only knowing what you have.

Nor would we recommend pulling working phones out of service over this. The scenario asks for too many things at once. What we would recommend is that the next batch gets bought while looking at how many years of updates the manufacturer promises — a public figure that usually sits on the same page as the camera megapixels and that nobody reads.

Five things that are worth doing

• 1.Read the whole date, not the month. It is under Settings → About phone → Android version → Android security update. If it ends in -01, that handset is declaring nothing about that month's modem, kernel or GPU.
• 2.And read it at scale, not phone by phone. The property comes out of adb shell getprop ro.build.version.security_patch, and if you run device management the same value travels as an inventory field. One column in a spreadsheet beats thirty screenshots.
• 3.Add the model and the end-of-updates date to the phone inventory. The second one decides when the device gets retired, and it is the one nobody writes down on purchase day, because on purchase day it looks like a brochure figure.
• 4.Decide who is allowed to buy a phone that will carry company email. It is one line in the purchasing procedure rather than a security policy, and if a handset can arrive without passing through it, the rest of this list is pointless.
• 5.Separate task handsets from people handsets, and if one of them uses a named chip and travels somewhere sensitive, switch VoLTE and VoWiFi off on it until there is a fix. A warehouse phone needs no mailbox and no documents: whatever is not on the phone cannot be taken by whoever gets into the phone.

The third list

A few days ago, writing about a flaw in macOS screen sharing, we said that almost every company has a list of its machines and almost none has a list of what listens from outside. This case adds a third, and it is the strangest of them: what the things you own are made of. The chip before the model, and who publishes its fixes and for how long before the name on the box.

Nobody is going to maintain that list for every toaster in the office, and there is no need to. You need it for anything carrying a SIM card, a public IP address or customer data — which is usually a lot less than you fear and rather more than you remember.

Sources (verified on 18 August 2026): the chain published on 17 August 2026, the CWE-1189 classification, the absence of isolation between modem and kernel memory, the disabling of protection on the first region (ID 0) of the MPU, the T606, T612, T616 and T7250 chips listed as affected, the test devices with their patch levels (Xiaomi Redmi A5 on 2026-01-01, Motorola E13 on 2025-02-01 and Realme C33 on the July 2025 patch), the requirement for attacker-controlled VoLTE infrastructure and for the victim to answer the video call, and the line "we have tried to reach out to the vendor through multiple channels (email and LinkedIn) but have not been able to receive any response", from the "UNISOC T612 LPE" and "UNISOC T612 RCE" advisories (SSD Secure Disclosure), together with The Hacker News' coverage of 17 August 2026. The two patch levels and their contents, the quote "this bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly", the notification to partners "at least a month before publishing the bulletin", the sixteen Unisoc entries in the Modem subcomponent rated High, and the lines stating that further details and the severity assessment are provided directly by Unisoc, from the June 2026 Android Security Bulletin; the seven Unisoc entries in the Modem subcomponent, from the March 2026 bulletin; and the line "for some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2026-01-01 security patch level", from the January 2026 bulletin, which published only the 2026-01-05 level (Android Open Source Project). The count of which 2026 bulletins carry Unisoc entries and which published both levels is ours, done against those same pages. The 15% share in Q4 2025 against 14% a year earlier comes from Counterpoint Research's quarterly AP-SoC share tracker; Unisoc's growth through the first half of 2026, the year-on-year drop of more than 25% in Qualcomm and MediaTek shipments, the entry tier migrating to Unisoc 4G platforms to cut bill-of-materials costs and the 15% market decline, from their first-half 2026 analysis. The reading of the -01 suffix on the test devices, the eighteen- and thirteen-month arithmetic, the distinction between a bug with a CVE and one without, and every recommendation are ours. As of 18 August 2026 we have found no Unisoc statement about this research and no assigned CVE.