SMS of Death：Androidのゼロクリック・テレフォニーDoS（CVE-2026-58882）

TL;DR

• 不正に加工されたWAP Push SMSがAndroidのテレフォニープロセスをクラッシュさせ、緊急通報を含む進行中の通話を切断します。タップも表示されるメッセージもありません。研究者のMark Bが2026年10月29日、動作する概念実証とともに公表しました。
• 欠陥はAndroid 12からAndroid 16までで再現し、Googleが修正を提供したのはAndroid 14〜17のみで、2026年10月のセキュリティ更新経由です。Android 12と13の端末、つまり2026年10月時点で世界のAndroidウェブトラフィックの18パーセントは修正を受けられません。
• 影響はサービス拒否であり、コード実行ではありません。端末はクラッシュし、再起動し、工場出荷時リセットに至るループに入る可能性があります。BleepingComputerが識別子CVE-2026-58882を報じています。2026年11月2日時点で公開CVEレコードにはまだ載っておらず、同日時点でCISAのKEVカタログにも入っていません。
• サポート対象のすべての端末を2026年10月のパッチレベル以降に更新してください。Android 12と13にはパッチが存在しません。これらのバージョンから移行できない端末は交換か退役を計画してください。

影響を受けるのは？

以下がすべて当てはまる場合に露出します。

• 端末がAndroid 12〜Android 17を実行していること。研究者はPixel 9と複数のSamsungモデルでAndroid 12からAndroid 16までのクラッシュを再現し、対象コードはこれらのリリースすべてに同梱されています。
• 端末が2026年10月のセキュリティ更新を受けていないこと。Googleの修正はAndroid 14〜17を対象とし、2026年10月のパッチレベル以降の端末は保護されます。
• 攻撃者が対象の電話番号を知っているか推測できること。それ以外は不要です。アプリのインストールも操作も事前アクセスも必要ありません。

研究者は、テストしたすべての端末でクラッシュが100パーセントの率で再現したと報告しています。Android 12と13は2026年10月時点で世界のAndroidウェブトラフィックの18.01パーセントを占め、これらの端末は同じテレフォニーコードを修正のないまま実行しています。

管理するすべての端末のAndroidバージョンとセキュリティパッチレベルを確認してください。

adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.security_patch

1つ目のコマンドはAndroidバージョン（例：14）を表示します。2つ目はパッチ日（例：2026-10-08）を表示し、2026-10-01以降の日付なら10月の更新が端末に到達しています。

修正するには？

Android 14〜17のすべての端末を2026年10月のパッチレベル以降に更新します。

1. 設定を開き、セキュリティとプライバシーから2026年10月のセキュリティ更新を確認します。インストールして端末を再起動してください。
2. 端末が実際に修正を保持しているか確認します。adb shell getprop ro.build.version.security_patchが2026-10-01以降の日付を表示する必要があります。更新の提供時期は製造元と通信事業者によって異なり、インストール完了には再起動が必要な場合があります。
3. 管理台帳を再確認します。Android 12または13の端末にはパッチの道がなく、2026年10月より前のパッチレベルのままの端末は脆弱なままです。

未修正の端末に対する回避策はありません。メッセージはユーザーに見える受信箱に届く前に処理されるため、SMS遮断アプリも権限の変更も機内モードの習慣も止められません。すでに被害を受けた端末については、「侵害されたか確認するには？」の復旧手順がADBで有害メッセージを消去します。ただし新たな攻撃は防ぎません。

根本原因は何か？

WSPヘッダー長が64ビット値として渡され、範囲検証なしに符号付き32ビット整数へキャストされます。 切り詰められた値がそのまま配列のサイズになります。欠陥はWapPushOverSmsのdecodeWapPduにあります。このコンポーネントは、受信したWAP PushショートメッセージをAndroidのintentへ変換する部分で、プラットフォームのframeworks/opt/telephonyに含まれます。

デコードはヘッダー長をuintvar、すなわち最大5バイトのWSP整数として読み、Javaのlongとして受け取ります。

// WapPushOverSms.java:217  header length read as long, cast with no bounds check
int headerLength = (int) pduDecoder.getValue32();

その後、同じ値がヘッダーバッファのサイズを決めます。

// WapPushOverSms.java:244  the cast value is used as an array size
byte[] header = new byte[headerLength];

細工されたメッセージは5バイトのuintvarとして88 80 80 80 00を宣言し、これはlongの2147483648にデコードされます。符号付き32ビットintへのキャストで-2147483648になります。new byte[-2147483648]の確保はテレフォニーのメインスレッドでNegativeArraySizeExceptionを投げ、プロセスは死にます。

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)

修正前のコードはこのデコードの周りでArrayIndexOutOfBoundsExceptionしか捕捉していませんでした。そのためNegativeArraySizeExceptionが抜け、通話・モデム接続・SMSを握るcom.android.phoneを殺していました。

どのように悪用されるか？

概念実証は公開されており、ソースとインストール可能なアプリも添えられています。攻撃の全体は短いメッセージ1通です。

