SMS of Death: Android Zero-Click Telephony DoS (CVE-2026-58882)

TL;DR

• A malformed WAP Push SMS crashes Android's telephony process, dropping any active call, including calls to emergency services, with no tap and no visible message. Researcher Mark B disclosed it with a working proof of concept on October 29, 2026.
• The flaw reproduces from Android 12 through Android 16, and Google shipped the fix only for Android 14 through 17, in the October 2026 security update. Android 12 and 13 devices, 18 percent of worldwide Android web traffic in October 2026, receive no fix.
• The impact is denial of service, not code execution: the phone crashes, reboots and can enter a loop that ends in a factory reset. BleepingComputer reports the identifier CVE-2026-58882; the public CVE records did not carry it as of November 2, 2026, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog as of that date.
• Update every supported device to the October 2026 patch level or later. On Android 12 and 13 there is no patch; plan replacement or retirement for devices that cannot leave those versions.

Am I affected?

You are exposed when all of these hold:

• The device runs Android 12 through Android 17. The researcher reproduced the crash from Android 12 up to Android 16 across Pixel 9 and several Samsung models, and the affected code ships in every one of those releases.
• The device has not received the October 2026 security update. Google's fix covers Android 14 through 17; devices updated to the October 2026 patch level or later are protected.
• The attacker knows, or can guess, the target's phone number. Nothing else is needed: no app installation, no interaction and no prior access.

The researcher reports the crash reproduces at a 100 percent rate on every tested device. Android 12 and 13 held 18.01 percent of worldwide Android web traffic in October 2026, and those devices run the same telephony code without a patch path.

Check the Android version and the security patch level of every device you manage:

adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.security_patch

The first command prints the Android version, for example 14. The second prints the patch date, for example 2026-10-08; any date of 2026-10-01 or later means the October update has arrived on that device.

How do I fix it?

Update every Android 14 through 17 device to the October 2026 patch level or later:

1. Open Settings, then Security and privacy, then check for the October 2026 security update; install it and restart the phone.
2. Verify the device actually carries the fix: adb shell getprop ro.build.version.security_patch must print a date of 2026-10-01 or later. Update availability depends on the manufacturer and carrier, and a restart may be needed to finish installation.
3. Re-check the fleet: any device on Android 12 or 13 has no patch path, and any patch level before October 2026 remains vulnerable.

There is no workaround for unpatched devices. The message is processed before it reaches any user-visible inbox, so no SMS-blocking app, permission change or airplane-mode habit stops it. For devices already hit, the recovery steps in "How do I check if I was compromised?" clear the poison messages over ADB; they do not prevent new ones.

What is the root cause?

A WSP header length arrives as a 64-bit value and is cast to a signed 32-bit integer with no range check. The truncated value then sizes an array. The flaw sits in decodeWapPdu of WapPushOverSms, the component that turns inbound WAP Push short messages into Android intents, in the frameworks/opt/telephony part of the platform.

The decode reads the header length as a uintvar, a Wireless Session Protocol integer of at most 5 bytes, and receives it as a Java long:

// WapPushOverSms.java:217  header length read as long, cast with no bounds check
int headerLength = (int) pduDecoder.getValue32();

Later, the same value sizes the header buffer:

// WapPushOverSms.java:244  the cast value is used as an array size
byte[] header = new byte[headerLength];

A crafted message declares a 5-byte uintvar of 88 80 80 80 00, which decodes to the long 2147483648. Cast to a signed 32-bit int, that is -2147483648. Allocating new byte[-2147483648] throws a NegativeArraySizeException on the telephony main thread, and the process dies:

E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: com.android.phone
E AndroidRuntime: java.lang.NegativeArraySizeException: -2147483648
E AndroidRuntime:   at ...WapPushOverSms.decodeWapPdu(WapPushOverSms.java:244)

The pre-fix code caught only ArrayIndexOutOfBoundsException around this decode, so the NegativeArraySizeException escaped and killed com.android.phone, the process that owns calls, the modem connection and SMS.

How is it exploited?

The proof of concept is public, with source and an installable app, and the whole attack is one short message:

