Zero click, silent, remote Android DoS

ComponentWapPushOverSmsframeworks/opt/telephony

InteractionNonezero-click, silent

VectorRemote SMSWAP Push, harbor 2948

Vendor status● Won't Fixclassified Non-Security

ReporterMark Blaszczykindependent

Reported5 May 2026Android & Devices VRP

Disclosed29 Oct 2026after 90-day timeline

CVENoneno CVE issued

01 / The vulnerability

An unchecked mold turns a 5-byte header into a negative gathering size

When Android receives a WAP Push message, WapPushOverSms.decodeWapPdu() says the WSP header dimension as a uintvar. The value comes rear as a long, is mold to int alongside no range check, and is afterward used immediately as the size of a new byte array:

// WapPushOverSms.java:217 header dimension peruse as long, mold alongside no limits check int headerLength = (int) pduDecoder.getValue32(); ... // WapPushOverSms.java:244 the mold value is used as an gathering size byte[] header = new byte[headerLength];

A 5-byte uintvar of 88 80 80 80 00 decodes to 0x80000000. Cast to a signed 32-bit int, that is -2147483648. Allocating new byte[-2147483648] throws an uncaught NegativeArraySizeException on the telephony chief thread, slaying com.android.phone:

E AndroidRuntime: FATAL EXCEPTION: main E AndroidRuntime: Process: com.android.phone E AndroidRuntime: java.lang.NegativeArraySizeException: -2147483648 E AndroidRuntime: at ...WapPushOverSms.decodeWapPdu(WapPushOverSms.java:244) E AndroidRuntime: at ...WapPushOverSms.dispatchWapPdu(WapPushOverSms.java:339) E AndroidRuntime: at ...InboundSmsHandler.processMessagePart(InboundSmsHandler.java:1169) E AndroidRuntime: at ...InboundSmsHandler$DeliveringState.processMessage(InboundSmsHandler.java:627)

The communication is delivered as a data SMS and is never shown to the user: there is nothing in the inbox, and the casualty never sees the sender's number.

02 / Impact

Remote, silent, and recoverable lone alongside effort

• Zero-click. The casualty does nothing. No tap, no open, no notification.
• Silent. Nothing appears in Messages; the attacker's figure is never shown.
• Calls drop, including emergency calls. Active sound calls terminate alongside DisconnectCause CS_DEATH as the procedure restarts.
• Telephony blackout. 1-2 seconds of no assistance per communication during com.android.phone restarts.
• Carrier redelivery amplifies it. Unacknowledged messages are re-sent by the carrier, re-crashing the phone; a sole communication caused intermittent outages for up to a week in testing.
• ~20 messages render the equipment unusable for an extended period.
• Persistent denial of service. Rapid repeated shipment corrupts the SQLite repository rearward SMS storage, turning a momentary collision into a phone that crashes on all footwear (detailed below).

Tested throughout multiple makes and models (Pixel 9 on April 2026 firmware, assorted Samsung Galaxy and A-series) alongside a 100% reproduction rate.

From a 2-second collision to a bricked phone: the SQLite race

A sole communication is a repeated transient outage. Sending the payload quickly in succession (≈30 messages) is materially worse: the crashes interleave alongside the telephony provider's writes to the SMS shop and hit a race circumstance that corrupts the SQLite database holding the device's messages.

Once the repository is corrupt, com.android.phone no longer needs a caller communication to fail: it crashes immediately on all boot as it says the damaged store. The phone is now persistently without telephony, and a restart does not apparent it.

Recovery is hostile, and this is the crucial part: a factory reset lone helps temporarily, since the transporter re-sends the unacknowledged payload and re-triggers the crash. Full improvement required:

• Removing the bodily SIM and inserting it into a non-Android device (e.g. an iPhone) so the carrier's retried messages are acknowledged and halt being redelivered;
• Then clearing the SMS records / corrupt repository complete ADB.

On a equipment using an eSIM, anywhere the SIM can't merely be moved to another handset, improvement would be considerably harder, and for a non-technical user, efficiently out of reach.

This is the difference the study turns on. It is not a transient crash: it is a remote, zero-click, persistent denial of assistance requiring a factory reset (and more) to recover, which is the exact form of a "Destructive Remote DoS" in the VRP's own rules.

03 / Why this is serious

A distant attacker can cut a phone off from Triple Zero

