Zero click, silent, remote Android DoS

Original Article ↗ Hacker News Discussion ↗

A recently disclosed Android vulnerability allows a single malformed WAP Push SMS to repeatedly crash the system phone process, dropping active calls (including emergency calls) with no user interaction and potentially leaving devices unable to place calls until the SIM is moved to another handset. Commenters debate how serious this denial-of-service risk is in practice, how easily such messages can be sent over real networks, and whether carriers or fake base stations could weaponize it at scale. Much of the conversation also criticizes the AI-generated “hypey” write-up and Google’s initial “won’t fix” triage, noting that Google has since assigned a CVE and shipped a patch (already incorporated by GrapheneOS) after what appears to have been an internal miscommunication.

Vulnerability & Impact

  • Malformed WAP Push data SMS (e.g., to port 2948) can crash Android’s com.android.phone, dropping calls, including emergency calls, with no user interaction or visible message.
  • Repeated delivery can corrupt an internal SMS/telephony SQLite DB, causing the phone process to crash on every boot. Device effectively loses phone capability while Wi‑Fi still works.
  • Recovery described as: move SIM/eSIM profile to a non‑Android device (so pending messages get ACKed), then clean up the corrupted DB (e.g., delete telephony.db) or factory reset. For eSIM this is much harder.
  • Some question whether SQLite should corrupt from a mid‑write crash; others assert they observed DB corruption in practice.

Exploitability & Role of Carriers

  • PoC APK is provided to send the malformed SMS from one device to any target phone number; no local compromise of the victim is needed.
  • Several commenters with experience say non‑user‑visible SMS types (WAP Push, silent SMS, APN config, voicemail indicators) are real and often not filtered.
  • Others are skeptical: unclear if arbitrary malformed WAP Push messages can traverse all carrier networks, or if some networks already filter or drop them.
  • Scenarios discussed: personal harassment (e.g., against an ex), targeted disruption/suppression, or attacks combined with IMSI catchers / spoofed towers.

Severity, Google’s Response & Patching

  • Debate over severity: some see it as a “temporary DoS” and minor; others stress that remotely disabling emergency calling is a serious security issue.
  • Google initially classified the report as “won’t fix” / “not a security issue,” likely via a front‑line triager. This drew criticism and was framed as part of a broader quality decline and VRP overload.
  • Later comments note that Google actually committed a fix in June, shipped it via security preview patches in July, and it will appear in the November 2026 Android Security Bulletin as CVE‑2026‑58882 (Critical). Earlier closure is attributed to internal miscommunication/duplicate handling.
  • A hardened Android fork reports having shipped the fix months earlier and confirms its own users are not affected.

AI‑Generated Write‑Up & “Slop” Debate

  • Many comments focus on the landing page’s AI‑generated tone: “hypeslop,” over‑dramatic marketing language, and characteristic phrasing.
  • Some argue the AI polish obscures technical clarity and hurts credibility; others defend using LLMs for layout/copy, given the bug and PoC are real.
  • Meta‑discussion about HN upvoting AI‑generated vulnerability sites despite widespread complaints about “AI slop.”