Android zero-click SMS bug causes persistent denial of service

A critical zero-click vulnerability in Android allows attackers to remotely disable mobile devices by sending a single malformed data SMS. Discovered and reported in mid-2026, the flaw affects multiple device manufacturers and persists across reboots until manually cleared or patched. Google addressed the issue in the October 2026 security update, but unpatched devices remain at risk of permanent service disruption.

What happened

The vulnerability targets the way Android processes WAP Push messages, a legacy protocol used to deliver configuration settings and multimedia content via SMS. Unlike standard text messages, these data SMS are processed silently in the background without user interaction or visible notifications. An attacker needs only the victim's phone number to send a specially crafted packet that triggers a crash in the telephony subsystem.

When the malicious message arrives, the com.android.phone process crashes immediately. This causes active voice calls to drop with a DisconnectCause CS_DEATH error and creates a brief telephony blackout lasting one to two seconds. Because carriers automatically redeliver unacknowledged messages, the phone enters a destructive cycle. Each redelivery attempt re-triggers the crash, leading to intermittent outages that can last for days. In testing, approximately twenty such messages rendered devices completely unusable for extended periods.

The impact is particularly severe because the malformed message remains queued in the system. Every time the device boots, it attempts to process the pending message, crashes again, and reboots. This loop continues until the message is deleted or the device is factory reset. The issue was reproduced with 100% consistency on Pixel 9 devices running April 2026 firmware, as well as various Samsung Galaxy and A-series models.

How it works

The root cause lies in how the Android framework decodes WAP Push Protocol Data Units (PDUs). Specifically, the WapPushOverSms.java component fails to validate the length of the header data before casting it to an integer. When a malicious PDU contains a header length value that is negative or exceeds the actual packet size, the system throws an exception that was not previously caught by the error handling logic. This unhandled exception crashes the entire telephony process.

Google’s initial recommended fix involved adding a bounds check to validate the header length before processing. However, the final patch shipped in the October 2026 security release took a different approach. Instead of just validating the input, engineers widened the exception handler to catch all RuntimeException errors during decoding. Crucially, the updated code now deletes the poison message from the raw storage table if decoding fails. This prevents the message from being retried on subsequent boots or carrier redeliveries, effectively breaking the denial-of-service loop.

Key details

• Zero-click exploitation: No user interaction is required; the message is never displayed in the inbox.
• Persistent DoS: The malformed message survives reboots, causing a crash loop every ~90 seconds via Android RescueParty.
• Emergency call failure: Active calls drop, and the device cannot reliably connect to emergency services like 000.
• Carrier amplification: Network redelivery of unacknowledged messages sustains the attack without further attacker involvement.
• Recovery complexity: Removing the message requires ADB access to delete specific rows from content://sms/raw, which is difficult for non-technical users.
• Patch availability: The fix is included in the October 2026 Android security update for Android 14 through 17.

Why it matters

For software engineers and security professionals, this vulnerability highlights the dangers of implicit trust in legacy protocols. WAP Push is an older technology, yet it remains integrated into modern Android stacks. The failure to validate input lengths before type casting is a classic error that led to a remote, persistent denial of service. It demonstrates that even silent, background processes can have catastrophic effects on device availability if error handling is insufficient.

The broader implications extend beyond technical inconvenience. In Australia, access to emergency calling is a mandatory regulatory requirement. Under the Telecommunications (Emergency Call Service) Determination, carriers must identify and block devices that cannot reach emergency services. If a phone is stuck in a crash loop, it cannot dial 000. Consequently, carriers are required to cut off service to the affected handset after 28 days if the issue is not resolved. This creates a perverse outcome where a successful attack leads to the victim’s device being barred from the network entirely, rather than just being temporarily disrupted.

What you can do

• Update immediately: Ensure your device is installed with the October 2026 Android security patch or later.
• Verify patch level: Check Settings > Security > Security Update to confirm your current patch level.
• Use ADB for recovery: If stuck in a reboot loop, use Android Debug Bridge to query and delete rows from content://sms/raw where the destination port is 134020.
• Avoid factory reset: Do not select "wipe data" in recovery mode unless absolutely necessary, as this erases all user data.
• Restrict SMS permissions: While not a complete fix, limiting which apps can send or receive SMS may reduce exposure to other vectors.
• Monitor carrier notices: Be aware that prolonged inability to make emergency calls may result in automatic service suspension by your carrier.