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.
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.
DisconnectCause CS_DEATH as the process restarts.com.android.phone restarts.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;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.
WapPushOverSms (issue 509520497). Suggested fix provided the same day.Why this is public. The issue was reported privately and held well beyond the VRP's 90-day window. Google declined to fix it across three tickets and four engineers, classifying a remote, zero-click, emergency-call-dropping denial of service as a non-security issue. Full disclosure follows so that users, carriers and downstream OEMs can assess the risk and mitigate.
The proof-of-concept Android app and full source code are published on GitHub. The app crafts the malformed WAP Push PDU and sends it as a data SMS to a target number.
For security research and defensive testing only. Sending disruptive messages to devices you do not own or have permission to test is illegal in most jurisdictions. Interfering with emergency communications is a serious crime. Use responsibly.