Android SMS of Death Flaw Can Drop Calls and Trap Phones in Repeated Crashes

An invisible message can interrupt a phone call

A specially crafted text message just eight bytes long can crash the calling service on vulnerable Android phones, disconnect active calls and, after repeated delivery, leave a handset struggling to start normally. Security researcher Mark Blaszczyk disclosed the flaw on October 29, 2026, after first reporting it to Google on May 5.

The vulnerability, described as SMS of Death and identified in security coverage as CVE-2026-58882, affects the software that processes certain incoming messages before they reach a messaging app. The recipient does not need to open anything, install an application or tap a link. The malicious message produces no inbox entry or notification, according to Blaszczyk.

Blaszczyk reproduced the problem on a Google Pixel 9 running April 2026 firmware and several Samsung Galaxy phones, including models in the Galaxy A series. He reported successful reproduction in every test on those devices. A single message interrupted cellular service for about one to two seconds while Android restarted its calling process.

Blaszczyk, an independent security researcher, described the immediate effect on the Android process responsible for telephone functions:

A single malformed WAP Push SMS crashes com.android.phone on Android, dropping active calls (including emergency calls), with zero interaction from the victim,

No attacks outside test environments have been reported, and the warning about interference with emergency services comes from the researcher's assessment. A complete list of affected handsets, carrier networks and countries has not been published. The practical concern is that a brief service interruption can end a conversation, while repeated interruptions can prevent someone from maintaining a connection when they need help.

Why the message never reaches the inbox

Android receives the malicious content through WAP Push, an older mechanism used to deliver data and instructions over mobile networks. Legitimate uses include prompting a phone to retrieve a multimedia message or apply carrier settings. Unlike an ordinary text written for a person to read, this kind of message is processed automatically by system software.

Android's WapPushOverSms component handles that processing. The flaw occurs inside its decoding function, where the phone reads information describing the length of part of the message. Because the calling service encounters the error before normal message handling finishes, the recipient has no visible text to inspect or delete.

The attack therefore bypasses the moment when people usually decide whether a message looks suspicious. Ignoring unknown senders or refusing to open links offers little help against a failure triggered during automatic processing. Protection depends primarily on correcting the operating system component that handles the message.

A large number becomes a negative length

Blaszczyk traced the crash to a number conversion error. Android reads a message header length using a data type capable of holding large numbers, then converts that value into a signed integer with 32 bits without first checking whether it fits.

In the described test, the value 2,147,483,648 becomes negative 2,147,483,648 during that conversion. A signed integer of that size can hold positive numbers only up to 2,147,483,647. The crafted value sits just beyond that limit.

Android then tries to reserve space for a block of data using the negative length. A negative size makes no sense for that operation, so the software raises an error called NegativeArraySizeException. Because the error is not properly handled, it terminates com.android.phone.

The eight byte message contains a five byte sequence that supplies the problematic length information. Its small size helps explain the seriousness of the defect: a tiny incoming message can trigger a much larger disruption because a central system process fails while interpreting it.

How a short outage becomes a repeating failure

Mobile carriers normally expect a phone to acknowledge that it has received a message. When Android crashes before completing that exchange, the carrier may try delivery again. A mechanism intended to make texting reliable can therefore bring the same harmful content back to the phone.

Android also keeps incoming messages in a pending queue while processing them. Blaszczyk said a malformed message can remain there and be processed again after a restart, creating another opportunity for the same crash.

Blaszczyk explained why restarting the device may fail to end the disruption:

The malformed message stays queued and is retried on every boot, so the phone can crash on startup until it is cleared,

Blaszczyk warned that roughly 20 messages could make a device unusable for an extended period. Testing also described about 30 messages arriving rapidly before more persistent failures developed. Those figures describe test conditions rather than a precise threshold that every handset would reach.

The researcher attributed some lasting failures to corruption of the SQLite database used to store incoming SMS data. SQLite is a small database system that applications and operating systems use to keep structured records. If records needed during startup repeatedly trigger a failure, the calling service can crash each time the phone tries to recover.

Carrier redelivery caused intermittent calling trouble lasting up to a week in testing, including disruption attributed to a single malicious message. The combination of messages held by the carrier and records stored on the handset helps explain why the effects can outlast the initial delivery.

Why the recovery screen can mean lost data

Android includes an automatic recovery mechanism called RescueParty. When a critical component keeps failing, it attempts recovery and can move the handset into recovery mode after roughly 90 seconds. Users may then encounter an option to wipe their data.

A factory reset erases local data and settings. Blaszczyk reported that resetting offered only temporary relief in testing because the carrier could subsequently redeliver messages still awaiting acknowledgement. Someone choosing to erase the phone could therefore lose personal information and face renewed crashes afterward.

Blaszczyk described recovery through Android Debug Bridge, or ADB, a tool that allows a computer to communicate with an Android device for development and maintenance. His procedure involved clearing affected SMS records during a short period when the phone was accessible.

