A single text message that never appears on screen can knock an Android phone off the mobile network, again and again, and end running calls, emergency calls included. Google fixed the flaw, CVE-2026-58882, in its November bulletin. For companies with Android devices, the job now is to make sure the fix has actually arrived.
What happens
The flaw sits in Android's telephony framework, the part of the system that handles calls and SMS. The researcher who found it sends a malformed WAP Push message as a data SMS to port 2948. Android processes such messages before anything reaches the messaging app, so there is no notification and no sender to see. A length value in the message header turns negative, the error is not caught, and the phone process com.android.phone crashes.
Each crash takes the phone off the network for one to two seconds and ends any call in progress. The real problem is that the message stays queued. Android processes it again after every restart, and the network delivers messages that were not acknowledged once more. In the researcher's tests one message caused outages for up to a week, and around twenty made a device practically unusable. On Android 12 a device kept restarting into recovery mode about every 90 seconds.
Google rates the flaw as critical. Its own entry describes the cause a little differently, as an out-of-bounds read after an integer overflow, but the effect is the same. It allows a denial of service, not code execution or access to data, and no attacks have been reported so far. A proof of concept is public, though, and all it needs is the phone number.
Which devices are affected
The researcher reproduced the crash on Android 12 to 16, among others on a Pixel 9 and on Samsung Galaxy S and A models, and lists Android 17 as affected too. Google's bulletin names Android 14, 15, 16 and 17, the versions it still supports. Android 12 and 13 are therefore affected but get no fix from Google.
What counts is the security patch level shown in the device settings, not the Android version. Google lists the fix under patch level 2026-11-01. It is not delivered as a Google Play system update, so it only arrives with the firmware from the device maker. Samsung included it in its November update on 3 November, with rollout depending on model and region. GrapheneOS has shipped it in its regular releases since 2026110100.
Some reports and guides, among them an article by a German IT service provider, treat the October patch level as sufficient, and the researcher also says the October builds contain the fix. But the October bulletin does not list it, so we would not use 2026-10-01 as the threshold.
Why companies should care
A phone that keeps dropping off the network is more than an annoyance when people depend on it: on-call staff, field technicians, anyone who works alone, anyone whose phone is their second factor. That emergency calls are dropped too makes it a safety issue for lone workers.
The recovery is a trap as well. A device stuck in a restart loop offers to wipe its data, and someone at a busy help desk may choose exactly that. heise and the researcher describe how to remove the message without a reset.
What to do now
- Raise the minimum patch level in your device management. In Intune or any other MDM, set the minimum Android security patch level to 2026-11-01 and look at which devices fail the check.
- Follow the rollout per model. Each maker ships the update on its own schedule. Check Samsung, Google and your other vendors for every model you use, and expect stragglers.
- Make sure devices restart. An update that has been downloaded but not installed protects nothing. Check that devices actually reboot instead of postponing it.
- Start with the phones that matter most. Devices for on-call duty, field work and lone working come first. If a device runs Android 12 or 13, ask the maker about a fix or replace it.
- Prepare the help desk. A phone that keeps losing its connection or restarts into recovery mode is not wiped but escalated. The researcher's recovery steps need USB debugging, so decide in advance how to do this on managed devices. As a precaution, do not put the SIM of an affected phone into another unpatched one.
- Keep a second channel. For people who must be reachable, a second way to call for help limits the damage from this flaw and the next one.
Questions about your fleet of mobile devices? Pentesting and consulting →