One WAP Push SMS crashes Android below the October 2026 patch

A single malformed WAP Push SMS crashes com.android.phone on Android with no interaction from the victim, and it keeps crashing the phone after that. The message never appears in the inbox, the sender’s number is never shown, and any active call drops the moment the telephony process dies. Below the October 2026 patch level the bug reproduced 100% of the time across the hardware the reporter tested: a Pixel 9 on April 2026 firmware and a range of Samsung Galaxy and A-series handsets.

The flaw is a signed-integer problem in length handling. When Android receives a WAP Push message, WapPushOverSms.decodeWapPdu() reads the WSP header length as a uintvar. The decoder returns a long, which is cast straight to int with no range check and then used as the size of a new array:

int headerLength = (int) pduDecoder.getValue32();
...
byte[] header = new byte[headerLength];

A five-byte uintvar of 88 80 80 80 00 decodes to 0x80000000. As a signed 32-bit int that is -2147483648, and new byte[-2147483648] throws an uncaught NegativeArraySizeException on the telephony main thread. The stack walks back through decodeWapPdu to InboundSmsHandler.processMessagePart, and com.android.phone dies.

Because the payload is delivered as a data SMS on port 2948, nothing surfaces to the user: no notification, no inbox entry, no sender number. The victim does nothing and sees nothing while the telephony stack restarts for one to two seconds per message. Active voice calls terminate with DisconnectCause CS_DEATH.

The persistence is what turns a crash into a weapon. An unacknowledged message gets re-sent by the carrier, which re-crashes the phone; the reporter saw a single message cause intermittent outages for up to a week. Around twenty messages render a device unusable for an extended period. The malformed message also stays queued in the pending inbound table and is retried on every boot, so the phone can crash during startup. On Android 12 that produces a reboot loop: Android’s RescueParty reboots into recovery roughly every ninety seconds, and the standard recovery prompt offers a wipe-data option a non-technical user is likely to take.

Recovering a device mid-loop

Recovery without a factory reset is possible but needs a computer and ADB. The poison rows live in content://sms/raw with destination_port=134020. In the short window after sys.boot_completed goes to 1, you query that table, note the sender address, temporarily grant the shell WRITE_SMS, and delete only those rows:

adb shell content query --uri content://sms/raw --projection _id:destination_port:date:deleted
adb shell cmd appops set com.android.shell WRITE_SMS allow
adb shell "content delete --uri content://sms/raw --where \"address='<SENDER>'\""
adb shell cmd appops set com.android.shell WRITE_SMS default

Clearing com.android.providers.telephony is the last resort, and it erases all SMS/MMS and APN settings. This recovery is credited to @sakisdog. For someone stuck in the loop without a laptop, none of it is reachable.

The emergency-call problem

The report classifies this as a destructive remote DoS, not a nuisance, because of what it does to emergency calling. While a device is under attack or stuck in the reboot loop, it cannot reliably dial emergency services. In Australia, access to Triple Zero is a mandatory property of a mobile service under the Telecommunications (Emergency Call Service) Determination, administered by the ACMA. Telstra states it is required to block phones that can no longer call 000, notifying the customer and blocking the handset if nothing is done within 28 days. An attacker who can remotely induce that condition can get the victim’s own device barred from carrier service until it is patched. The framework was tightened in 2024 after the 3G shutdown left some phones able to make ordinary calls but not emergency ones, which is the same functional state this bug produces on demand.

Google’s fix

The reporter sent Google a fix on the day of the first report, 5 May 2026: validate the length before the cast and reject anything negative or larger than the PDU. Google took a different route. On 15 June 2026, commit 735d967, “Fix remote DoS in decodeWapPdu,” widened the caught exception from ArrayIndexOutOfBoundsException to RuntimeException so the crash is swallowed, and made a failed decode delete the triggering message so it cannot re-crash on redelivery or boot. That shipped in the October 2026 Android security release for Android 14 through 17. Devices at the October 2026 patch level or later are protected; anything on an earlier patch level is not.

For a fleet, the detectable signature is a com.android.phone crash logging NegativeArraySizeException in WapPushOverSms.decodeWapPdu, plus the presence of rows with destination_port=134020 in content://sms/raw. The patch is the only durable fix; the ADB cleanup only buys time on an unpatched device already in the loop. The working proof-of-concept Android app and source are published on GitHub under Apache 2.0, for authorised testing only. Mark B reported the bug to the Android & Devices VRP on 5 May 2026; the public writeup landed on 29 October 2026.