Google has declined to fix an Android flaw that lets a single invisible text message crash a phone’s calling service, and security researcher Mark Blaszczyk responded on Thursday by publishing full technical details and a working proof of concept.
Dubbed SMS of Death, the zero-click denial-of-service bug sits in WapPushOverSms, the part of Android’s telephony framework that processes WAP Push messages. Blaszczyk reported it through the Android and Google Devices Vulnerability Reward Program on May 5, 2026, and Google closed it for the final time on October 29 as a non-security issue. No CVE identifier has been assigned.
One malformed message kills com.android.phone, the system process that runs calling and cellular service, and drops any call in progress, including calls to emergency services. Blaszczyk said he reproduced the crash every time on a Pixel 9 running April 2026 firmware and on several Samsung Galaxy and Galaxy A-series handsets.
How Does One Text Crash an Android Phone?
WAP Push is a decades-old SMS format that carriers use for MMS notifications and configuration messages, and Android automatically parses it. When a WAP Push message arrives, the decoder reads the length of its WSP header as a variable-length integer, gets back a long, and casts it to a 32-bit int without checking the range. That value then sets the size of a new byte array.
// WapPushOverSms.java:217
int headerLength = (int) pduDecoder.getValue32();
// WapPushOverSms.java:244
byte[] header = new byte[headerLength];A five-byte header length field can encode 0x80000000, which becomes -2,147,483,648 once squeezed into a signed integer. Android then tries to allocate an array of negative size, throws a NegativeArraySizeException on the telephony main thread, and nothing in InboundSmsHandler catches it, so the whole phone process dies. The researcher’s crafted payload is just eight bytes long.
The attack needs nothing from the victim except a phone number. The payload travels as a data SMS addressed to the WAP Push port, so it never lands in the Messages app, shows no notification, and never reveals the sender. Each message knocks out cellular service for one to two seconds while the process restarts, and an active call ends with the disconnect cause CS_DEATH.
Why Doesn’t a Factory Reset Fix It?
Because the phone crashes before it can confirm receipt, the carrier treats the message as undelivered and keeps resending it. In Blaszczyk’s testing, a single message caused intermittent outages for up to a week, and about 20 messages left a device unusable for an extended period.
Sending around 30 in rapid succession does lasting damage. The crashes collide with the telephony provider’s writes to the SQLite database that stores SMS messages, resulting in a race condition that corrupts the database. From then on, com.android.phone crashes on every boot while reading the damaged store, with no new message required.
A factory reset clears the database, but the carrier redelivers the queued payloads, restarting the cycle. Blaszczyk only recovered his test phones by moving the physical SIM into a non-Android device, such as an iPhone, so the pending messages were acknowledged and stopped coming in, then wiping the corrupt SMS records via ADB.
He noted that phones using an eSIM, which cannot be moved to another handset, would be far harder to recover, and effectively unrecoverable for most non-technical owners.
The researcher framed the emergency-call risk around Australia, where carriers must identify handsets that cannot reach Triple Zero (000) and cut them off the network. Telstra blocks such devices if the customer takes no action within 28 days. Blaszczyk argued that an attacker who can induce that state remotely could, in effect, get a victim’s own phone barred from service.
Google’s handling of the report spanned three tickets and four engineers, according to the disclosure. The original issue was closed on June 20 as “Won’t Fix (Infeasible)”, and an appeal filed the same day was closed within three minutes as not reproducible. The report was later marked as a duplicate, briefly reopened in July after the issue surfaced on Discord, and then sent back to triage after Blaszczyk argued that it met the program’s own definition of a destructive remote denial-of-service.
The final decision came on October 29, two days after Blaszczyk asked for a status update following three months of silence. Google said the bug “does not meet the severity threshold” and classed it as a non-security issue. Blaszczyk had held the details past the program’s 90-day disclosure window and offered to brief Australian carriers before going public.
The fix is a single bounds check that rejects any header length below zero or larger than the message itself before the cast, which Blaszczyk sent to Google on the day of his first report. Google has treated a near-identical bug as a security flaw before: in 2009 it patched CVE-2009-2999, a malformed WAP Push message that restarted Android 1.5 phones and dropped them off the network.
The proof-of-concept is an Android app, released with its source code under the Apache 2.0 license, that sends the crafted payload as a data SMS from any Android 11 or later phone with a SIM. Blaszczyk labels it a working weapon for authorized testing only and warns that interfering with someone’s access to emergency services is a serious criminal offence. His disclosure does not report any exploitation in the wild.
With no patch from Google, the researcher said he went public so that users, carriers, and Android device makers can assess the risk and mitigate it themselves.
Community Discussion
Join the conversation. Ask questions, share solutions, and help others.
Be the first to start the discussion!
