An unchecked cast turns a 5-byte header into a negative array size

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.

Remote, silent, and recoverable only with effort

• Zero-click. The victim does nothing. No tap, no open, no notification.
• Silent. Nothing appears in Messages; the attacker's number is never shown.
• Calls drop, including emergency calls. Active voice calls terminate with DisconnectCause CS_DEATH as the process restarts.
• Telephony blackout. 1-2 seconds of no service per message while com.android.phone restarts.
• Carrier redelivery amplifies it. Unacknowledged messages are re-sent by the carrier, re-crashing the phone; a single message caused intermittent outages for up to a week in testing.
• ~20 messages render the device unusable for an extended period.
• Persistent denial of service. Rapid repeated delivery corrupts the SQLite database behind SMS storage, turning a momentary crash into a phone that crashes on every boot (detailed below).

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

From a 2-second crash to a bricked phone: the SQLite race

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:

• Removing the physical SIM and inserting it into a non-Android device (e.g. an iPhone) so the carrier's retried messages are acknowledged and stop being redelivered;
• Then clearing the SMS records / corrupt database over ADB.

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.

A remote attacker can cut a phone off from Triple Zero

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 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

One bounds check

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;

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.

• 5 May 2026ResearcherReport filed: zero-click WAP Push crash in WapPushOverSms (issue 509520497). Suggested fix provided the same day.
• 5 May 2026Android SecurityAssigned for investigation; researcher asked to follow coordinated disclosure.
• 15 May 2026ResearcherRequests higher priority: reproduced on 5 handsets, emergency-call impact, Australian carrier regulations.
• 20 Jun 2026Android SecurityClosed Won't Fix (Infeasible): "not a security vulnerability."
• 20 Jun 2026ResearcherClarifies this is a remote permanent DoS; ~20 messages permanently disable the phone. Resubmits as appeal (issues 525810560 and 525816147, "SMS of DEATH").
• 20 Jun 2026Android SecurityResubmit 525810560 closed within 3 minutes Won't Fix (Not Reproducible).
• 22 Jun 2026ResearcherReports SQLite corruption from rapid sends → crash on boot; recovery needs SIM swap to a non-Android device + ADB.
• 23 Jun 2026Android SecurityRequests disclosure plans; reminds of the 90-day VRP timeline and asks to review any write-up in advance.
• 23 Jun 2026ResearcherAgrees to hold for public safety; offers to brief Australian carriers so they can schedule a block. Restates the one-line fix.
• 2-3 Jul 2026Android SecurityAppeal marked Duplicate of the original; re-evaluation confirms same root cause.
• 16 Jul 2026Android SecurityOriginal reopened after the issue surfaced on Discord, then confirmed a duplicate again.
• 16 Jul 2026ResearcherAdds detail: the behaviour meets the VRP's own "Destructive Remote DoS" criterion.
• 17 Jul 2026Android SecurityAcknowledges the extra context; triage to take another look: "4 engineers will have evaluated the report."
• 27 Oct 2026ResearcherRequests a status update after three months of silence.
• 29 Oct 2026Android SecurityFinal decision: Won't Fix, quoting "does not meet the severity threshold ... considered a Non-Security Issue (NSI)."

Source & APK

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.