- Researcher Mark Blah published a working exploit for CVE-2026-58882, which crashes Android's phone process with one silent text message and can drop emergency calls.
- Google's October 2026 fix covers Android 14 through 17. Blah says Android 12 and 13 run the same code and receive no fix.
- Check which Android versions and patch levels your staff phones run, especially for people who carry on-call or safety duties.
Most attacks need a victim to click something. This one needs only a phone number. A researcher has shown that one malformed text message can crash an Android phone's calling software, and the owner sees nothing arrive.
What was published
Researcher Mark Blah released a working proof-of-concept for a flaw he calls "SMS of Death". BleepingComputer reports it is tracked as CVE-2026-58882. The exploit app crafts the malformed message and sends it to a target number.
According to Blah, the payload travels as a data SMS. It leaves nothing in the inbox, and the sender's number stays hidden from the victim. Active calls end, including emergency calls. Each message cuts service for one to two seconds while the phone process restarts.
How a five-byte header crashes the phone process
The message uses WAP Push, an older format for carrying data over text. When Android receives one, a routine called decodeWapPdu reads a length value from the header. Blah says the code stores that length as a long number, converts it to a smaller 32-bit integer with no range check, and uses it as the size of a new block of memory.
Five bytes, 88 80 80 80 00, decode to 0x80000000. As a signed 32-bit integer, that is -2,147,483,648. Asking for a block of negative size is like asking a warehouse to build a shelf of negative length. The system has no instruction for it, throws a NegativeArraySizeException error, and nothing catches it. The com.android.phone process, which runs cellular functions, shuts down.
One crash is a nuisance. Repetition makes it worse. Blah says carriers resend messages the phone did not acknowledge, and bad messages stay in a queue that Android retries on every boot. His tests found that one message could trigger on-and-off service loss lasting as long as seven days. About 20 messages left a device unusable for an extended period.
On one Android 12 phone, the device rebooted into recovery roughly every 90 seconds. Blah says normal users were pushed toward a factory reset. A GitHub contributor, Sakis, found a way to delete the queued messages over Android Debug Bridge (ADB). That needs a computer and technical skill, so it is out of reach for most people.
Blah reports a 100% reproduction rate across a Pixel 9 on April 2026 firmware and various Samsung Galaxy and A-series phones. He reproduced the crash from Android 12 up to Android 16. These are the researcher's own test results.
Where the patch stops
Blah reports that Google addressed the flaw in its October 2026 Android security update, which covers Android 14 through 17. He says the commit, titled "Fix remote DoS in decodeWapPdu", was authored on 15 June 2026. Phones on the October patch level or later are protected, he says.
Blah also says the fix does not add the range check he gave Google on the day of his first report. Instead, it widens the exception handling so the crash is swallowed. It also deletes the triggering message. BleepingComputer points out that Google's October bulletin does not list the flaw.
The sources include no comment from Google. Android 12 and 13 are outside the security-update window, according to Blah. They run the same code and Google's patch does not cover them. Per Blah and BleepingComputer, those phones did not receive the fix, and the exploit is now public.
The emergency-call argument
Blah's report makes a point aimed at Australia. He points to the Telecommunications (Emergency Call Service) Determination, overseen by the ACMA. In his account, it obliges carriers to find handsets that cannot reach Triple Zero (000).
He also cites Telstra's own statement. Telstra says it will notify the customer and then block the device if the problem is not fixed within 28 days.
His conclusion is that an attacker could get a victim's handset cut off by its carrier until the software is updated. That is his reading. The sources do not show any carrier confirming it would apply to this flaw.
The wider lesson holds without that rule. A phone's protection depends on a calendar the owner does not control. The vendor decides when support ends. After that date, a flaw like this one stays open on every phone that has not been replaced.
What leaders should ask
First, ask how many company or staff phones run Android 12 or 13. Ask for a count, not a guess. Device management tools usually report the Android version and patch level.
Second, ask who relies on a phone for on-call alerts, safety checks or emergency contact. Move those people off unsupported devices first.
Third, ask what the plan is for a phone stuck in a reboot loop. If recovery means a factory reset or an ADB session, staff need to know whom to call and what to avoid. Blah warns against choosing "wipe data" at the recovery prompt.
Fourth, ask whether staff phones on supported versions have taken the October update. BleepingComputer notes that availability depends on the maker and carrier, and a restart may be needed.
A phone number is public by design. A device whose support has ended receives no new fixes, and this flaw shows what that costs.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Mark Blah.
