Android 'SMS of Death' exploit is public: fix is in October's code, not Google's bulletin; CVE only reserved

Written on day 41, in October's code, and not in October's bulletin

A researcher who published a working proof of concept for an Android text message crash on 29 October 2026 says the flaw was reported on 5 May. Google's public fix commit, "Fix remote DoS in decodeWapPdu", was authored on 15 June 2026, which is 41 days after that report (derived). The changed code is present in the Android Open Source Project (AOSP) security release tags for Android 14, 15, 16 and 17 that were tagged on 5 and 6 October 2026, and absent from the tags of 8 September. Yet Google's October 2026 Android Security Bulletin, published 5 October and updated 8 October, lists 25 CVEs (derived count) and none of them names this commit, its bug number or the telephony decoder it changes. This was read on Saturday 31 October 2026 from 19:53 GMT. The attack is nicknamed "SMS of Death" and BleepingComputer calls it CVE-2026-58882.

That settles one argument and leaves several open. It does not establish that a given phone is protected, because the bulletin's promise, that a patch level of 2026-10-01 or later addresses the issues listed, does not cover an issue it does not list. It does not establish that anyone has used the flaw outside the researcher's testing: no source read for this briefing reports that. It does not establish what Google thinks of the report, because no Google statement was found. And the CVE number in the headlines is, on CVE.org, only a reserved identifier with no published record.

The proof of concept is public and the researcher's page says it works. This briefing therefore prints no message content, no code from the proof of concept and no recovery commands, and does not link to the downloads. It describes the fault at the level Google's own commit does and gives defenders a ranked list of actions. The researcher is described by role only.

Zoom

What the researcher's page states, and what it leaves out

The researcher's page at smsofdeath.com is the only primary source for the attack itself. Everything below in the left column is the researcher's own statement, copied in meaning from the page as read on 31 October. The page is an argument as well as a technical write up: it argues for a higher classification of the report under Google's vulnerability reward rules and makes a regulatory argument about emergency calls in Australia. Those arguments are the researcher's, and the regulatory pages it cites were not read for this briefing.

A "100 per cent reproduction rate" means every attempt the researcher made worked, on the devices the researcher chose, in the researcher's own testing. The page does not give the number of devices or attempts. It is a statement about a sample, not about the installed base of Android.

Four claims that disagree, and what the primary sources support

The researcher says the fix shipped in the October 2026 update. BleepingComputer, reporting the researcher's account, says the flaw is not listed in Google's October bulletin. The CVE identifier appears in BleepingComputer's article but not in the researcher's page text. These look like contradictions. They are not all about the same thing, and each can be tested against a Google source.

So "fixed in October" and "not in the October bulletin" can both be true, and the sources read here say they are. The first is about code. The second is about what Google chose to list. The difference matters because a bulletin is the document that device makers and enterprise tools use to decide what a patch level contains. A fix that is in the source but not in the bulletin has no CVE row to track, and nothing in the bulletin tells a vendor to include it.

One detail in the commit points the other way. Its message carries the line "Flag: EXEMPT CVE_FIX", which appears to mark the change as a security fix (inference). It does not say why no bulletin row exists. That is a question for Google, and no statement from Google was found.

A separate October entry should not be confused with this flaw. The bulletin's only Critical remote denial of service in the Framework section, CVE-2026-58865, is described in its CVE record as "a possible persistent denial of service due to a missing bounds check" in PduParser.java. Its public change, authored 17 June 2026 under bug 513582756, edits the MMS parser in frameworks/base. It is a different file, a different bug and a different component from the WAP push decoder, so on the evidence of the commits it is not this flaw.

What Google changed, and what it left alone

Google's commit, 735d967 in the frameworks/opt/telephony repository, was authored on 15 June 2026 (Pacific time) and carries a committer date of 5 August 2026. Its message says it catches RuntimeException during WAP push decoding and SMS broadcast "to prevent persistent crash loops", and that on failure it logs a warning and deletes the poison tracker from the raw database. The tracker is the record of the pending message. The diff changes two catch blocks and the handling of a null tracker, and adds unit tests. It does not change the line that narrows the length value or the line that allocates the array: both are still in the 17.0.0_r2 source tag read for this briefing.