ADB recovery requires technical access, and many owners will not have configured the necessary connection beforehand. The researcher's recovery approach also involved moving a physical SIM into a handset that did not run Android so outstanding messages could be received and acknowledged. He warned that recovery could be harder when the mobile subscription uses an eSIM.

For someone facing repeated crashes, the concrete priority is to seek qualified technical help before selecting a data wipe. The reported recovery work involves system records and access settings, making it more demanding than deleting an ordinary text message.

Which Android versions need attention?

The main affected range described in the technical accounts is Android 12 through Android 16. Some accounts extend it through Android 17. Testing specifically named Pixel and Samsung Galaxy devices, while the suspected reach is broader because the problem sits in shared Android telephony code.

The reported October 2026 correction covers Android 14 through Android 17. Phones still running Android 12 or Android 13 are the clearest support concern: those versions are described as outside Google's current security support, leaving owners dependent on a manufacturer or another operating system provider to supply a correction.

A phone's Android version and its security update status answer different questions. The version identifies the generation of the operating system. The security update information helps show how recently its vulnerabilities were addressed. Two phones running the same Android version can receive fixes at different times.

Manufacturers and carriers influence when updates reach individual models. Owners should check the security update date in Settings, usually under About phone, Security or Software updates, and install the latest available update. For this flaw, the reported correction is associated with the October 2026 update, although model specific confirmation from the manufacturer is useful when release timing is unclear.

A fix took a different route from the complaint

Blaszczyk said Google initially treated his submission as a nonsecurity issue and closed it without agreeing to the action he sought. His published account described further appeals and a renewed nonsecurity classification on October 29. Meanwhile, Android engineers had been developing a correction.

The reported sequence separates the handling of the researcher's complaint from the movement of code through Android's development and update systems:

• May 5, 2026: Blaszczyk first reported the vulnerability to Google.
• June 15: Google created an engineering correction for the message processing failure.
• July: GrapheneOS said it received the patch through security previews and implemented it that month.
• August 5: The correction was reportedly checked into Google's development process.
• October: The change became public in the Android Open Source Project and was included in updates for Android 14 through Android 17.
• October 29: Blaszczyk publicly disclosed his findings.
• November: GrapheneOS said the vulnerability was expected to appear in Android's security bulletin.

GrapheneOS suggested an internal communication problem might explain Google's handling of the report. That explanation was speculation by the operating system project's developers. The record described here contains both a rejected complaint and an engineering change intended to stop the crash.

The November bulletin was the next stated publication milestone. GrapheneOS said it had already implemented the correction in July, so the later bulletin date concerned public security documentation rather than its first deployment of the patch.

What the correction changes

Google's reported fix expands exception handling so Android catches the runtime error and removes the malformed message from the pending queue. That allows processing to move past the harmful record rather than repeatedly crashing on it.

Blaszczyk had proposed checking whether the declared header length was valid before converting it. The reported engineering approach instead handles the failure and clears the message responsible. In practical terms, removing that record also addresses the repeated processing that can turn one delivery into a continuing service problem.

The correction is described as acting on a malformed message when it encounters one. The roughly 20 messages mentioned in the testing concern the severity of repeated disruption, rather than a number the fix must wait to receive before taking effect.

A correction appearing in the Android Open Source Project means the underlying code is available for incorporation into Android software. Delivery to an individual owner still depends on a suitable update being built and distributed for that handset. This is why checking a particular model's support status matters alongside knowing that Google has corrected the code.

What owners can do now

Owners of supported phones should install the latest system security update and check their manufacturer's release notes or support information for confirmation of the correction. People using Android 12 or Android 13 should ask whether their model will receive a patch or can upgrade to a supported Android version.

Blaszczyk has published a demonstration application and its source code, making prompt patch deployment more urgent. His publication includes a warning against targeting other people, particularly because interference with emergency communications can create serious danger.

Users whose phones repeatedly lose cellular service or restart should contact their device manufacturer or a qualified repair service. A phone displaying a recovery prompt needs careful handling if its owner wants to preserve data. Anyone needing urgent assistance while their handset cannot maintain a call should use another working phone.

The central change for owners is straightforward: this failure happens before there is a suspicious message to assess. A current security update, delivered for the actual handset in use, is the most practical protection described for supported devices.

Key Points

• A malformed WAP Push SMS can crash Android's calling service without any action by the recipient.
• Blaszczyk reproduced the flaw on a Pixel 9 and Samsung Galaxy devices, with individual interruptions lasting about one to two seconds.
• Repeated processing and carrier redelivery can cause prolonged disruption, repeated crashes and recovery prompts.
• The reported October 2026 correction covers Android 14 through Android 17. Android 12 and Android 13 owners depend on further support from their device providers.
• No attacks outside testing have been reported. The researcher warned that disrupted calling could affect access to emergency services.
• A factory reset erases data and may be followed by renewed delivery of harmful messages. Technical recovery may require ADB.