Android WAP Push Flaw Turns One Silent Text Into A Telephony Outage

Security researcher Mark B published a working proof of concept for CVE-2026-58882 on October 29. The flaw sends a malformed WAP Push data SMS to Android's telephony framework. On the tested phones, an unchecked length conversion causes an exception that kills the phone process, briefly removes cellular service, and drops an active call without any action by the recipient. Repeated delivery or queued messages can make the failure persistent enough to force a difficult recovery.

Google's public source tree contains a corrective commit that catches runtime failures during WAP Push decoding and removes the poison message from the raw SMS database. The researcher says the fix reached Android 14 through 17 in the October 2026 update, but CVE-2026-58882 does not appear in Google's public October bulletin. That gap makes a generic patch date incomplete proof. Device owners should obtain model-specific confirmation from the manufacturer, update supported phones, retire unsupported critical-use devices, and prepare an alternate communication path.

The researcher published a technical write-up and sender application on October 29 after reporting the issue to Google's Android and Devices Vulnerability Reward Program on May 5. The write-up identifies the affected component as `WapPushOverSms` in the Android telephony framework and demonstrates delivery as a WAP Push data SMS on port 2948. The supplied proof of concept needs SMS permissions on the sending Android phone but no software on the receiving phone.

On receipt, the malformed message is processed below the normal messaging interface. The researcher reports that it does not appear as an ordinary visible message and that no link, attachment, notification, or approval is required. A successful trigger kills `com.android.phone`, the process responsible for cellular functions. The immediate result is a short loss of service and termination of an active call, including an emergency call in the researcher's test.

The public evidence supports a remote, zero-interaction availability flaw. It does not establish that an attacker can execute code, read messages, obtain the phone's contents, impersonate the subscriber, or persist outside the queued-message behavior. No vendor or government source cited here reports malicious exploitation. The risk changed on October 29 because usable code became public, not because a confirmed campaign was disclosed.

WAP Push is a legacy carrier-facing mechanism used to deliver structured data to a handset. Android's decoder reads the WSP header length as a larger unsigned-style value, then converts that value to Java's signed 32-bit `int`. The researcher shows a crafted five-byte length that becomes the minimum negative integer after conversion. The older path then uses that result as the size of a new byte array.

Java rejects a negative array size by throwing `NegativeArraySizeException`. In the vulnerable flow, that runtime exception reaches the main telephony thread and terminates the process. Restarting the process restores service after a single message, but the underlying delivery system can retry a message and Android can read a stored raw message again. That changes a brief crash into repeated service loss without requiring a more powerful exploit primitive.

Google's public commit, authored June 15 and committed to the visible tree in August, is titled `Fix remote DoS in decodeWapPdu`. It wraps WAP Push decoding and the related broadcast operation in runtime-exception handling, logs the failed delivery, and deletes the poison tracker from the raw database. The commit also adds tests. That fix is narrow and appropriate: reject the malformed input and remove the object that would otherwise trigger the same failure again.

One crash can disconnect a call and briefly remove cellular service. The researcher reports that sending about 20 messages made tested phones substantially harder to use and that one Android 12 device repeatedly rebooted into recovery. These are laboratory observations from selected Pixel and Samsung devices, not proof that every model, carrier, radio stack, or Android build fails identically. Queue behavior, process restart policy, and manufacturer changes can alter the result.

The operational consequence is still larger than an ordinary messaging-app crash. Telephony is an emergency and business-continuity dependency. On-call staff, lone workers, field teams, travelers, healthcare personnel, dispatch users, and people who rely on one mobile device for emergency contact can lose the channel they expect to remain available. A denial-of-service event does not need confidentiality loss to create physical or operational risk.

Organizations should avoid testing the public payload on production phones or carrier networks. Sending it to another person's device can interrupt emergency access and may violate law or carrier policy. Validation belongs on owned lab devices with explicit authorization, isolated test numbers, a documented recovery plan, and no dependency on the handset for real calls. Most teams can verify patch provenance without transmitting the exploit at all.

The researcher's current page says Android 12 through 17 are affected and that Android 14 through 17 received the fix in the October 2026 update. BleepingComputer independently links the AOSP commit and reports the same delivery boundary. Google's October Android Security Bulletin, however, does not list CVE-2026-58882 among the issues associated with the 2026-10-01 patch level. The public bulletin therefore cannot by itself prove that a phone with that date includes this particular correction.

Android patch delivery is distributed. Google can merge a platform change, while a manufacturer selects and integrates changes into model-specific firmware and a carrier may affect rollout timing. An Android security patch string represents a vendor assertion about the bulletin level, not a hash of every upstream commit. Ask the device manufacturer or enterprise mobility provider whether the exact build includes Android bug 517376969 or the equivalent fix for WAP Push runtime failures.

Record manufacturer, model, region, carrier, Android release, build number, security patch level, update channel, and the date the device actually installed the build. Treat unsupported Android 12 and 13 phones in critical roles as a replacement problem unless the manufacturer provides a specific backport. Disabling an ordinary messaging app or hiding SMS notifications does not remove processing in the lower telephony service.

Prioritize phones whose loss would matter most. Update supported devices, enforce minimum builds through mobile-device management where possible, and prevent an unverified or unsupported phone from being the only route for emergency duty. A fallback can include a second managed phone on a different platform or carrier, a radio, a desk line, a secure data messenger on a separate device, or a documented call tree. The alternate path must not depend on the same handset and SIM.

Carriers and device vendors should monitor abnormal WAP Push delivery, repeated telephony-process failure, and clusters of subscribers that repeatedly detach after data SMS receipt. Enterprise teams usually cannot inspect carrier message content, so endpoint crash telemetry, user reports, device-health data, and carrier escalation timestamps become important. Rate controls can reduce volume, but they are not a substitute for correct input handling because one message can interrupt a live call.

User guidance should be specific and calm. A sudden signal loss or dropped call is not proof that this CVE was used. Ask affected users to record the time, model, build, carrier, observed restart or recovery behavior, and whether service returns. Do not instruct them to install a third-party cleaner or proof-of-concept package. Escalate repeated boot or telephony crashes through the manufacturer, carrier, and organizational incident channel.

For a phone that still boots normally, install the confirmed fixed build and restart through the vendor-supported process. Preserve device and mobile-management logs that are available without destabilizing the phone. If cellular service repeatedly disappears, move the user to an alternate communication device before troubleshooting so recovery does not leave them unreachable.

The researcher documents an ADB method for deleting queued raw SMS rows, but that route requires developer access, a computer, and technical judgment. It may be unavailable on a managed or locked phone, and changing the message database can destroy useful evidence. Use it only through an authorized support procedure that matches the device state. A factory reset is a last-resort availability decision, not the first diagnostic step, and it should follow backup and evidence considerations.

After service returns, prove the fixed build remains installed, remove temporary debugging access, confirm voice, SMS, data, emergency-calling policy, and management enrollment, and document the recovery. The central lesson is not that SMS content is newly untrustworthy. It is that silent carrier inputs reach privileged parsing code before the user can make a safe choice, so resilient parsing and independent communication paths must carry the control burden.