The researcher's page says it proposed a different fix, a range check before the narrowing, on the day of the first report, and argues that Google's choice hides the exception instead of removing the cause. From the diff, after Google's change a malformed message still triggers the exception, but the exception is caught, the message is deleted and the loop is broken (inference from the diff, consistent with the commit message). That removes the repeat crashes. It does not obviously remove the first one: the researcher does not say whether the process still restarts once per message after the fix, and no retest on a fixed build was found.

Zoom

AOSP tags show what Google's source contains. They do not show what a phone maker ships. Handset makers build from Google's partner releases, add their own changes and decide when to release. BleepingComputer adds that availability depends on the manufacturer and carrier and that a restart may be needed to finish an update. Whether Samsung and other makers carry this commit at the same date is not stated by any source read.

Which versions are affected: tested, listed, inferred

The "Android 12 to 17" label on the researcher's page is therefore a mix of tested versions (12 to 16) and an inferred one (17). That is a reasonable inference from shared code, but it is an inference. The researcher's statement that Android 12 and 13 are outside the security update window is not something the October bulletin contradicts: every row in it lists Android 14 or later. No source read gives a count of devices still on 12 or 13, so none is given here.

Emergency calls: argued from a dropped call, not tested

The headline risk is to calls to emergency services. The researcher's page says active voice calls end as the phone process restarts and argues that a phone under attack or stuck in the loop "cannot reliably place" an emergency call. BleepingComputer repeats that calls, including emergency calls, can be interrupted. Neither describes a test of an emergency call. The reasoning is plausible: the process that handles cellular calls is the one that crashes. But it is an argument from mechanism, and the page's own figure for each crash is a restart of 1 to 2 seconds.

By the page's own numbers, 20 messages, each costing 1 to 2 seconds, would cost 20 to 40 seconds of service if they arrived one after another (derived). The page's claim that 20 messages make a device unusable for an extended period rests on retries and the boot loop, not on that arithmetic. Both figures are the researcher's, and neither has been repeated by an independent source. The page also argues that, in Australia, the regulatory remedy for a handset that cannot reach emergency services is to block it from the network. That is the researcher's reading of rules this briefing did not check.

The friendly name check: five labels that do the work of a control

The patch level line deserves the most care. Google's bulletin says devices with a security patch level of 2026-10-01 or later address the issues in that bulletin. A fix that is not in the bulletin is outside that promise. The researcher says devices on the October patch level or later are protected, which may well be true for devices built from the October source, but a defender cannot confirm it from the patch level string alone.

Who gains from which account

The researcher published a working proof of concept and a write up that argues the report deserved a higher classification, as a "Destructive Remote DoS" under the programme's published rules. The page does not say how Google classified the report or whether a reward was paid, so the dispute, if there was one, is not on the record here. A researcher gains attention and credibility from a named, public attack, and has an interest in the severity argument. Google has an interest in how its fix is described, and gave no statement that could be found. BleepingComputer's account follows the researcher's page and adds the bulletin check.

Nothing read reports use of the flaw in the wild. That absence is not evidence that it has not been used: a crash with no inbox trace is hard to notice. It is a statement about what was found on 31 October.

What defenders do, in order

The steps use Google's bulletin and the researcher's page. Where a step is this site's inference, it says so.

What is not established

Technical details

Each block below is copied from the source named in its caption on 31 October 2026, except where marked as omitted. This briefing deliberately leaves out the message bytes, the header length value that triggers the fault, the destination port, the proof of concept's code and build steps, and the researcher's ADB commands. None of that is needed to detect the crash, to check a build or to judge the fix. The test cases in Google's commit also contain such values and are not printed.

First, Google's commit message and metadata. This is the identifier a defender can give a vendor: bug 517376969 and the title. Note the flag line and the 15 June authoring date against the 5 August committer date.

commit  735d9672603fa206c4b43cb668c1aa273db70b97
author  [a Google engineer, name and address omitted by this site]   Mon Jun 15 20:25:38 2026 -0700
committer  Android Build Coastguard Worker   Wed Aug 05 16:14:43 2026 -0700
parent  552115b4731c5aded7d70c8368c010cc99997ef8
4 files changed: InboundSmsHandler.java, WapPushOverSms.java, WapPushOverSmsTest.java, GsmInboundSmsHandlerTest.java

