The PoC author argues the malformed PDU is parsed by the modem firmware or vendor RIL daemon before the Android application layer ever sees the SMS, which is why no user interaction is required. Because baseband firmware runs on a separate processor with its own OS and is shipped as signed vendor blobs, the fix has to come from Qualcomm/MediaTek, not Google.
The editorial frames this PoC as the latest entry in a lineage going back to Collin Mulliner's 2010 Black Hat talk and the 2019 Simjacker/WIBattack campaigns. The novelty isn't the attack class but the breadth — current Android builds across multiple SoC vendors are affected, implying either a shared upstream component or a protocol ambiguity each vendor independently mishandles.
A site at smsofdeath.com published a proof-of-concept for a zero-click, silent, remote denial-of-service against Android handsets delivered over cellular SMS. The attack requires only the victim's phone number. There is no tap, no preview, no notification — the device just reboots or wedges the radio stack. The disclosure went to the Hacker News front page on October 29 with 106 points and the kind of comment thread that only happens when the PoC actually works on commenters' own hardware.
The mechanism, as described in the writeup, lives in how the modem and the RIL (Radio Interface Layer) parse incoming PDU-encoded SMS. The payload is a specifically malformed SMS protocol data unit that triggers an unhandled exception inside the baseband firmware or the vendor RIL daemon before Android's application layer ever sees it. Because SMS delivery is a push protocol brokered by the SMSC (the carrier's Short Message Service Center), the victim doesn't have to open anything. The radio receives the frame, tries to decode it, and dies.
This is not new as a class — researchers have been publishing SMS-of-death variants since Collin Mulliner's 2010 Black Hat talk on feature-phone bricking, and the Simjacker and WIBattack campaigns of 2019 showed the SIM Application Toolkit surface is still live. What's notable here is the breadth: the PoC reportedly affects current Android builds across multiple SoC vendors, which implies the bug is either in a shared upstream component (Qualcomm's QMI stack, MediaTek's RIL, or AOSP's `telephony-common`) or in a protocol-level ambiguity that each vendor fumbles independently.
The interesting part is not that Android can be DoS'd. The interesting part is which layer of the stack the attacker is talking to, and which layer owns the fix. Baseband firmware is a different operating system than Android. It runs on its own processor, with its own memory, often with no MMU, and it's shipped as a signed blob by the modem vendor — not by Google, not by the OEM building the handset. When Krzysztof Opasiak and others reverse-engineered Samsung's Shannon baseband in 2020, they found a Monte Carlo of unchecked length fields and classic stack smashes. Those bugs don't get CVEs on the Android Security Bulletin. They get silent fixes in modem firmware updates that reach maybe 30% of devices.
The second thing worth sitting with: this is a carrier-filterable attack. SMSCs already drop malformed PDUs for billing reasons, and T-Mobile, Verizon, and the European MNOs have signaling firewalls (Oracle, Enea, SecurityGen) that inspect SMPP and SS7 traffic. A regex on the offending TPDU structure deployed at the SMSC blocks the attack for every subscriber on that network, instantly. That's a faster mitigation path than waiting for Samsung to ship a firmware OTA to the Galaxy S22 you bought in 2022 that stopped receiving updates last quarter. The practical response to SMS-of-death bugs runs through GSMA working groups and carrier NOCs, not through Google's monthly patch train.
The HN thread is doing what HN threads do: half the comments are people confirming their Pixel 8 rebooted, the other half are arguing about whether an unauthenticated reboot even counts as a vulnerability. It does. A targeted attacker who knows your number — journalists, dissidents, executives at an acquisition deadline, on-call SREs during an incident — can keep your phone in a reboot loop for the duration of the window that matters. The DoS is the attack. You don't need code execution if the goal is to make the phone unreachable at 2:47 AM when PagerDuty is trying to escalate.
There's also the uncomfortable supply-chain angle. SMS PoCs this clean usually mean the author found the bug by fuzzing the RIL against a captured corpus of carrier traffic, which means the carrier already saw this exact malformed PDU in the wild. The question nobody is asking publicly: how long has this been a signal in SMSC logs before smsofdeath.com published?
For practitioners, three concrete moves.
First, check your out-of-band channel assumption. If your incident response or 2FA fallback relies on SMS reaching an on-call engineer's phone, you have a dependency on a protocol you don't control, running on firmware the OEM doesn't patch, filtered by a carrier you have no SLA with. Any on-call rotation whose last-mile wake-up is cellular SMS should have an authenticated-push backup (Pushover, Opsgenie's app push, or a plain phone call) that doesn't share the baseband failure mode. This is the lesson from the 2023 T-Mobile outage and from every Signaling-System-7 interception story since 2016, and it still hasn't landed in most runbooks.
Second, move high-value 2FA off SMS, now, not Q2. NIST deprecated SMS as a second factor in SP 800-63-3 back in 2017 and softened it only under pressure. If an attacker can brick a target's phone for ten minutes, SMS-OTP account recovery becomes a race condition the attacker wins. TOTP apps, FIDO2 hardware keys, and passkeys all survive a baseband DoS because they don't need the radio.
Third, if you ship an Android app whose threat model includes targeted users — secure messengers, journalist tools, crypto wallets, protest apps — add a telemetry signal for unexpected modem resets. The Android `TelephonyManager` exposes `getRadioHalVersion()` and listeners on `ServiceState` changes. A sudden spike of radio-off → radio-on cycles with no cell-tower change is a reasonable canary that someone is poking at the baseband.
Expect Google to issue a Pixel firmware update inside two cycles and a terse Android Security Bulletin entry with a CVE that lands in the Critical bucket. Expect Samsung and Xiaomi to ship fixes to their flagships within a quarter and to abandon the mid-tier devices entirely. Expect the carriers to deploy SMSC filters within days — they already have the tooling, and the business case is self-interest, because a bricked phone is a lost monthly ARPU. The durable fix is not patching the parser; it's shrinking the attack surface that reaches the baseband in the first place, and that conversation — RCS-over-IP, iMessage-style modern transports, finally retiring SMS — has been stalled on carrier revenue for a decade. Until that moves, SMS-of-death class bugs will keep returning, because the protocol they exploit was designed when the phone on the receiving end had 4KB of RAM and no concept of a stack canary.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.