Vulnerabilities

On October 29, independent researcher Mark Blaszczyk published details and a proof-of-concept app for a bug he calls the "SMS of Death". A single malformed WAP Push message, a type of data SMS the user never sees, crashes the com.android.phone process. Every crash cuts mobile service for one to two seconds and ends any active call, emergency calls included. He reproduced it on a Pixel 9 and on several Samsung Galaxy phones, including A-series models.

Google treated the report as a non-security issue from May until the end of October, yet it shipped a fix. Its November 2026 Android Security Bulletin, published November 2, lists the bug as CVE-2026-58882, a Critical denial of service in the System component, fixed at patch level 2026-11-01 for Android 14, 15, 16, 16 QPR2 and 17. If you manage Android phones that staff rely on for calls, that is the number to enforce now.

How it works

WAP Push is an old mechanism carriers use to send configuration and MMS notifications to phones as binary SMS. Android hands every incoming WAP Push message to WapPushOverSms, part of the telephony framework in frameworks/opt/telephony, before any messaging app is involved. That is why the attack needs no click and leaves nothing in the inbox, no notification and no sender number.

Inside decodeWapPdu(), the code reads the Wireless Session Protocol (WSP) header length, which is encoded as a variable-length integer, into a 64-bit long. It then casts that value to a 32-bit signed int without checking its range and uses it as the size of a byte array. A crafted length becomes negative after the cast, so the allocation throws NegativeArraySizeException. Nothing catches it on the telephony main thread, and the phone process dies. Reports put the whole payload at eight bytes, five of which encode that one length field.

A crash on its own lasts seconds. The persistence makes it worse:

1. The phone never acknowledges the message, so the carrier redelivers it. In the researcher's tests, one message caused intermittent outages for up to a week.
2. The message also sits in Android's pending inbound queue, the content://sms/raw table, and Android retries it at every boot.
3. With repeated crashes, Android's Rescue Party recovery feature reboots the phone into recovery mode, roughly every 90 seconds according to the write-up.

Blaszczyk reports that about 20 messages sent quickly left a phone unusable for a long time; one report gives the figure as 20 to 30. He attributes the lasting damage to a race condition that corrupts the SMS database, which he describes as his assessment rather than a demonstrated result. A factory reset gave only temporary relief, because the carrier delivered the queued messages again.

Google's fix does not add the length check the researcher proposed. It widens the exception handling during WAP Push decoding to catch any RuntimeException, and deletes the malformed message from the raw queue so it cannot be replayed.

What attackers are doing

No source reports use in the wild, and the November bulletin carries no exploitation note for any entry. What changes the risk is that a working sender app and its source code are public on GitHub, and sending the message needs only the ability to send a binary SMS to a phone number. Anyone with a list of staff mobile numbers can knock those phones off the network repeatedly.

The disclosure timeline explains why many fleets are still exposed. Blaszczyk reported the bug on May 5 and says Google repeatedly classed it as non-security, most recently on October 29. Android's code history shows a fix written on June 15, and GrapheneOS says it received that fix through Google's July security previews for device makers.

Which patch level fixes it

Sources disagree here. The researcher and several outlets say the fix shipped in the October 2026 release for Android 14 to 17. The October bulletin, however, does not list CVE-2026-58882, and the November bulletin does, at 2026-11-01. GrapheneOS also said the bug would appear in the November bulletin. Some October builds may already contain the code change, but only 2026-11-01 is documented, so use that as your compliance value.

Android 12 and 13 are affected too: eSecurityPlanet lists Android 12 to 16, and the looping phone in the researcher's recovery case ran Android 12. But Google's bulletin only covers Android 14 and later. Those phones get no official fix unless their maker backports one.

What to do

Enforce 2026-11-01

In Microsoft Intune, open Devices, then Compliance, and edit your Android Enterprise policy. Set Minimum security patch level to 2026-11-01 (Device properties for fully managed, dedicated and corporate-owned work profile devices; System security for personally owned work profiles). Other Android Enterprise MDM tools have the same field.

Vendor rollout varies by maker, model and carrier. For groups where the November build is still arriving, set the value once your MDM shows the November build on most of each model, with a short grace period before Conditional Access blocks work apps.

Phones that cannot be patched

Export a report of devices on Android 12 or 13, or below 2026-11-01 with no November build offered, and prioritise replacing the ones used by on-call staff, field workers and anyone who works alone. No setting on the phone blocks the payload. Samsung Messages has a WAP Push switch, but no source confirms it stops this bug, and parsing happens in the telephony framework first.

Carrier filtering is the remaining lever. No carrier has announced a filter for this message, so ask your mobile operator's business account team whether their SMS firewall can drop inbound WAP Push from external senders on your corporate lines, and what it would break, such as MMS notifications or carrier configuration pushes.

Check whether phones were hit

The signs are user reports of calls dropping or "no service" for a second or two, or a phone booting into recovery by itself. On a suspect phone, take a bug report (Developer options, Take bug report) and search it for FATAL EXCEPTION naming com.android.phone with NegativeArraySizeException.

Recover a looping phone

Do not choose "Wipe data" at the recovery prompt; a reset does not clear what the carrier still holds. The researcher's recovery uses Android Debug Bridge (ADB) from a computer in the short window after boot to delete the offending rows from the pending SMS queue. The last-resort command in his write-up erases all SMS, MMS and access point name (APN) settings, so have the carrier's APN details ready. Then install the November update before the phone goes back into service.

Our safeguarding and hardening team sets up MDM compliance rules like the one above, and our mobile penetration testing covers the apps and devices your staff carry. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Android Security Bulletin, November 2026, Android Security Bulletin, October 2026, eSecurityPlanet, CyberInsider, Cybernews, Android Authority, braindetox technical analysis, BornCity, Phonandroid, Android Rescue Party documentation, Microsoft Intune Android Enterprise compliance settings.