1. 攻撃者はテキストメッセージではなくdata SMSを、対象のポート2948（WAP Pushポート）へ送ります。ペイロードは8バイトで、01 06 88 80 80 80 00 BE。トランザクションID、push PDUタイプ、毒入りのヘッダー長、コンテンツタイプです。
2. Androidはメッセージを、ユーザー向けの受信箱より前にテレフォニースタックへ配信します。InboundSmsHandler.processMessagePartはそれをWapPushOverSms.decodeWapPduへ渡し、uintvarヘッダー長を2147483648として解釈し、-2147483648へキャストします。
3. new byte[-2147483648]の確保がテレフォニーのメインスレッドで例外を投げます。com.android.phoneがクラッシュし、進行中の通話は切断原因CS_DEATHで終わります。
4. Androidはテレフォニープロセスを再起動し、1〜2秒間サービスなしになります。SMSは一度も応答確認されないため、通信事業者が再送し、クラッシュが繰り返されます。研究者は1通で最大1週間に及ぶ断続的な障害を測定しました。
5. 有害メッセージは生のSMSデータベースに残るため、起動のたびに再試行されます。約20通でテスト端末は長時間使用不能になり、あるAndroid 12端末は約90秒ごとにリカバリーへ再起動するサイクルに入り、工場出荷時リセットで終わりました。

GitHubの概念実証アプリは、この細工されたメッセージを別のAndroid端末から送信します。研究者は動作する武器であるという警告付きで公開し、ライセンスを許可されたテストに限っています。

攻撃はどのように流れるか？

ポート2948への8バイトのdata SMS 1通が、未検証のキャストを通じてテレフォニーをクラッシュさせ、キューに残ったメッセージがクラッシュを繰り返させます。

攻撃者に何ができるか？

実証された影響は、電話のセルラーサービスへの持続的な拒否であり、開示資料のどこにもコード実行は主張されていません。

• プロセスが死ぬとき進行中の通話はすべて切断されます。緊急サービスへの通話を含みます。攻撃やその後のループが続く間、端末は確実に通話を発信できません。
• 1回のクラッシュは1〜2秒の通話不能をもたらします。事業者の再送が1通を繰り返しのクラッシュに変え、1通だけで1週間にわたりテスト端末を断続的に障害させました。
• 約20通で端末は使用不能になり、あるAndroid 12ではキューに残ったメッセージが90秒ごとのリカバリー再起動ループを引き起こしました。研究者による復旧は、ADBによる削除手順か完全な工場出荷時リセットを必要としました。
• 被害者には何も見えません。data SMSはメッセージアプリに現れず、送信者の番号も表示されません。このため攻撃の事後的な帰属も困難です。

条件は最小限です。攻撃者に必要なのは電話番号だけです。アプリも権限も操作もネットワーク上の位置も不要です。

なぜ修正は機能するか？

Googleの修正はcommit 735d9672603fa206c4b43cb668c1aa273db70b97「Fix remote DoS in decodeWapPdu」で、2026年6月15日に書かれ、2026年10月のセキュリティ更新で配布されました。研究者が提案した範囲検証を追加するものではなく、クラッシュを致命的にしないこととメッセージを残さないことです。

// WapPushOverSms.java: widen the catch to cover NegativeArraySizeException
-        } catch (ArrayIndexOutOfBoundsException aie) {
+        } catch (RuntimeException e) {

// InboundSmsHandler.java: a failed decode now deletes the poison message
-                    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);
+                        }
+                    }

NegativeArraySizeExceptionはRuntimeExceptionなので、広げたcatchが確保失敗を飲み込み、メッセージを汎用エラーとして扱います。InboundSmsHandlerの対になる変更は、配信が例外を投げたときにメッセージを生のデータベースから削除し、事業者の再送ループと起動時の再試行ループの両方を断ちます。このcommitはGoogleのEXEMPT CVE_FIXフラグを持ち、ヘッダー長4294967295に対するテストを追加しています。

この修正は問題を狭めますが、原因そのものは除去しません。未検証のキャストはコードに残り、不正なヘッダーは解析時の検証ではなく下流で拒否されるようになりました。それでもAndroid 14〜17のクラッシュは止まり、Android 12と13では同じキャストが修正されないまま残ります。

侵害されたか確認するには？

完了しなかった攻撃は痕跡を残さないことがあり、成功した攻撃はクラッシュを繰り返す電話を残します。欠陥そのものの兆候は明確です。

adb logcat -d | grep -i "NegativeArraySizeException"

com.android.phone配下でのNegativeArraySizeException: -2147483648の記録が、このデコード失敗の署名です。有害メッセージは生のSMSデータベースにあり、通常のSMSアプリには表示されません。WAP Pushの行とその送信者を一覧表示します。

adb shell content query --uri content://sms/raw --projection _id:address:destination_port:date:deleted

destination_port=134020を持つ行は、生のデータベースにおけるWAP Pushポート2948の符号化です。説明のつかない送信者からの行が、削除すべきメッセージです。以下の復旧は@sakisdogにより提供され、概念実証リポジトリで文書化されています。端末の起動後の短い時間枠で実行する必要があります。

adb shell cmd appops set com.android.shell WRITE_SMS allow
adb shell "content delete --uri content://sms/raw --where \"address='<SENDER>'\""
adb shell cmd appops set com.android.shell WRITE_SMS default