RESTRICT AUTOMERGE: Fix remote DoS in decodeWapPdu (b/517376969)
Catch RuntimeException during WAP push PDU decoding and SMS broadcast
to prevent persistent crash loops. If decoding fails, log a warning and
delete the poison tracker from the raw database.
Also add warning logs if inboundSmsTracker is null during broadcast.
Added corresponding unit tests in WapPushOverSmsTest and GsmInboundSmsHandlerTest.
Bug: 517376969
Test: atest FrameworksTelephonyTests:WapPushOverSmsTest FrameworksTelephonyTests:GsmInboundSmsHandlerTest
Flag: EXEMPT CVE_FIX
(cherry picked from commit 618039539b4bd57c6761def72a567def95e3dfad)

Second, the two source changes in the commit, with the test files left out. The first widens the exception that decodeWapPdu catches. The second wraps message delivery so a failing message is deleted from the raw table. The line that narrows the length is not in the diff. Indentation is as the diff page shows it.

@@ -314,10 +314,10 @@
             result.intentData = intentData;
             result.contentTypeParameters = pduDecoder.getContentParameters();
             result.statusCode = Activity.RESULT_OK;
-        } catch (ArrayIndexOutOfBoundsException aie) {
+        } catch (RuntimeException e) {
             // 0-byte WAP PDU or other unexpected WAP PDU contents can easily throw this;
             // log exception string without stack trace and return false.
-            Rlog.e(TAG, "ignoring dispatchWapPdu() array index exception: " + aie);
+            Rlog.e(TAG, "ignoring decodeWapPdu() runtime exception: " + e);
             result.statusCode = Intents.RESULT_SMS_GENERIC_ERROR;
         }
         return result;

@@ -624,7 +624,19 @@
                 case EVENT_BROADCAST_SMS:
                     // if any broadcasts were sent, transition to waiting state
                     InboundSmsTracker inboundSmsTracker = (InboundSmsTracker) msg.obj;
-                    if (processMessagePart(inboundSmsTracker)) {
+                    boolean success = false;
+                    if (inboundSmsTracker != null) {
+                        try {
+                            success = processMessagePart(inboundSmsTracker);
+                        } catch (RuntimeException e) {
+                            loge("Exception delivering message part", e);
+                            deleteFromRawTable(inboundSmsTracker.getDeleteWhere(),
+                                    inboundSmsTracker.getDeleteWhereArgs(), MARK_DELETED);
+                        }
+                    } else {
+                        loge("EVENT_BROADCAST_SMS with null inboundSmsTracker");
+                    }
+                    if (success) {
                         sendMessage(obtainMessage(EVENT_UPDATE_TRACKER, msg.obj));
                         transitionTo(mWaitingState);
                     } else {

Third, the crash signature the researcher prints. It is what a developer or an enterprise log pipeline would look for in a device log from a phone on a vulnerable build: a fatal exception in com.android.phone, thrown inside the WAP push decoder. The researcher's exception message carries a number that would identify the trigger; it is replaced here. Line numbers are those the researcher's page printed for its test build and differ between Android versions (this site observed other line numbers in the 17.0.0_r2 file).

E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: com.android.phone
E AndroidRuntime: java.lang.NegativeArraySizeException: <value omitted by this site>
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)

Fourth, what Google's bulletin says a device should report once it has the October fixes, and the CVE Program's answers about the identifier. The patch string is how to check a build. The bulletin does not promise that this fix is behind it, as explained above.

[ro.build.version.security_patch]:[2026-10-01]

Pixel (Google devices): security patch level 2026-10-05 or later

published record (api/cve), HTTP 404:
{"error":"CVE_RECORD_DNE","message":"The cve record for the cve id does not exist."}

identifier (api/cve-id), HTTP 200:
{"cve_id":"CVE-2026-58882","cve_year":"2026","state":"RESERVED","owning_cna":"[REDACTED]"}

What the primaries do not print: no indicators of compromise, no carrier side detection rule, no mitigation setting on the phone, and no statement from Google. The researcher's recovery route is described in the checklist in words, because its commands are a step by step and are not repeated here.

The question that exposes the gap

Google's source has carried the fix since early October, and the bulletin that tells the industry what a patch level contains does not mention it. A researcher has made the attack public, a number in the headlines points at nothing yet, and for Android 12 and 13 there is no fix to wait for. If a phone you rely on crashed its calls tomorrow and reached recovery every 90 seconds, would you know whether its build contains the fix, who would tell you, and what you would do with the person holding it?

Key facts