Android "SMS of Death": one WAP Push text kills the phone process, about 20 reboot it into a loop — fixed in Android 14–17, while 12 and 13 stay exposed
Disclosed October 29: a single WAP Push SMS silently crashes the Android phone process and cuts emergency calls; the fix reaches Android 14–17 only.
Security researcher Mark B (@sourone on X) published the Android remote denial-of-service vulnerability now being called “SMS of Death” on October 29: a single data SMS addressed to WAP Push port 2948 crashes the system’s com.android.phone process with zero interaction and no trace in the inbox, and about twenty messages in a row push a phone into a reboot loop with all calls — emergency calls included — cut off. The fix shipped in the October 2026 Android security update for Android 14 through 17; Android 12 and 13 are past their security support window and will never receive it. Media coverage refers to the flaw as CVE-2026-58882; when we checked the MITRE CVE API and the CVE Program’s list repository on November 2, neither had a record under that number, and the researcher’s own writeup names no CVE at all — so this entry treats it as a media-cited identifier, not an officially assigned one.
Key points
- The trigger: a malformed WSP header length decodes from uintvar encoding to 0x80000000, which is -2147483648 as a signed int;
WapPushOverSms.decodeWapPduuses it as a byte-array size, throws an uncaught NegativeArraySizeException, and the phone process dies (per the smsofdeath.com writeup). - The damage: each message causes 1–2 seconds of no service and kills in-progress calls; around twenty can render a device unusable for an extended period. The poisoned message stays in
content://sms/rawand replays on every boot, with RescueParty rebooting the device into recovery mode roughly every 90 seconds. - The fix boundary: it is in the October 2026 Android security update for Android 14–17 only, and per Android Authority’s October 30 report the flaw was not listed in the October security bulletin.
How the crash works
The bug lives in old telephony-framework code that handles WAP Push — a carrier-era feature where an ordinary data SMS is addressed to port 2948 and WapPushOverSms parses it into a push payload. That parsing happens before anything reaches the inbox, which is why the whole attack is invisible: the sender’s number never shows, and no message appears.
The chain is short. The WSP header length is decoded from uintvar encoding into a long, then cast to an int with no range check and used as the size of a byte array. The researcher’s five-byte sequence 88 80 80 80 00 decodes to 0x80000000 — -2147483648 when read as a signed int — so the allocation throws NegativeArraySizeException on the telephony main thread. Nothing catches it, the entire com.android.phone process is killed, and calls drop with a DisconnectCause of CS_DEATH while the process restarts.
The message itself is the stubborn part. At the moment of the crash it is still sitting in the pending inbound queue at content://sms/raw, so every boot replays it and crashes again. Android’s RescueParty machinery keeps tripping, rebooting the device into recovery mode roughly every 90 seconds — the point where an ordinary user reaches for a factory reset. In the researcher’s testing, one message kept a phone dropping off the network intermittently for up to a week, because carriers redeliver the poisoned message. Reproduction was 100% on a Pixel 9 (April 2026 firmware) and various Samsung Galaxy and A-series models; the faulty code has shipped in many Android releases and dates back to at least Android 12 (per Android Authority).
The disclosure timeline
Half the value of this disclosure is the vulnerability; the other half is the process it exposes. The researcher reported it to Google through the Android & Devices VRP on May 5. Android’s code records show the fix was authored on June 15 (commit 735d967, “Fix remote DoS in decodeWapPdu”). It shipped in the October security update for Android 14–17. The public writeup waited until October 29, when it landed together with a working, Apache-2.0-licensed PoC (GitHub repo MarkBlah/smsofdeath, at 417 stars as of November 2).
| Item | Detail | Source and date |
|---|---|---|
| Reported | 2026-05-05, via Android & Devices VRP | smsofdeath.com |
| Fix authored | 2026-06-15, commit 735d967 | Android code records (via Android Authority) |
| Fix shipped | October 2026 security update, Android 14–17 | smsofdeath.com; BleepingComputer |
| Public disclosure | 2026-10-29, with a PoC | smsofdeath.com; GitHub |
| Media-cited CVE | CVE-2026-58882; no record in MITRE API or cvelistV5 on 11-02 | BleepingComputer; Android Authority |
Google declined the author’s proposed bounds check (reject a length that is negative or exceeds the PDU) and instead widened the caught exception type to RuntimeException, plus deleting the poison message from the raw table — which breaks the boot-loop replay. Any device at or above the October 2026 patch level is protected.
What others say
Android Authority’s October 30 report adds the detail that makes the process story sting: Google had repeatedly dismissed the report as a non-security issue, even though the dates it cites put the fix about six weeks after the report (May 5 to June 15). The piece suggests an internal communication breakdown or a duplicate report, and says the flaw is “apparently slated” for the November security bulletin. GrapheneOS’s account fits the vendor timeline: it received the fix in July security previews and says the fix is scheduled for the November bulletin. The two accounts can coexist — vendors receive fixes before bulletins publish — but the October bulletin genuinely omitted the flaw, and which account is right won’t be verifiable until the November bulletin ships. BleepingComputer independently confirmed the core event on October 31, likewise noting the bulletin omission and the missing fix for Android 12/13; Digital Trends and other outlets’ follow-ups match the same numbers. Google had not responded publicly as of this writing, and Android Authority said it would update if Google comments. We could not fetch Android Authority’s full text (the page came back incomplete), so the “non-security issue” phrasing is quoted from its summary.
Our take
What this means for you depends almost entirely on your device’s patch level. The one-minute check: open Settings, look at Android version and security update — a patch level of 2026-10-01 or higher means you’re fixed. Devices stuck on Android 12 or 13 have no official path out; Google’s security support for them has ended, and no update will carry the fix. That is a large installed base, and the cost of attack is close to zero — one ordinary Android phone and a public PoC.
The shape of the harm matters too. This bug steals nothing and needs no permission; it cuts calls and texts, which lands hardest on people who depend on SMS verification codes and incoming-call notifications, and on families that hand old phones down as backup devices. The emergency-call angle even has regulatory teeth in Australia: the researcher points out that the ACMA’s Emergency Call Service Determination requires carriers to identify phones that cannot reach Triple Zero (000) and stop their service, and Telstra says it must block such handsets if unresolved within 28 days — meaning the flaw can get a victim’s device barred from the carrier network entirely. Two things remain open: whether the November bulletin formally lists the fix, and who, if anyone, backs the exposed Android 12/13 fleet. When we covered the Microsoft Authenticator zero-permission flaw in late October, the dispute was the gap between a shipped fix and public details; this time the anomaly is that the fix existed and still missed its own bulletin. For people on unpatched devices, the community-found stopgap is deleting the poisoned rows from content://sms/raw (identifiable by destination_port=134020) with ADB in the brief window after boot, contributed by GitHub user @sakisdog — it takes a computer and some technical skill, and the “wipe data” option in recovery should be avoided, because that step is irreversible.