Technical details and proof-of-concept code have been published for a vulnerability that can disable Android's cellular functionality with a single SMS and no user interaction. Fixes are available for Android 14–17, while older devices, including those running Android 12 and 13, remain outside their scope.
Key points
- What happened: A zero-click vulnerability in Android's WAP Push SMS processing can disable phone functionality without user interaction; technical details and proof-of-concept code are now public
- Why it matters: Ongoing calls, including emergency calls, are disconnected. If repeated messages cause a reboot loop, ordinary users cannot distinguish it from a failure requiring a factory reset
- Fix coverage: Google's fix is available for Android 14–17 but does not reach Android 12 or 13. CVE-2026-58882 is expected to appear formally in November's security bulletin
A five-byte value breaks Android's phone functionality
According to a technical analysis published on October 29 local time by security researcher Mark Blaszczyk, the problem lies in Android's processing of WAP Push SMS messages.
smsofdeath (machine translation)
WAP Push lets carriers send configuration information, download instructions, and similar data to devices through SMS. Unlike ordinary text messages, it is processed automatically inside Android before appearing in the user's SMS inbox.
The vulnerability originates in a method called WapPushOverSms.decodeWapPdu(). It reads a WAP Push message's header length as a variable-length integer, then converts that value to a signed 32-bit integer. No range validation occurs during the conversion.
The researcher's attack sends an eight-byte message containing a five-byte value (88 80 80 80 00) as a data SMS to port 2948. Those five bytes should be read as 2,147,483,648, but conversion to a signed 32-bit integer produces -2,147,483,648. When Android attempts to allocate memory using this negative value as an array size, it throws a NegativeArraySizeException.
The exception is not caught, causing com.android.phone to stop. com.android.phone handles Android's cellular communications, including voice calls. An ongoing call is disconnected. In the researcher's tests, emergency calls were also interrupted.
Nothing appears on the user's screen. No message remains in the SMS inbox, and the sender's number is not visible.
How one message becomes a week of disruption
The impact extends beyond a single crash.
Even after com.android.phone crashes, the process restarts automatically within seconds. The problem is what happens to the message that caused the crash. Messages Android could not successfully receive remain in the device's pending queue, while the carrier redelivers them as undelivered messages. Either path reprocesses the offending message, repeating the crash.
In the researcher's tests, one message caused intermittent disruption lasting up to a week. Every carrier redelivery stopped the device's communications for several seconds.
Bulk delivery has more serious consequences. Sending about 20 messages causes continuous crashes immediately after boot, leaving the device unusable for an extended period. A GitHub report describes an Android 12 device repeatedly rebooting roughly every 90 seconds, with Android's automatic recovery mechanism, RescueParty, prompting entry into recovery mode. To an ordinary user, it looks like a failure requiring a factory reset.
A recovery method has been published for this reboot loop using ADB (Android Debug Bridge), a developer tool for controlling a device from a PC. Identifying and deleting the offending messages in the pending queue can stop the loop without a factory reset. However, this requires a PC connection and prior ADB configuration, and the operation must be completed in the brief interval between reboots.
The researcher reports testing a Pixel 9 with April 2026 firmware and several Samsung Galaxy models, with a 100% reproduction rate in every case.
Fix created in June, formal listing expected in November
The researcher reported the issue through Google's vulnerability reward program on May 5, 2026. Android's source code contains a fix commit dated June 15, titled "Fix remote DoS in decodeWapPdu" (fixing a remote denial of service in decodeWapPdu).
The fix differs from the researcher's proposal. The researcher suggested range checks to verify that the header length was neither negative nor greater than the actual data length. Google instead broadened the catch clause from ArrayIndexOutOfBoundsException to RuntimeException, preventing exceptions from stopping the process, and combined this with deletion of unsuccessfully processed messages from the database to prevent reboot loops.
The fix is associated with CVE-2026-58882, rated Critical. However, the identifier does not appear in Google's October 2026 Android Security Bulletin. GrapheneOS, an Android-derived OS focused on privacy and security, says the CVE is scheduled for November's security bulletin. GrapheneOS says it has included the fix since its July release.
The fix covers Android 14–17. Android 12 and 13 are outside Google's security-update support window and will not receive it. The vulnerability has been reproduced on Android 12 through 16, leaving the issue unresolved on devices that do not receive a fix.
Android devices in Japan could experience the same effects if they use an unpatched implementation. The conditions for sending this type of message through Japanese carriers, and any attacks in Japan, have not been confirmed at present, but the affected code is part of Android's shared platform. What users can currently do is check whether their device's security patch level reflects the latest updates. In Android Settings, open "About device" or "About phone" and check "Android security update."
Originally published on Joho no Todai. The Japanese original is here.
Top comments (0)