As reported by SecurityAffairs, independent researcher Mark Blaszczyk has disclosed a zero-click denial-of-service flaw in Android that allows a single crafted WAP Push SMS to crash the com.android.phone process — effectively halting telephony, interrupting active calls, and blocking access to emergency services. Shield53 views this as a meaningful exposure issue rather than a remote code execution risk, but the operational impact is serious for any organization or individual reliant on Android devices for critical communications.
Technical Summary
| Attribute | Detail |
|---|---|
| Flaw name | SMS of Death |
| Attack vector | Zero-click WAP Push SMS |
| Affected component | WapPushOverSms (frameworks/opt/telephony) |
| Root cause | uintvar WSP header length cast 64-bit to 32-bit without range check; induces NegativeArraySizeException |
| Trigger payload | Five-byte WSP header producing value -2147483648 |
| Impact | Telephony crash, call interruption, emergency call denial |
| Interaction required | None (zero-click) |
| Vendor patch | Awaiting Google security bulletin; no CVE assigned at time of reporting |
| Active exploitation | Public disclosure only; no confirmed in-the-wild abuse |
Why It Matters
The defining risk here is not data theft or code execution — it is availability. The flaw targets the mobile radio interface layer, the most fundamental communication channel on a smartphone. Because WAP Push messages are handled silently by the OS and require no user consent, attackers need only know the target's phone number, and the message can be delivered over legacy SS7/SMS infrastructure that is largely unfiltered by carriers. For individuals, repeated triggering could leave a device unable to place calls for the duration of the attack window. For enterprises — particularly those in sectors where Android devices are used for incident response, on-call rotations, or field operations — this represents a denial-of-service path against the workforce itself.
The emergency services angle is the most concerning dimension. If an attacker can repeatedly crash the phone process on a target device, they can effectively prevent the user from reaching 911 or local emergency numbers during a crisis. In regulated environments where duty-of-care obligations apply to emergency communications, this could trigger legal and compliance exposure beyond the technical remediation.
Broader Implications
- Legacy SMS remains an attack surface. WAP Push is a protocol from an era of feature phones, yet it is still processed by modern Android. This is a recurring pattern: carriers and OS vendors carry forward legacy signaling features long after their consumer value has faded, creating attack surface that few defenders monitor.
- Zero-click + carrier reach = scale. An attacker does not need a network foothold on the device. A compromised SMSC or an abusive SMS gateway can target thousands of numbers in parallel.
- Crash bugs in telephony deserve CVE respect. Historically, DoS-only telephony bugs have been underweighted relative to RCE. This flaw's ability to block emergency calls should reframe how vendors triage this class of report.
Who Is at Risk
Any Android device running a build that includes the vulnerable WapPushOverSms handler in its default configuration is potentially affected. Highest-risk populations include:
iOS devices are not affected by this specific flaw; the issue is isolated to the Android telephony framework component.
Shield53 Recommendations
Immediate Actions
- Inventory exposure. Identify all Android devices in your estate, including BYOD, IoT, and field units. Confirm carrier and OS version to scope remediation.
- Monitor for the patch. Track the next Google Android Security Bulletin and the researcher's disclosure timeline. When a CVE is assigned, link it to asset inventory for tracking.
- Suppress WAP Push at the carrier boundary where possible. Some MNOs and MVNOs allow enterprise mobile management accounts to filter WAP Push at the gateway. Ask your carrier whether this traffic class can be blocked for business lines.
- Deploy detection. Mobile device management (MDM) and endpoint detection tools should alert on repeated
com.android.phoneprocess crashes or unexpected telephony restarts as potential indicators of repeated SMS of Death triggers. - Provide fallback emergency comms. For high-risk users (emergency services, executives, on-call staff), ensure a secondary communications path — a second carrier, a different OS, or landline escalation — so a single-channel DoS cannot fully isolate them.
Strategic Actions
- Pressure carriers on SMS signaling hygiene. Enterprises should request from their MNOs evidence of SS7 and SMSC-level filtering of malformed WAP Push traffic, not just device-side patching.
- Update mobile security baselines. Incorporate telephony DoS into your mobile threat model. Most current mobile hardening guides focus on app sandboxing and data protection — they should also cover signaling-layer availability.
- Prioritize patch SLAs for critical communicators. Define a 72-hour patch SLA for telephony-layer CVEs on devices used by emergency-response personnel, separate from the standard patch cadence.
Takeaway: SMS of Death is not a breach flaw — it is a reachability flaw. For organizations whose safety, response, or revenue depends on Android phone calls being available on demand, this is a 911-level exposure that deserves the same urgency as a critical RCE.
