An independent security researcher named Mark Blaszczykowski has disclosed a vulnerability in Android's telephony stack that lets a remote attacker crash any Android phone with a single SMS — no user interaction required. The bug sits in WapPushOverSms.decodeWapPdu(), where a 5-byte WAP Push header value of 0x80000000 is cast from long to int without a bounds check, producing a negative array size that throws an uncaught NegativeArraySizeException on the telephony main thread. The com.android.phone process dies, active calls drop — including emergency calls — and the victim sees nothing in their inbox. The impact escalates fast. A single message causes a 1-2 second telephony blackout while the process restarts. Carrier redelivery amplifies the damage: because the message is never acknowledged, carriers re-send it, re-crashing the phone. In testing, a single payload caused intermittent outages lasting up to a week. Send approximately 20 messages in rapid succession and the device becomes unusable. Send around 30 and you trigger a race condition that corrupts the SQLite database backing SMS storage, turning a transient crash into a phone that fails on every boot. Recovery from the persistent state is hostile. A factory reset only helps temporarily because the carrier re-delivers the unacknowledged payload and re-triggers the crash loop. Full recovery requires physically removing the SIM, inserting it into a non-Android device to acknowledge the queued messages, and then clearing the corrupt database via ADB. For eSIM users — where the SIM cannot be physically moved — recovery is effectively out of reach without specialist knowledge. The vulnerability was tested on Pixel 9 (April 2026 firmware) and multiple Samsung Galaxy and A-series devices with a 100% reproduction rate. The researcher reported it to Google through the Android & Google Devices VRP on 5 May 2026, providing a one-line fix the same day: a bounds check on the header length before the cast. Google assigned the report, then closed it as Won't Fix (Infeasible) on 20 June. A resubmission was closed within three minutes as Won't Fix (Not Reproducible). A third ticket documenting the SQLite corruption and persistent DoS was marked as a duplicate. The regulatory angle is sharp. Under Australian telecommunications law, carriers must identify phones that cannot reach Triple Zero (000) and are ultimately required to bar those devices from the network. The researcher argues — correctly — that this vulnerability manufactures the exact condition the regulation exists to prevent: a phone that cannot place emergency calls. The perverse outcome is that the regulatory remedy for a remotely-bricked Android phone is not a patch but a network ban on the victim's device. Google's final response, on 29 October 2026, maintained the classification: Won't Fix, Non-Security Issue, no CVE issued. The researcher held the disclosure well beyond the 90-day VRP window before publishing, and has now released a working proof-of-concept on GitHub. The fix remains what it was on day one: a single bounds check on line 217 of WapPushOverSms.java. The disclosure lays bare a structural problem in how the world's dominant mobile OS vendor triages security reports. A remote, zero-click, persistent denial-of-service that drops emergency calls and can brick a phone — reproducible at 100% across multiple OEMs — does not meet Google's severity threshold. The one-line fix was provided six months ago. The question is not whether this is a vulnerability. It is whether Google's vulnerability classification framework is itself the vulnerability.
