Zero click, silent, remote Android DoS

Android Telephony · Zero-Click · Remote DoS

A single malformed WAP Push SMS crashes com.android.phone on Android, dropping active calls (including emergency calls), with zero interaction from the victim.

Download APK

Source

Google Issue Tracker

⚠ Working proof-of-concept, authorised testing only. Read the warning & license before downloading.

When Android receives a WAP Push message, WapPushOverSms.decodeWapPdu() reads the WSP header length as a uintvar. The value comes back as a long, is cast to int with no range check, and is then used directly as the size of a new byte array:

// WapPushOverSms.java:217 header length read as long, cast with no bounds check int headerLength = (int) pduDecoder.getValue32(); ... // WapPushOverSms.java:244 the cast value is used as an array size byte[] header = new byte[headerLength];

A 5-byte uintvar of 88 80 80 80 00 decodes to 0x80000000. Cast to a signed 32-bit int, that is -2147483648. Allocating new byte[-2147483648] throws an uncaught NegativeArraySizeException on the telephony main thread, killing com.android.phone:

E AndroidRuntime: FATAL EXCEPTION: main E AndroidRuntime: Process: com.android.phone E AndroidRuntime: java.lang.NegativeArraySizeException: -2147483648 E AndroidRuntime: at ...WapPushOverSms.decodeWapPdu(WapPushOverSms.java:244) E AndroidRuntime: at ...WapPushOverSms.dispatchWapPdu(WapPushOverSms.java:339) E AndroidRuntime: at ...InboundSmsHandler.processMessagePart(InboundSmsHandler.java:1169) E AndroidRuntime: at ...InboundSmsHandler$DeliveringState.processMessage(InboundSmsHandler.java:627)

The message is delivered as a data SMS and is never shown to the user: there is nothing in the inbox, and the victim never sees the sender's number.

Tested across multiple makes and models (Pixel 9 on April 2026 firmware, various Samsung Galaxy and A-series) with a 100% reproduction rate.

A single message is a repeated transient outage. Sending the payload rapidly in succession (≈30 messages) is materially worse: the crashes interleave with the telephony provider's writes to the SMS store and hit a race condition that corrupts the SQLite database holding the device's messages.

Once the database is corrupt, com.android.phone no longer needs a fresh message to fail: it crashes immediately on every boot as it reads the damaged store. The phone is now persistently without telephony, and a restart does not clear it.

Recovery is hostile, and this is the critical part: a factory reset only helps temporarily, because the carrier re-sends the unacknowledged payload and re-triggers the crash. Full recovery required:

On a device using an eSIM, where the SIM can't simply be moved to another handset, recovery would be significantly harder, and for a non-technical user, effectively out of reach.

This is the distinction the report turns on. It is not a transient crash: it is a remote, zero-click, persistent denial of service requiring a factory reset (and more) to recover, which is the exact shape of a "Destructive Remote DoS" in the VRP's own rules.

Dropping calls is not an inconvenience when one of those calls is to emergency services. While a device is under this attack, or bricked by the SQLite corruption, it cannot reliably place a call to 000. The attack is remote, needs only the victim's number, and shows them nothing.

Australia treats access to emergency calling as a mandatory property of a mobile service, not a nice-to-have. Under the Telecommunications (Emergency Call Service) Determination, administered by the ACMA, carriers are required to identify mobile phones that cannot reach Triple Zero, help the customer move to a working device, and stop providing service to the affected handset. Telstra states plainly that 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.

The consequence is perverse: the regulatory remedy for a phone that can't reach 000 is to cut it off the network, not to patch the OS. So an attacker who can remotely induce that condition on an Android handset can, in effect, get the victim's own device barred from carrier service until a fix exists. The regulation exists precisely because loss of emergency-call access is considered a public-safety failure; this bug manufactures that failure on demand.

The framework was tightened in 2024 following the 3G shutdown, which left some phones able to make ordinary calls but unable to reach emergency services, the same functional state this vulnerability produces.

Sources: ACMA: proposed amendments to the ECS Determination · Telstra: Emergency Call Service Determination · Dept. of PM&C: impact analysis

The remedy is a range check before the cast in WapPushOverSms.java (line 217), provided to Google on the day of the first report:

long rawHeaderLen = pduDecoder.getValue32(); if (rawHeaderLen < 0 || rawHeaderLen > pdu.length) { result.statusCode = Intents.RESULT_SMS_GENERIC_ERROR; return result; } int headerLength = (int) rawHeaderLen;

05 / Disclosure timeline Communication with Google

The report was filed through the Android & Google Devices VRP and resubmitted twice as a mis-triage appeal. Across three tickets and four engineers, Google classified it as a non-security issue.