Security researcher Mark Blah has released a working proof-of-concept exploit for a newly disclosed Android vulnerability nicknamed “SMS of Death” and tracked as CVE-2026-58882. The bug allows a remote attacker to crash the com.android.phone process – and in some cases push devices into a reboot loop – by sending a single malformed WAP Push SMS.
Zero‑click crash in Android’s telephony stack
The flaw lives in Android’s core telephony framework, in WapPushOverSms.decodeWapPdu(). When a WAP Push message arrives, the code reads the WSP header length as a uintvar:
```java
int headerLength = (int) pduDecoder.getValue32();
byte[] header = new byte[headerLength];
``
There is no bounds check before casting the long to int. A specially crafted 5‑byte uintvar sequence 88 80 80 80 00 decodes to 0x80000000, which becomes -2147483648 as a signed 32‑bit int. When Android tries to allocate new byte[-2147483648], it throws an uncaught NegativeArraySizeException on the telephony main thread, killing com.android.phone.
To trigger it, an attacker can send this 8‑byte WAP Push PDU as a data SMS to port 2948:
01 06 88 80 80 80 00 BE
Because this is handled as a data SMS, nothing appears in the inbox and the victim never sees the sender’s number. The crash drops ongoing calls with DisconnectCause CS_DEATH, causes a 1–2 second “no service” window, and can be repeated at will.
Persistent DoS and reboot loops
The primary write‑up shows that carrier redelivery makes things worse: unacknowledged messages are retried, re‑crashing the phone. Around 20 malicious messages were enough to make devices effectively unusable. On at least one Android 12 handset, the phone entered a reboot loop into recovery roughly every 90 seconds, pushing non‑technical users toward a factory reset.
The root cause is that the malformed WAP Push messages remain queued in content://sms/raw and are reprocessed on every boot. GitHub contributor Sakis documented an ADB‑based recovery: temporarily granting WRITE_SMS to com.android.shell and deleting only the poisoned rows from content://sms/raw. This breaks the loop without wiping the device, but it requires a computer, ADB, and some expertise.
Which Android versions are affected?
According to the primary analysis, the vulnerable code path exists from Android 12 through 17. Google shipped a fix in the October 2026 Android security update for Android 14–17, but it is not listed in the public October bulletin. Devices stuck on Android 12 and 13 run the same vulnerable code and do not receive the patch.
Instead of adding a header‑length bounds check as suggested by the researcher, Google’s “Fix remote DoS in decodeWapPdu” commit widens exception handling to catch RuntimeException (including NegativeArraySizeException) and changes InboundSmsHandler so that a failed decode deletes the offending message from the raw SMS table, preventing repeated crashes and boot loops.
Why it matters
Because com.android.phone controls cellular connectivity, this is not just an annoyance. While a device is under attack or stuck in a reboot loop, it cannot reliably place calls – including emergency calls. In Australia, where regulators require carriers to block devices that can’t reach Triple Zero (000), a remote attacker could theoretically force an Android handset into a state where the carrier is obliged to bar it from the network until it is fixed.
With a public PoC now available and exploitation requiring only the victim’s phone number and SMS capability, Android users are strongly advised to:
- Install the October 2026 security update (or later) on devices running Android 14–17;
- Treat Android 12–13 devices as permanently at risk, especially in safety‑critical contexts;
- Avoid dismissing unexplained reboot loops as mere glitches – they could be signs of this or similar telephony‑layer attacks.
Source: Google, Gündəm · bleepingcomputer.com