1. The attacker sends a data SMS, not a text message, to the target's port 2948, the WAP Push port. The payload is 8 bytes: 01 06 88 80 80 80 00 BE, a transaction id, a push PDU type, the poisoned header length and a content type.
2. Android delivers the message to the telephony stack before any user-facing inbox. InboundSmsHandler.processMessagePart hands it to WapPushOverSms.decodeWapPdu, which parses the uintvar header length as 2147483648 and casts it to -2147483648.
3. The new byte[-2147483648] allocation throws on the telephony main thread. com.android.phone crashes, and any call in progress terminates with disconnect cause CS_DEATH.
4. Android restarts the telephony process, which takes 1 to 2 seconds of no service. Because the SMS was never acknowledged, the carrier re-delivers it, and the crash repeats. The researcher measured intermittent outages for up to a week from a single message.
5. The poison message stays queued in the raw SMS database, so it is retried on every boot. Around 20 messages made test devices unusable for extended periods; one Android 12 device entered a reboot-to-recovery cycle roughly every 90 seconds that ended with a factory reset.

The proof-of-concept app on GitHub sends the crafted message from a second Android phone. The researcher published it with a warning that it is a working weapon and restricted its license to authorized testing.

How does the attack flow?

One 8-byte data SMS to port 2948 crashes telephony through the unchecked cast, and the queued message keeps the crash coming back.

What can an attacker do?

The demonstrated impact is persistent denial of the phone's cellular service, and nothing in the disclosure claims code execution:

• Any active call drops when the process dies, including a call to emergency services, and the phone cannot reliably place calls while the attack or the resulting loop runs.
• Each crash costs 1 to 2 seconds of telephony blackout. Carrier redelivery turns one message into repeated crashes; a single message kept one test device failing intermittently for up to a week.
• Roughly 20 messages left devices unusable, and on one Android 12 device the queued messages caused a reboot loop into recovery every 90 seconds. The researcher's recovery required either an ADB cleanup procedure or a full factory reset.
• The victim sees nothing: the data SMS never appears in Messages, and the sender's number is never shown, which also makes the attack hard to attribute afterwards.

The conditions are minimal: the attacker needs the phone number and nothing more. No app, no permission, no interaction and no network position are required.

Why does the fix work?

Google's fix is commit 735d9672603fa206c4b43cb668c1aa273db70b97, "Fix remote DoS in decodeWapPdu", authored on June 15, 2026 and shipped in the October 2026 security update. It does not add the bounds check the researcher proposed; it stops the crash from being fatal and stops the message from surviving it:

