Android's zero-click SMS crash bug
A malformed text message can crash unpatched Android phones without being opened, and older devices may stay vulnerable indefinitely.
A single text message can drop a call, cut off mobile connectivity, and in the worst case push an Android phone into a reboot loop — with no tap, no link, and no notification required. The flaw behind that scenario is a zero-click denial-of-service bug in Android, and it has a nickname that fits: the SMS of Death.
According to TechRadar's reporting, the vulnerability is tracked as CVE-2026-58882 and carries a critical severity rating. Google has patched supported Android versions, but the same report notes that devices past their end-of-life date will not receive a fix and remain at risk.
What makes this one unusual is how little the attacker needs. There is no malicious app to install and no phishing page to visit. The payload is an SMS message, and the phone processes it before the user ever sees it.
A malformed eight-byte message
TechRadar reports that the bug was discovered by security researcher Mark Blah, who described it as a zero-click denial-of-service vulnerability. In technical terms, it is an improper validation of a header-length value in Android's WapPushOverSms.decodeWapPdu function.
The mechanism, as described in the report, involves a malformed eight-byte WAP Push message sent to an Android device's port 2948. The bytes are: 01 06 88 80 80 80 00 BE. Because this is a hex message, translating it into a signed 32-bit integer produces -2147483648.
Android then attempts to allocate memory using that negative value. That triggers a NegativeArraySizeException error, which crashes the com.android.phone process. Since that process manages cellular functions, the call drops and mobile connectivity is disrupted. The report adds that even emergency services are susceptible, it was said.
Why the user never sees it coming
The zero-click label is not marketing shorthand. Android processes incoming messages before they reach the inbox, according to the report, which means the victim is never notified of the SMS and has no obvious reason to connect a dropped call to a text message that never appeared on screen.
That alone would make diagnosis difficult. The source describes additional behavior that makes it worse: some carriers attempt to redeliver messages that never reached the inbox, extending the disruption, and Android itself keeps trying to process messages already stored on the phone.
The result is a crash that can repeat without any further action from the attacker. The report describes a scenario in which connectivity drops, calls fail, and the device can eventually enter recovery mode, rebooting roughly every minute and a half until the user performs a factory reset.
Twenty messages and a reboot loop
A single message is enough to drop a connection. According to Blah's findings as reported by TechRadar, sending 20 or more messages can force the device into a reboot loop. On an Android 12 device, the report states, that can force looped recovery mode, leaving a factory reset as the only viable option.
The report does not describe the technical steps a user would take to recover a device already stuck in that state, beyond the factory reset scenario. It does note that the malicious message can, in principle, be removed with a computer using Android Debug Bridge (ADB) — a route that requires more technical knowledge than most phone owners are likely to have.
The patch and what it changes
Initially, according to the report, all Android versions were affected. Google patched the flaw for versions 14 through 17, but older devices will not be getting a patch and thus remain at risk indefinitely.
The fix is titled “Fix remote DoS in decodeWapPdu”. Per the source, it prevents the crashes by catching exceptions triggered when Android processes malformed text messages, and it also deletes these messages from the SMS database so they do not trigger repeat crashes.
TechRadar reports that Google apparently patched the bug in its October 2026 Android security updates. That date matters because it sets the floor for when a fix existed — not when every phone received it.
Why some phones wait longer
Android's update model is not uniform. The report notes that, unlike Apple's ecosystem, Android is diversified, with different manufacturers following different update cadences. A patch landing in Google's security updates does not mean it has arrived on every handset that needs it.
On that basis, the report reasons that Pixel users have likely already received this update, while people using Samsung, Xiaomi, Motorola, or OnePlus devices will probably have to wait a little longer until their manufacturers apply the fix and push it out.
The report also notes that the proof-of-concept has been released, and reasons that most Android manufacturers have likely pushed their updates by now. Its guidance to users is direct: install them as soon as possible.
The proof-of-concept is out
Blah has released a proof-of-concept showing how to exploit the flaw, according to the report. Separately, BleepingComputer reported that a GitHub contributor found a way to remove the malicious message, though the source describes that method as requiring more technical knowledge than most mobile phone users are likely to have.
For anyone trying to understand the attack surface, the published PoC makes the mechanics concrete: a specific byte sequence, a specific port, and a specific integer overflow path inside a function most Android users will never hear about.
What the report does and does not establish
The source describes a researcher's findings, a Google patch, and reporting from BleepingComputer on a removal method. It does not describe an in-the-wild campaign, a named victim, or an estimate of how many devices remain exposed.
What it does establish is a set of boundaries. Patched versions exist for Android 14 through 17. End-of-life devices are outside that boundary. The crash path runs through the phone process, which is why connectivity and calls are affected. And the message is processed before it reaches the inbox, which is why the user has no obvious signal that anything arrived.
Those four facts are enough to understand why the flaw drew the SMS of Death nickname, and why the report treats installation of available updates as the practical step for users.
What this means for Android users
The immediate consequence for anyone holding an Android phone is a patch-status question, not a behavior-change question. There is no setting described in the source that prevents the message from being processed, and no user action described that blocks it. The variable the report points to is whether the device has received the fix.
For people on supported versions, that means checking for and installing the October 2026 Android security updates if they have not already arrived. For people on devices past end-of-life, the report's framing is less reassuring: no patch is coming, and the risk stays in place.
For organizations managing mixed Android fleets, the report's emphasis on manufacturer update cadence suggests the practical question is which devices in a fleet are still receiving security updates at all. The source does not offer an enterprise remediation playbook, but it does make clear that the gap between a Google patch and a manufacturer push is where exposure lives.
The deeper implication is about how a flaw like this is discovered and disclosed. A proof-of-concept is now public, the technical detail is documented, and the affected function is named. What remains is the ordinary, uneven work of getting a fix onto hardware that may no longer be supported by anyone.
Sources
- TechRadar Original source
Continue Reading
Node-RED flaw turned into Linux bot dropper
VulnCheck says attackers are exploiting a maximum-severity Node-RED bug to push a Linux bot onto exposed industrial gear.
Trigger.dev Breach Exposes Customer Secrets
Cloud-hosted AI workflow platform Trigger.dev says attackers reached environment variables for a subset of organizations.
Most Severe Flaws Sit Off the Advisory Map
Armadin's attack data suggests vendor advisories miss the bulk of critical weaknesses in enterprise environments, with most fixes resting on in-house code and settings.