<SENDER>を上のクエリで得たアドレスに置き換えてください。ループを断てない場合、最終手段としてすべてのSMSとMMSを消去しAPN設定を初期化します。adb shell pm clear com.android.providers.telephonyです。工場出荷時リセットを意図しない限り、リカバリー画面で「wipe data」を選ばないでください。

年表

• 2026-05-05：Mark BがGoogleのAndroidおよびデバイスの脆弱性報奨プログラムに欠陥を報告。
• 2026-06-15：Androidエンジニアがテレフォニーフレームワークに修正commit 735d9672603fa206c4b43cb668c1aa273db70b97を記述。
• 2026-10-01：Googleが2026年10月のセキュリティ速報を公表。パッチレベルは2026-10-01と2026-10-08です。修正はこの更新でAndroid 14〜17に届きます。欠陥自体は速報には記載されません。
• 2026-10-29：Mark Bが技術解説、概念実証アプリとソースを公表し、@sakisdogがADB復旧を文書化。
• 2026-11-02：公開CVEレコードには報告された識別子CVE-2026-58882がまだ載っておらず、欠陥はCISAのKEVカタログにも入っていません。

FAQ

これはリモートコード実行ですか？

いいえ。実証された影響はプロセスのクラッシュと、それに続くテレフォニーサービスの拒否です。開示資料のどのソースもコード実行を主張しておらず、Google自身の修正commitもこの欠陥をリモートのサービス拒否と題しています。

メッセージはメッセージアプリに表示されますか？

いいえ。この攻撃はポート2948へのdata SMSであり、Androidはどの受信箱にも届く前にテレフォニースタックで処理します。被害者は内容も送信者の番号も決して見られません。このため攻撃の事後的な帰属も困難です。

なぜAndroid 12と13は修正されないのですか？

フレームワーク向けのセキュリティ更新はサポート中のバージョンへ配布され、この欠陥ではAndroid 14〜17を指します。Android 12と13の端末は同じテレフォニーコードを実行していますが、その更新対象から外れています。製造元が変更をバックポートしない限り、これらの端末は耐用寿命の残りずっと脆弱なままです。

CVE番号が正しいとどう分かりますか？

報告された値として扱い、確定ではないことに注意してください。BleepingComputerがCVE-2026-58882という名前を挙げ、Googleの修正commitはEXEMPT CVE_FIXフラグを持ち、CVEが割り当てられたことを裏付けています。2026年11月2日時点で公開CVEデータベースとNVDにはレコードがまだなく、公開時には番号が変わる可能性があります。

通信事業者はこれらのメッセージを遮断できますか？

公表された資料には事業者側のフィルタの記述はありません。不正な値は通常のdata SMSのWAP Pushヘッダー内にあるため、遮断するにはそのポートかその符号化を対象にする必要があります。そうしたフィルタリングは情報源のどこにも説明がありません。端末側の唯一の保護は2026年10月のパッチレベルです。

企業の端末台帳は今週何をすべきですか？

Android 14〜17のすべての端末を2026年10月のパッチレベルへ更新し、Android 12または13と報告されているバージョンを棚卸しし、交換か退役を計画してください。それらの端末は修正を受けられず、攻撃に必要なのは電話番号だけです。

参考文献

• 「SMS of Death」の技術解説。根本原因、影響、概念実証を含む：https://smsofdeath.com/（2026年10月29日公開、2026年11月2日確認）
• 概念実証アプリとソース、およびADB復旧の議論：https://github.com/MarkBlah/smsofdeath（2026年10月29日公開、2026年11月2日確認）
• Androidの修正commit 735d9672603fa206c4b43cb668c1aa273db70b97「RESTRICT AUTOMERGE: Fix remote DoS in decodeWapPdu」：https://android.googlesource.com/platform/frameworks/opt/telephony/+/735d9672603fa206c4b43cb668c1aa273db70b97（2026年6月15日記述、2026年11月2日確認）
• 修正commit時点のWapPushOverSms.javaのソース、217行と244行：https://android.googlesource.com/platform/frameworks/opt/telephony/+/735d9672603fa206c4b43cb668c1aa273db70b97/src/java/com/android/internal/telephony/WapPushOverSms.java（2026年11月2日確認）
• Androidセキュリティ速報、2026年10月：https://source.android.com/docs/security/bulletin/2026/2026-10-01（2026年10月公開、2026年11月2日確認）
• BleepingComputer「New Android SMS of Death exploit can remotely crash unpatched phones」。識別子CVE-2026-58882の出典：https://www.bleepingcomputer.com/news/security/new-android-sms-of-death-exploit-can-remotely-crash-unpatched-phones/（2026年10月31日公開、2026年11月2日確認）
• Statcounter Global Stats、Androidバージョン別世界シェア、2026年10月：https://gs.statcounter.com/android-version-market-share/worldwide（2026年11月2日確認）
• CISAのKEVカタログ。CVE-2026-58882について確認したフィード：https://www.cisa.gov/known-exploited-vulnerabilities-catalog（2026年11月2日確認）