// WapPushOverSms.java: widen the catch to cover NegativeArraySizeException
-        } catch (ArrayIndexOutOfBoundsException aie) {
+        } catch (RuntimeException e) {

// InboundSmsHandler.java: a failed decode now deletes the poison message
-                    if (processMessagePart(inboundSmsTracker)) {
+                    boolean success = false;
+                    if (inboundSmsTracker != null) {
+                        try {
+                            success = processMessagePart(inboundSmsTracker);
+                        } catch (RuntimeException e) {
+                            loge("Exception delivering message part", e);
+                            deleteFromRawTable(inboundSmsTracker.getDeleteWhere(),
+                                    inboundSmsTracker.getDeleteWhereArgs(), MARK_DELETED);
+                        }
+                    }

NegativeArraySizeException is a RuntimeException, so the widened catch swallows the allocation failure and marks the message as a generic error. The companion change in InboundSmsHandler deletes the message from the raw database when delivery throws, which breaks both the carrier-redelivery loop and the boot-retry loop. The commit carries Google's EXEMPT CVE_FIX flag and adds tests for a header length of 4294967295.

The fix narrows the issue rather than eliminating its cause. The unchecked cast stays in the code, and the malformed header is now rejected downstream instead of validated at the parse. That is enough to stop the crash on Android 14 through 17, and it leaves the identical cast unpatched on Android 12 and 13.

How do I check if I was compromised?

An attack that failed to complete may leave no trace, and a successful one leaves a phone that has been crashing. Signs of the flaw itself are unambiguous:

adb logcat -d | grep -i "NegativeArraySizeException"

A hit on NegativeArraySizeException: -2147483648 under com.android.phone is the signature of this decode failing. The poison messages sit in the raw SMS database, which normal SMS apps do not show. List the WAP Push rows and their senders:

adb shell content query --uri content://sms/raw --projection _id:address:destination_port:date:deleted

Rows carrying destination_port=134020, the raw-database encoding of WAP Push port 2948, from senders you cannot account for are the messages to remove. The recovery below was contributed by @sakisdog and documented in the proof-of-concept repository; it must run in the window after the phone boots:

adb shell cmd appops set com.android.shell WRITE_SMS allow
adb shell "content delete --uri content://sms/raw --where \"address='<SENDER>'\""
adb shell cmd appops set com.android.shell WRITE_SMS default

Replace <SENDER> with the address from the query above. If the loop cannot be broken, the last resort erases all SMS and MMS messages and resets APN settings: adb shell pm clear com.android.providers.telephony. Do not choose "wipe data" at the recovery prompt unless you intend a factory reset.

Timeline

• 2026-05-05: Mark B reports the flaw to Google's Android and Devices Vulnerability Reward Program.
• 2026-06-15: An Android engineer authors fix commit 735d9672603fa206c4b43cb668c1aa273db70b97 in the telephony framework.
• 2026-10-01: Google publishes the October 2026 security bulletin, whose patch levels are 2026-10-01 and 2026-10-08. The fix ships for Android 14 through 17 with this update; the flaw is not listed in the bulletin.
• 2026-10-29: Mark B publishes the technical write-up, the proof-of-concept app and source, and @sakisdog documents the ADB recovery.
• 2026-11-02: The public CVE records still do not carry the reported identifier CVE-2026-58882, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog.

FAQ

Is this remote code execution?

No. The demonstrated impact is a process crash and the denial of telephony service that follows it. No source in the disclosure claims code execution, and Google's own fix commit titles the flaw a remote denial of service.

Does the message appear in the Messages app?

No. The attack is a data SMS to port 2948, and Android processes it in the telephony stack before it reaches any inbox. The victim never sees the content and never sees the sender's number, which also makes the attack hard to attribute afterwards.

Why are Android 12 and 13 not fixed?

Google's security updates for the framework ship to supported versions, which for this flaw means Android 14 through 17. Android 12 and 13 devices run the same telephony code but sit outside that update window. Unless a manufacturer backports the change, those devices stay vulnerable for the rest of their service life.

How do I know the CVE number is right?

Treat it as reported, not confirmed. BleepingComputer names CVE-2026-58882, and Google's fix commit carries its EXEMPT CVE_FIX flag, which confirms a CVE was assigned. As of November 2, 2026, the public CVE database and NVD do not yet carry the record, so the number could change when it publishes.

Can a carrier block these messages?

Nothing in the published material describes a carrier-side filter. The malformed value lives inside the WAP Push header of an ordinary data SMS, so blocking would have to target that port or that encoding. No such filtering is described in the published material. The only device-side protection is the October 2026 patch level.

What should an enterprise fleet do this week?

Update every Android 14 through 17 device to the October 2026 patch level, inventory the versions that report Android 12 or 13, and plan their replacement or retirement. Those devices cannot receive the fix, and the attack needs only their phone numbers.

References

• SMS of Death technical write-up, with root cause, impact and proof of concept: https://smsofdeath.com/ (published October 29, 2026; checked November 2, 2026)
• Proof-of-concept app and source, and the ADB recovery discussion: https://github.com/MarkBlah/smsofdeath (published October 29, 2026; checked November 2, 2026)
• Android fix commit 735d9672603fa206c4b43cb668c1aa273db70b97, "RESTRICT AUTOMERGE: Fix remote DoS in decodeWapPdu": https://android.googlesource.com/platform/frameworks/opt/telephony/+/735d9672603fa206c4b43cb668c1aa273db70b97 (authored June 15, 2026; checked November 2, 2026)
• WapPushOverSms.java source at the fix commit, lines 217 and 244: https://android.googlesource.com/platform/frameworks/opt/telephony/+/735d9672603fa206c4b43cb668c1aa273db70b97/src/java/com/android/internal/telephony/WapPushOverSms.java (checked November 2, 2026)
• Android Security Bulletin, October 2026: https://source.android.com/docs/security/bulletin/2026/2026-10-01 (published October 2026; checked November 2, 2026)
• BleepingComputer, "New Android SMS of Death exploit can remotely crash unpatched phones", the source of the CVE-2026-58882 identifier: https://www.bleepingcomputer.com/news/security/new-android-sms-of-death-exploit-can-remotely-crash-unpatched-phones/ (published October 31, 2026; checked November 2, 2026)
• Statcounter Global Stats, worldwide Android version market share, October 2026: https://gs.statcounter.com/android-version-market-share/worldwide (checked November 2, 2026)
• CISA Known Exploited Vulnerabilities catalog, feed checked for CVE-2026-58882: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (checked November 2, 2026)