--- title: Zero click, silent, remote Android DoS | daily.dev description: A malformed WAP Push SMS crashes com.android.phone on Android with zero interaction from the victim, dropping active calls including emergency calls. The bug... canonical: https://daily.dev/posts/zero-click-silent-remote-android-dos-u70xngqkc twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Zero click, silent, remote Android DoS | daily.dev og:description: A malformed WAP Push SMS crashes com.android.phone on Android with zero interaction from the victim, dropping active calls including emergency calls. The bug... og:url: https://daily.dev/posts/zero-click-silent-remote-android-dos-u70xngqkc og:image: https://api.daily.dev/og/posts/U70XnGqKC.png og:image:alt: Zero click, silent, remote Android DoS og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Zero click, silent, remote Android DoS **[Hacker News](https://daily.dev/sources/hn)** · 5 min read · 0 upvotes · 1 comments ## Summary A malformed WAP Push SMS crashes com.android.phone on Android with zero interaction from the victim, dropping active calls including emergency calls. The bug is in WapPushOverSms.decodeWapPdu(), which reads a WSP header length as a long, casts it to int with no range check, and allocates a byte array with that size. A 5-byte uintvar of 88 80 80 80 00 decodes to 0x80000000, becomes -2147483648 as a signed int, and throws an uncaught NegativeArraySizeException. Sending rapidly in succession, around 30 messages, is described as materially worse, hitting a race condition that corrupts the SQLite SMS database and makes the phone crash on every boot; a factory reset only helps temporarily because the carrier re-sends the payload. Google classified the report as a non-security issue across three tickets and four engineers, and the issue was held well beyond the 90-day window, so full disclosure was published on GitHub. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does a malformed WAP Push SMS crash com.android.phone on Android? WapPushOverSms.decodeWapPdu() reads the WSP header length as a uintvar returned as a long, casts it to int without a range check, and uses it as a byte array size. A 5-byte uintvar of 88 80 80 80 00 decodes to 0x80000000, which becomes -2147483648 as a signed int, causing new byte[-2147483648] to throw an uncaught NegativeArraySizeException that kills the com.android.phone process. _Developers tracking Android telephony security issues can follow disclosures like this one on daily.dev._ ### Can repeatedly sending malicious SMS messages permanently break an Android phone's calling ability? Yes, sending the malformed WAP Push payload roughly 30 times in rapid succession triggers a race condition that corrupts the SQLite database storing SMS messages. Once corrupted, com.android.phone crashes on every boot reading the damaged store, and a factory reset only helps temporarily because the carrier re-sends the unacknowledged payload and re-triggers the crash. _Anyone assessing mobile security risk can track findings like this through daily.dev._ ### What is the fix for the WapPushOverSms.java header length vulnerability in Android? The fix adds a range check before the int cast at WapPushOverSms.java line 217: read the header length as a long, and if it is negative or larger than the PDU length, return RESULT_SMS_GENERIC_ERROR instead of allocating a byte array with that value. This prevents the NegativeArraySizeException that currently crashes com.android.phone. _Engineers patching telephony stacks can keep up with fixes like this via daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 130 comments across hackernews, lobsters (as of 2026-10-29). **TL;DR:** Discussion is split between people debating whether this is a real, exploitable attack (requiring carrier cooperation or a rogue cell tower/IMSI catcher) versus dismissing the whole write-up as AI-generated 'slop' with a melodramatic landing page; several also question Google's 'not a security issue' classification as indefensible. **Sentiment:** 5% positive · 35% mixed · 60% skeptical **The case for** - Some argue the bug is real and serious since it can brick phones and cut off emergency calls, making Google's 'not a security issue' call indefensible. - A few note that with a spoofed cell tower or compromised carrier, the attack could be devastating at scale. - Pointing out that the underlying flaw (unchecked cast to negative array size) is a legitimate, reproducible bug regardless of the presentation. **The pushback** - Many are skeptical of real-world exploitability, questioning whether carriers would actually forward such a malformed message or whether a custom sending app could get it onto the network at all. - Strong backlash against the AI-generated 'hypeslop' landing page style, with commenters saying it undermines trust in the report's legitimacy. - Some suspect the demo requires a sending device/app rather than being truly zero-click remote, calling the 'remote' framing into question. - Doubts raised about the SQLite corruption claim, since SQLite is normally very reliable, fueling suspicion the report could be misleading or even a vector for a trojan APK. - Confusion over Google's Issue Tracker access and whether the issue was really triaged as claimed, with some saying restricted visibility is normal for security reports, muddying the narrative of dismissal. **By community** - hackernews (heated): Sharp divide between those debating real-world severity and carrier trust versus a large contingent dismissing the write-up as AI slop, with side tangents on DND features and the AU emergency-number law. **Hottest debate:** Whether this is a genuinely exploitable, serious remote DoS or mostly AI-hyped 'slop' built around a bug whose real-world triggerability over carrier networks is unproven. **Open questions** - Can an attacker actually inject a malformed WAP Push SMS onto a carrier network without already controlling the carrier or using an IMSI catcher? - Does the SQLite corruption and boot-loop really occur as described, and how exactly does recovery work short of a full factory reset? - Is the demo APK actually sending the crash SMS remotely to any phone number, or does it require pre-existing local access/configuration? - Does this issue affect alternative Android builds like GrapheneOS? **Highlights** > It's not clear, which makes me skeptical that this is all that serious of an issue. I'd like to know - can any devices actually put such a malformed message onto the carrier network? It probably requires at least a custom app that would never be allowed on an app store, if it's possible at all. And do any carriers actually let it go through their network and to a device like a normal message? It's entirely possible the malformed message would crash some software in the carrier's processing stack first and so never be delivered. And if it doesn't, they could easily add a check to block such messages. It's difficult to believe they don't already have some sort of protection against spamming tons of messages to any device. It's also entirely possible it works differently on different carriers, and some but not others might add blocks for this but not make a press release about it or anything. This seems more like meh, minor bug, fix it quietly in the next Android release, not OMG the world is on fire to me. > — [ufmace on hackernews · 1 comments](https://news.ycombinator.com/item?id=50288513) > > can any devices actually put such a malformed message onto the carrier network? It probably requires at least a custom app that would never be allowed on an app store, if it's possible at all. The author has provided an APK that claims to do just that. Hacking tools aren't allowed on app stores, no, but that has no bearing on the severity of vulnerabilities they exploit. > And do any carriers actually let it go through their network and to a device like a normal message? It's entirely possible the malformed message would crash some software in the carrier's processing stack first and so never be delivered. Apparently, unless you're accusing the author of lying. > And if it doesn't, they could easily add a check to block such messages. Your ISP could block RDP but that doesn't lessen the severity of RDP vulnerabilities, shift responsibility, or lessen the need for the vendor to respond in any way, that's not how this works. This is an Android vulnerability and it should be assumed that the carrier is indifferent, actively hostile, cooperating with law enforcement to carry out this attack, or someone might carry out this attack using an IMSI catcher. > It's difficult to believe they don't already have some sort of protection against spamming tons of messages to any device. 20? I doubt it. Do you think the author is lying? > It's also entirely possible it works differently on different carriers, and some but not others might add blocks for this Indeed. What's indefensible is Google's classification that this isn't a security vulnerability. > — [dns\_snek on hackernews](https://news.ycombinator.com/item?id=50289278) > Omfg I am interested in this, I'm interested in wtf a WAP push is, but all I'm getting on this website is Claude-speak "not this, but that" and tables of irrelevant numbers, because Claude fucking loves a table. Look at this Claude shit: > Zero-click. The victim does nothing. No tap, no open, no notification. > Silent. Nothing appears in Messages; the attacker's number is never shown. Congrats, now you sound like yet another AI YouTube advertisement. "You control when we... ...woohoo"... OP, please, if you think you have important information, please write it up yourself, I am so sick and tired of being sent LLM generated Markdown files with zero human input, and now you're just publishing that on a website. FFS. Oh you had Claude publish your name presumably so you'd get credit for "your" "discovery". Mark Blaszczyk, please do better. > — [EdwardDiego on hackernews · 6 comments](https://news.ycombinator.com/item?id=50286278) > Networks still send WAP pushes but you can't just send randomly formatted WAP pushes to your friends. You can, however, use a stingray to MITM your friend's Android phone and send whatever you want to them, because now there is no network firewall to protect them. The combination of MITM and a bug like this could be pretty devastating. > — [dools on hackernews](https://news.ycombinator.com/item?id=50287857) > SQLite data corruption needs some explanation because SQLite is normally very reliable. How do I know this isn't slop written to spread a Trojan horse APK? > — [cowlevel on hackernews](https://news.ycombinator.com/item?id=50289224) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50285452) · 208 points · 130 comments - [lobsters](https://lobste.rs/s/udg9co/single_malformed_wap_push_sms_crashes_com) · 2 points · 0 comments ## Community discussion Top comments from developers on daily.dev. **@abx000x** · 0 upvotes > time to watchout my andriod phone Lol, ## Similar posts on daily.dev - [A 0-click exploit chain for the Pixel 9 Part 1: Decoding Dolby](https://daily.dev/posts/a-0-click-exploit-chain-for-the-pixel-9-part-1-decoding-dolby-nrcxllz0p) · Project Zero · 0 upvotes · 0 comments - [Android Malware Operations Merge Droppers, SMS Theft, and RAT Capabilities at Scale](https://daily.dev/posts/android-malware-operations-merge-droppers-sms-theft-and-rat-capabilities-at-scale-wjogzparr) · The Hacker News · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#cyber](https://daily.dev/tags/cyber), [#java](https://daily.dev/tags/java), [#android](https://daily.dev/tags/android) [View this post on daily.dev](https://daily.dev/posts/zero-click-silent-remote-android-dos-u70xngqkc) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Zero click, silent, remote Android DoS","url":"https://daily.dev/posts/zero-click-silent-remote-android-dos-u70xngqkc","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/zero-click-silent-remote-android-dos-u70xngqkc"},"datePublished":"2026-10-29T10:40:34.401Z","dateModified":"2026-10-29T14:41:54.937Z","description":"A malformed WAP Push SMS crashes com.android.phone on Android with zero interaction from the victim, dropping active calls including emergency calls. The bug...","image":"https://media.daily.dev/image/upload/s--2-1xRawN--/f_auto/v1722860399/public/Placeholder%2011","thumbnailUrl":"https://media.daily.dev/image/upload/s--2-1xRawN--/f_auto/v1722860399/public/Placeholder%2011","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/zero-click-silent-remote-android-dos-u70xngqkc","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"security,cyber,java,android","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Zero click, silent, remote Android DoS"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/zero-click-silent-remote-android-dos-u70xngqkc","comment":[{"@type":"Comment","text":"time to watchout my andriod phone Lol,","datePublished":"2026-10-29T13:55:27.308Z","dateModified":"2026-10-29T13:55:40.466Z","url":"https://daily.dev/posts/U70XnGqKC#c-u5aPpVFFm","author":{"@type":"Person","name":"Abdullahi QULLE","url":"https://daily.dev/abx000x","image":"https://lh3.googleusercontent.com/a/ACg8ocKwmX6XUi5W8GSmhhTN_tjyGWDWaZ2bSA-ARyHW3FokRu8CtTE=s96-c"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/zero-click-silent-remote-android-dos-u70xngqkc#faq","mainEntity":[{"@type":"Question","name":"How does a malformed WAP Push SMS crash com.android.phone on Android?","acceptedAnswer":{"@type":"Answer","text":"WapPushOverSms.decodeWapPdu() reads the WSP header length as a uintvar returned as a long, casts it to int without a range check, and uses it as a byte array size. A 5-byte uintvar of 88 80 80 80 00 decodes to 0x80000000, which becomes -2147483648 as a signed int, causing new byte[-2147483648] to throw an uncaught NegativeArraySizeException that kills the com.android.phone process. Developers tracking Android telephony security issues can follow disclosures like this one on daily.dev."}},{"@type":"Question","name":"Can repeatedly sending malicious SMS messages permanently break an Android phone's calling ability?","acceptedAnswer":{"@type":"Answer","text":"Yes, sending the malformed WAP Push payload roughly 30 times in rapid succession triggers a race condition that corrupts the SQLite database storing SMS messages. Once corrupted, com.android.phone crashes on every boot reading the damaged store, and a factory reset only helps temporarily because the carrier re-sends the unacknowledged payload and re-triggers the crash. Anyone assessing mobile security risk can track findings like this through daily.dev."}},{"@type":"Question","name":"What is the fix for the WapPushOverSms.java header length vulnerability in Android?","acceptedAnswer":{"@type":"Answer","text":"The fix adds a range check before the int cast at WapPushOverSms.java line 217: read the header length as a long, and if it is negative or larger than the PDU length, return RESULT_SMS_GENERIC_ERROR instead of allocating a byte array with that value. This prevents the NegativeArraySizeException that currently crashes com.android.phone. Engineers patching telephony stacks can keep up with fixes like this via daily.dev."}}]} ```