Android SMS Flaw Can Drop Emergency Calls

A newly disclosed Android SMS flaw can drop active calls, including emergency calls, without asking the recipient to open a message. The proof-of-concept is public, so owners of degoogled phones should check their operating system version and install the newest security update offered by their project.

The vulnerability is tracked as CVE-2026-58882 and has been called “SMS of Death.” It is a denial-of-service problem rather than a way to read messages or steal data. Its practical effect can still be serious: the malformed message crashes Android’s cellular-service process, and repeated delivery can produce a reboot loop.

What the malformed message does

According to BleepingComputer’s technical account of the exploit, the attack sends an eight-byte WAP Push message to an Android phone. WAP Push messages are processed before they reach the ordinary SMS inbox, so the recipient does not see the message or its sender.

The malformed header contains a length value that becomes a negative number when Android converts it to a signed 32-bit integer. Android then attempts to allocate an array using that invalid length. The resulting NegativeArraySizeException crashes com.android.phone, the process responsible for cellular functions.

That crash interrupts mobile connectivity and disconnects an active voice call. No tap, link, app installation, or notification is required. The published testing described by the sources covered Pixel and Samsung devices, but the vulnerable component is part of Android’s telephony framework rather than a particular messaging application.

Why repeated delivery is worse

A single crash can briefly interrupt service. The larger risk comes from the way the malformed message may remain queued or be redelivered by a carrier after Android fails to acknowledge it.

Android Authority’s report on the disclosure says repeated processing can cause persistent crashes. The researcher reported that about 20 malicious messages could leave a phone practically unusable and potentially trapped in a boot loop.

Recovery may then require connecting the device to a computer and clearing the pending messages with Android Debug Bridge. BleepingComputer describes that method as requiring advanced technical knowledge. In the reported Android 12 test, the phone entered recovery approximately every 90 seconds, and a factory reset was otherwise required.

The published proof-of-concept means this is no longer only a theoretical fault. It should not be tested against another person’s phone: doing so could deliberately disrupt cellular and emergency service.

Which Android versions need attention

The vulnerable code dates back to Android 12. The researcher says Google’s correction was released for Android 14 through Android 17 in the October 2026 security update. Android 12 and Android 13 devices outside their security-update window did not receive that correction.

There is some uncertainty around how the patch is labeled. BleepingComputer reports that CVE-2026-58882 does not appear in Google’s public October bulletin even though the relevant code fix shipped through the October security updates. Android Authority reports that GrapheneOS said the vulnerability was scheduled for the November bulletin and that Google had already distributed the underlying correction through earlier security previews.

For a degoogled phone, the important factors are the Android base and whether its OS maintainer incorporated the correction. Removing Google apps, avoiding a Google account, or replacing Play services does not affect the WAP Push processing path described in these reports. A recent custom-ROM build date alone also does not prove that this particular fix is present.

GrapheneOS, CalyxOS, LineageOS, /e/OS, iodéOS, and other Android distributions publish updates on different schedules. Owners should therefore rely on their project’s release notes and installed security patch information rather than assuming that every Android 14-or-newer build is protected.

What owners should do

1. Open the phone’s system information and record its Android version, OS build number, and Android security patch level.
2. Install every pending operating-system update, then restart if the updater requests it. This matters more than updating the SMS app because the flaw is in Android’s telephony framework.
3. If the phone remains on Android 12 or Android 13 without current security fixes, check whether its degoogled OS offers a supported newer branch. If not, plan a move to maintained hardware or software.
4. If unexplained cellular crashes develop into a reboot loop, seek help from someone familiar with ADB before assuming a factory reset is the only recovery path.

The safest conclusion is narrow: supported phones should take their newest available system update, while owners of unpatched Android 12 and Android 13 devices should treat the public exploit as a concrete reason to leave an unsupported build.