Dropping calls is not an inconvenience whenever one of those calls is to emergency services. While a equipment is under this attack, or bricked by the SQLite corruption, it cannot reliably location a call to 000. The assault is remote, needs lone the victim's number, and shows them nothing.

Australia treats admission to emergency calling as a mandatory asset of a mobile service, not a nice-to-have. Under the Telecommunications (Emergency Call Service) Determination, administered by the ACMA, carriers are required to identify mobile phones that cannot attain Triple Zero, assistance the client move to a operating device, and halt providing assistance to the affected handset. Telstra states plainly that it is required to obstacle phones that can no longer call 000, notifying the client and blocking the equipment if nothing is done inside 28 days.

The consequence is perverse: the regulatory remedy for a phone that can't attain 000 is to cut it off the network, not to place the OS. So an attacker who can remotely induce that circumstance on an Android handset can, in effect, get the victim's own equipment barred from transporter assistance until a fix exists. The regulation exists exactly since defeat of emergency-call admission is considered a public-safety failure; this bug manufactures that nonaccomplishment on demand.

The example was tightened in 2024 following the 3G shutdown, which remaining several phones capable to create average calls but unable to attain emergency services, the identical functional province this exposure produces.

Sources: ACMA: projected amendments to the ECS Determination · Telstra: Emergency Call Service Determination · Dept. of PM&C: effect analysis

04 / The fix

One limits check

The remedy is a range inspect before the mold in WapPushOverSms.java (line 217), provided to Google on the day of the archetypal report:

long rawHeaderLen = pduDecoder.getValue32(); if (rawHeaderLen < 0 || rawHeaderLen > pdu.length) {  result.statusCode = Intents.RESULT_SMS_GENERIC_ERROR;  come back result; } int headerLength = (int) rawHeaderLen;

05 / Disclosure timeline

Communication alongside Google

The study was submitted through the Android & Google Devices VRP and resubmitted twice as a mis-triage appeal. Across three tickets and four engineers, Google classified it as a non-security issue.

Researcher Android Security Team Status change

• 5 May 2026ResearcherReport filed: zero-click WAP Push collision in WapPushOverSms (issue 509520497). Suggested fix provided the identical day.
• 5 May 2026Android SecurityAssigned for investigation; investigator asked to prosecute coordinated disclosure.
• 15 May 2026ResearcherRequests higher priority: reproduced on 5 handsets, emergency-call impact, Australian transporter regulations.
• 20 Jun 2026Android SecurityClosed Won't Fix (Infeasible): "not a safety vulnerability."
• 20 Jun 2026ResearcherClarifies this is a distant imperishable DoS; ~20 messages permanently disable the phone. Resubmits as petition (issues 525810560 and 525816147, "SMS of DEATH").
• 20 Jun 2026Android SecurityResubmit 525810560 closed inside 3 minutes Won't Fix (Not Reproducible).
• 22 Jun 2026ResearcherReports SQLite misconduct from fast sends → collision on boot; improvement needs SIM toggle to a non-Android equipment + ADB.
• 23 Jun 2026Android SecurityRequests disclosure plans; reminds of the 90-day VRP timeline and asks to assessment any write-up in advance.
• 23 Jun 2026ResearcherAgrees to clasp for community safety; offers to concise Australian carriers so they can agenda a block. Restates the one-line fix.
• 2-3 Jul 2026Android SecurityAppeal marked Duplicate of the original; re-evaluation confirms identical base cause.
• 16 Jul 2026Android SecurityOriginal reopened following the matter surfaced on Discord, afterward confirmed a copy again.
• 16 Jul 2026ResearcherAdds detail: the behavior meets the VRP's own "Destructive Remote DoS" criterion.
• 17 Jul 2026Android SecurityAcknowledges the additional context; triage to obtain another look: "4 engineers volition have evaluated the report."
• 27 Oct 2026ResearcherRequests a position update following three months of silence.
• 29 Oct 2026Android SecurityFinal decision: Won't Fix, quoting "does not encounter the severity threshold ... considered a Non-Security Issue (NSI)."

Why this is public. The matter was reported privately and held fine beyond the VRP's 90-day window. Google declined to fix it throughout three tickets and four engineers, classifying a remote, zero-click, emergency-call-dropping denial of assistance as a non-security issue. Full disclosure follows so that users, carriers and downstream OEMs can measure the hazard and mitigate.

06 / Proof of concept

Source & APK

The proof-of-concept Android app and complete origin code are published on GitHub. The app crafts the malformed WAP Push PDU and sends it as a data SMS to a mark number.