Zero-Click Malformed WAP Push SMS Crashes Android Telephony

A malformed WAP Push SMS can remotely crash com.android.phone on Android without user interaction, according to a report by independent researcher Mark Blaszczyk. The crash can drop active calls, including emergency calls, and repeated delivery may corrupt SMS storage and make a device persistently unusable. Google classified the issue as a non-security issue after review.

Technical cause

When Android receives a WAP Push message, WapPushOverSms.decodeWapPdu() reads the WSP header length as a uintvar. The value returns as a long, is cast to int without a range check, and is used as the size of a new byte array. A 5-byte uintvar of 88 80 80 80 00 decodes to 0x80000000, which becomes -2147483648 as a signed 32-bit int. Allocating new byte[-2147483648] throws an uncaught NegativeArraySizeException on the telephony main thread, killing com.android.phone. The message is delivered as a data SMS and is not shown to the user.

Impact and recovery

The message is zero-click and silent. Nothing appears in Messages and the sender's number is not shown. Calls drop, including emergency calls, with active voice calls terminating as the process restarts. Telephony is unavailable for about 1 to 2 seconds per message while com.android.phone restarts. Carrier redelivery can repeat the crash; a single message caused intermittent outages for up to a week in testing, and about 20 messages rendered a device unusable for an extended period. Rapid repeated delivery can corrupt the SQLite database behind SMS storage, causing com.android.phone to crash on every boot. Recovery required removing the physical SIM to a non-Android device so retried messages are acknowledged, then clearing SMS records over ADB. With an eSIM, recovery would be significantly harder.

The report says a device under this attack cannot reliably call 000. It cites Australian carrier obligations under the Telecommunications (Emergency Call Service) Determination, administered by ACMA, and says Telstra states it is required to block phones that can no longer call 000, notifying the customer and blocking the device if nothing is done within 28 days.

Disclosure and status

Mark Blaszczyk filed the report on 5 May 2026 through the Android and Google Devices VRP and resubmitted it twice as a mis-triage appeal. Google assigned it, closed it as Won't Fix (Infeasible) on 20 June 2026, closed a resubmission as Won't Fix (Not Reproducible) within three minutes, and on 29 October 2026 made a final decision of Won't Fix, quoting that it does not meet the severity threshold and is considered a Non-Security Issue (NSI). The disclosure says it was held beyond the VRP's 90-day window.

The proposed fix is a range check before the cast in WapPushOverSms.java: read the value as a long, reject values below 0 or above pdu.length, return an error result, then cast to int. The proof of concept and source code are published on GitHub; the warning says it is for authorised testing only.

Sources: smsofdeath.com