TL;DR: What is the Android SMS of Death?
SMS of Death is a zero-click flaw in Android's telephony code, made public on 29 October 2026 by security researcher Mark Blaszczyk. One invisible WAP Push text crashes the phone service, drops any call in progress, including emergency calls, and about 20 of them can trap a phone in a reboot loop. Android 12 to 17 run the vulnerable code. Google wrote a fix in June for Android 14 to 17, while Android 12 and 13 get nothing. Google classed the bug as a non-security issue, and a working proof of concept is now public. For founders, this is a phone-fleet problem: check patch levels, retire old work phones and stop leaning on SMS alone.
Developing story. Last updated 1 Nov 2026, 07:45 CET. Android Authority and BleepingComputer now report the bug as CVE-2026-58882, and Android Authority expects it in Google's November 2026 bulletin. Neither the bulletin nor the CVE record was public on the morning of 1 November (see the update below). We'll update this article as Google publishes its November 2026 Android Security Bulletin and phone makers ship their updates.
The Android SMS of Death went from a rejected bug report to a public exploit in two days. In Germany, searches for Android Sicherheitslücke jumped 1,000% on Saturday after dpa, WiWo and teltarif picked up the story, and the same questions keep coming up: is my phone affected, has Google fixed it, and what happens if the phone starts rebooting. If your team runs on Android phones, here is what we know and what to do this week.
What do we know so far about the SMS of Death?
Update 1 Nov, 07:45 CET: the bug now has a reported CVE number. Android Authority (30 October) and BleepingComputer (31 October) track it as CVE-2026-58882. Android Authority writes that it carries Android's highest severity rating and is apparently slated for Google's November 2026 Android Security Bulletin, which matches what GrapheneOS said on 29 October. We could not confirm the number at the source: on the morning of 1 November the public CVE list returned no record for CVE-2026-58882, and Google had not yet published its November bulletin. Google has not explained publicly why it rejected a report about a bug its own engineer had already fixed; Android Authority says it asked Google for clarification. We found no reports of real attacks so far, and the researcher's write-up is unchanged.
Here is what the researcher's full write-up, the Android source code and the first reports confirm:
Here is what the researcher's full write-up, the Android source code and the first reports confirm:
- The flaw: Android's WapPushOverSms code reads the header length of a WAP Push message, casts it to a 32-bit number without a range check and uses it as an array size. A crafted 5-byte value turns into a negative number, Android throws an exception nobody catches, and com.android.phone, the process behind calls and mobile data, dies.
- The delivery: the attack arrives as a data SMS to port 2948. It never shows up in Messages, there is no notification, and the victim never sees the sender's number. All the attacker needs is a phone number.
- One message: 1 to 2 seconds without service and a dropped call, including a call to emergency services. Because the phone crashes before it confirms delivery, the carrier keeps resending, and in testing one message caused intermittent outages for up to a week.
- About 20 messages: the device becomes unusable for an extended period. The poison message is retried at every boot, and Android's RescueParty sends the phone into recovery mode about every 90 seconds, showing a Wipe data prompt.
- Tested devices: a Pixel 9 on April 2026 firmware and several Samsung Galaxy and Galaxy A-series phones, with a 100% reproduction rate. The crash was reproduced from Android 12 up to Android 16.
- No attacks seen yet: the disclosure reports no exploitation in the wild. The proof-of-concept app and its source code are public on GitHub, so that can change fast.
Which Android phones are affected, and which are patched?
The vulnerable code ships in Android 12 through 17. On 15 June 2026 a Google engineer authored commit 735d967, titled "Fix remote DoS in decodeWapPdu" and tagged as a CVE fix. It catches the error and deletes the poison message, which breaks the crash loop. The researcher had proposed a simple range check on the day of his first report.
The open question is the patch level. The researcher says the fix shipped in the October 2026 security release. GrapheneOS, which received it in Google's partner previews in mid-July, says on its issue tracker that it belongs to the upcoming November 2026 bulletin, with the patch pushed to the public Android code in October. The October 2026 Android Security Bulletin doesn't name the bug, and the CVE number is still unconfirmed: Android Authority, BleepingComputer and eSecurity Planet use CVE-2026-58882, Cyber Kendra reported that none was assigned, and the public CVE list showed no record for it on 1 November. The safe reading for now: treat a phone as covered once it shows the November 2026 security patch level, and install October's in the meantime.
Why did Google call it a non-security issue?
Blaszczyk reported the bug to Google's Android and Devices Vulnerability Reward Program on 5 May 2026. According to his disclosure, as summarised by Cyber Kendra, the original report was closed on 20 June as "Won't Fix (Infeasible)", five days after Google's own engineer had written the fix. An appeal was closed within minutes as not reproducible, the case moved across three tickets and four engineers, and on 29 October Google said the bug "does not meet the severity threshold". The researcher published everything that day.
Blaszczyk argues that the bug fits the program's own definition of a destructive remote denial of service, because a normal user stuck in the loop ends up wiping the phone. He also points to Australia, where carriers must cut off handsets that can't reach Triple Zero (000), so an attacker could in effect get a victim's phone barred from the network. Google treated a near-identical WAP Push crash as a security flaw before, in 2009, as CVE-2009-2999 on Android 1.5.
Founders who run their own bug bounty should read this one as a warning. A quiet fix plus a rejected report is how a researcher ends up publishing a working exploit. Our sister guide on bug bounty rules for small startups covers the basics of answering researchers well.
Why does a phone bug matter for startups?
Because your business runs on those phones. Three exposures stand out:
- Field and frontline teams. Delivery riders, carers, sales reps and technicians on cheap or older Android handsets are the most likely to sit on Android 12 or 13, or on a brand that ships patches late. A phone in a reboot loop means a lost shift, and a dropped emergency call is a duty-of-care problem.
- SMS logins. If your product or your own admin accounts rely on SMS one-time codes, a phone stuck in a crash loop can't receive them. That locks out customers and staff at the worst moment.
- Support load. If you sell to people with Android phones, expect questions. The researcher's recovery needs a computer and ADB, and phones with an eSIM are much harder to rescue, since the SIM can't be moved to another device.
We saw a cousin of this risk in October with the Orange outage in France: when the phone network or the phone itself fails, every process that assumes a working mobile line fails with it.
What should founders do about the SMS of Death now?
Next steps, in the order I'd take them:
- List every work phone. Model, Android version and security patch level (Settings, About phone, Android version). Bring-your-own-device phones count if staff use them for work calls or logins.
- Patch what can be patched. Install the October 2026 update now and the November 2026 update as soon as the maker ships it. On Pixels it arrives directly; on other brands, check the maker's update page.
- Set a minimum patch level. If you use a device manager (Google's Android management, Intune or similar), block phones below the November 2026 patch level from company apps once that update is out.
- Plan to retire Android 12 and 13 work phones. They won't get Google's fix. Put replacements in the next budget, and buy phones with a long, published update promise.
- Give staff a backup for urgent calls. A second device, a landline or a VoIP app on a laptop keeps lone workers reachable while a phone is down.
- Move logins off SMS codes. Authenticator apps and passkeys keep working when the phone service crashes. If your product sends SMS codes, add one of these as an option. The security basics for startups guide covers the rest of the setup.
- Write the rule for a reboot loop. Never tap Wipe data. Switch the phone off, move a physical SIM to a non-Android phone so the queued messages get delivered there, and ask IT to clear the bad messages over ADB. WiWo and dpa give the same advice: get professional help before resetting anything.
Are you getting customers from ChatGPT yet?
More and more traffic is coming from Perplexity, ChatGPT, Grok and other AI tools.
👉 Rank on ChatGPT
What we don't know yet
- Which patch level carries the fix: October 2026, as the researcher says, or November 2026, as GrapheneOS says. Google's November bulletin should settle it.
- Whether Google confirms CVE-2026-58882, the number the media now use, and whether it changes its non-security verdict now that the exploit is public.
- When Samsung, Motorola, Xiaomi and other makers ship the fix, and whether any of them patch Android 12 or 13 themselves.
- Whether carriers filter the malformed WAP Push messages in their networks, which would protect old phones too.
- Whether anyone uses it in real attacks. None reported as of 1 November.
Timeline
- 5 May 2026: Mark Blaszczyk reports the bug to Google's Android and Devices Vulnerability Reward Program, with a proposed bounds-check fix.
- 15 June: a Google engineer authors commit 735d967, "Fix remote DoS in decodeWapPdu".
- 20 June: the report is closed as "Won't Fix (Infeasible)"; an appeal is closed the same day.
- Mid-July: the fix reaches Google's security preview patches for phone makers, and GrapheneOS ships it.
- 5 October: Google publishes the October 2026 Android Security Bulletin.
- 29 October: Google calls the bug a non-security issue; the researcher publishes the write-up and proof of concept.
- 30 and 31 October: GSMArena, dpa, WiWo and teltarif report it, and searches for Android Sicherheitslücke spike in Germany.
- 30 October to 1 November: Android Authority and BleepingComputer report the bug as CVE-2026-58882, expected in the November bulletin; on 1 November neither the CVE record nor that bulletin is public yet.
Is the SMS of Death a reason to panic?
It is a reason to tidy up your phone fleet this week. Nobody has reported real attacks, Android 14 and newer have a fix on the way or in hand, and the damage is availability, with no data stolen. The weak spots are old phones, slow-patching brands and processes that assume a working mobile line. Fix those three and this bug becomes a non-event for your team. If the PHP flaw earlier this month was a website lesson, this one is the phone version: an inventory and a patch policy beat any amount of worry, as GSMArena also tells its readers.
FAQ: the Android SMS of Death
What is the Android SMS of Death?
A zero-click bug in Android's WAP Push handling, made public on 29 October 2026 by researcher Mark Blaszczyk. One invisible message crashes the phone service and drops calls; about 20 can leave a phone stuck in a reboot loop.
Which Android versions are affected?
Android 12 to 17 run the vulnerable code. Google's fix covers Android 14 to 17. Android 12 and 13 get no fix from Google.
Has Google fixed the SMS of Death?
Yes, for Android 14 to 17. A Google engineer wrote the fix on 15 June 2026. The researcher says it shipped with the October 2026 patch; GrapheneOS says it is part of the November 2026 bulletin. Install both updates.
Can the SMS of Death steal my data?
The disclosure describes a denial of service: crashes, dropped calls and reboot loops, with no data theft. The risk to data comes from wiping the phone to escape the loop.
What should I do if my Android phone keeps rebooting?
Don't choose Wipe data. Get technical help: the researcher's recovery clears the bad messages over ADB from a computer, and moving a physical SIM to a non-Android phone stops the carrier resending them.
Does the SMS of Death affect iPhones?
No. The bug sits in Android's own telephony code. The researcher recovered test phones by moving the SIM into a non-Android device such as an iPhone.
About the Author
Violetta Bonenkamp, also known as MeanCEO, is an experienced startup founder with an impressive educational background including an MBA and four other higher education degrees. She has over 20 years of work experience across multiple countries, including 5 years as a solopreneur and serial entrepreneur. Throughout her startup experience she has applied for multiple startup grants at the EU level, in the Netherlands and Malta, and her startups received quite a few of those. She’s been living, studying and working in many countries around the globe and her extensive multicultural experience has influenced her immensely.
