A single malformed text message, delivered silently and never shown in the inbox, can crash the telephony process on an Android phone and drop a call in progress, emergency calls included. Researcher Mark Blaszczyk disclosed the flaw on October 29, 2026, with working proof-of-concept code. Google’s October 2026 security update fixes it for Android 14 through 17, which leaves older phones in a difficult spot.
Tech news in one quick read: Get the most interesting stories in startups, tech and programming, each with a short TLDR, in one daily email from TLDR.
We may earn a commission if you sign up.
Android 12 and 13 devices that did not receive the fix remain exposed, according to Blaszczyk’s disclosure page, because the October 2026 fix is listed only for the newer releases. The bug is tracked as CVE-2026-58882 and has been nicknamed the “SMS of Death” for the way it turns an ordinary-looking message into a service outage.
WapPushOverSms and the crash in com.android.phone
The weakness sits in WapPushOverSms, the Android component that decodes WAP Push messages, an old carrier format delivered as a data SMS. According to the eSecurity Planet analysis of CVE-2026-58882, Android reads a header-length value as a large number and converts it to a smaller integer type without validating it. A crafted sequence makes the result negative, Android throws a NegativeArraySizeException when it tries to allocate memory, and the telephony process, com.android.phone, dies.
No tap, download or reply is needed. The message does not appear in the inbox and the sender’s number is not shown.
Blaszczyk’s own write-up at smsofdeath.com describes the vector as a remote, zero-click WAP Push message aimed at port 2948, and reports that the crash was reproduced from Android 12 to 16. He withheld the byte-level details of the trigger, and so does this article. The page gives a timeline: reported to Google’s Android and Devices vulnerability reward program on May 5, 2026, a fix commit authored June 15, and public disclosure on October 29.
Reboot loops, emergency calls and a factory reset
One crash is a nuisance. Repeated crashes are the real problem. Telephony restarts after about one to two seconds, but the carrier may resend a message the phone never acknowledged, and the unprocessed message stays in the pending queue, so each restart can trigger another crash. Blaszczyk found that around 20 messages could leave a device unusable for an extended period, and Cybernews reported that Android’s RescueParty feature eventually pushes a repeatedly crashing phone into recovery mode after about 90 seconds.
A boot loop can corner an ordinary owner into a factory reset. The researcher described a way to clear the offending messages from a computer using Android Debug Bridge without wiping the phone, but it demands technical skill and a narrow window after boot, and his page warns against choosing the wipe-data option in recovery.
Blaszczyk reported a 100% reproduction rate on a Pixel 9 running April 2026 firmware and on several Samsung Galaxy A-series phones. Calling the public proof-of-concept “a working weapon,” he made clear that the risk is practical and not theoretical.
What Google changed in the fix
Google’s repair does not do what the researcher proposed. Instead of validating the header length, the change widens exception handling so runtime errors during WAP Push decoding are caught and the malformed message is deleted from the queue. A write-up at Braindetox identifies the commit as “Fix remote DoS in decodeWapPdu,” committed on August 5, 2026 and shipped in the October release. It notes that the October bulletin’s critical entry for a related denial of service is numbered CVE-2026-58865 and links to a different commit, so the match with CVE-2026-58882 is unconfirmed there.
Disclosure timeline and Google’s handling
The dates in the public record do not line up perfectly, which is itself informative. Blaszczyk says he reported the flaw on May 5, 2026 and that Google authored a fix on June 15. Braindetox lists the commit as landing in the Android Open Source Project on August 5, while Smartworld says the fix was rolled out in July. All sources agree the change reached phones through the October 2026 security update and that disclosure came on October 29, roughly five and a half months after the first report.
Italian outlet Smartworld reports that Google repeatedly rejected the report as not a security issue, and suggests an internal communication failure or a duplicate report as the likely cause; Google has not publicly explained the discrepancy. The same article says the vulnerable code dates back to Android 12 and that models no longer receiving security updates stay permanently exposed. The October fix is listed for Android 14, 15, 16 and 17 only, and no source consulted lists a patch for Android 12 or 13.
The practical advice is the plain one: install the newest security update the manufacturer offers, and treat a phone that has stopped receiving updates as exposed. GrapheneOS said the fix will appear in its November bulletin.
What remains unclear is how many Android 12 and 13 phones are still in daily use, and whether carriers will filter the malformed messages before they reach handsets. Neither Google nor the researcher has published figures on either point.
This article was produced with the assistance of AI and reviewed by Morning Overview editors prior to publication.
Tech news in one quick read: Subscribe to TLDR →
We may earn a commission if you sign up.
More from Morning Overview
- Tropical Storm Rachel is dumping up to 12 inches on four Mexican states on its way to major hurricane strength
- The FTC says Lens.com doubled the price shoppers saw in Google ads
- Common allergy, bladder and sleep pills tied to sharply higher dementia odds
- NOAA now gives this winter a 75% chance of the strongest El Nino since 1950
