Android「SMS of Death」脆弱性（CVE-2026-58882）——SMS受信だけで電話機能が停止、報道で分かっていること

公開日：2026年11月3日文：クリスタルメソッド編集部監修：河合継（代表取締役）

Android脆弱性CVE-2026-58882——SMS処理にDoSの恐れ、修正版へ更新を

研究者のMark Blaszczyk氏が10月末に詳細を公開したAndroidの脆弱性「SMS of Death」（CVE-2026-58882）について、2026年11月3日時点で確認できた内容を整理する。Googleの公式セキュリティ公報（Android Security Bulletin）での掲載はこの時点で確認できておらず、報道どうしで食い違う点もある。確認できた事実と、食い違っている点を分けて書く。

SMS of Death（CVE-2026-58882）とは——特別なSMSで電話機能が止まる

報道によると、細工したWAP Push形式のSMSを受信すると、Androidの電話サービス（com.android.phone）が停止する。受信者がメッセージを開く、リンクを押すといった操作は不要で、メッセージは受信トレイに表示されないと伝えられている（eSecurityPlanet）。

原因はSMSの受信を処理するWapPushOverSmsのdecodeWapPdu()にある。ヘッダー長を64ビットの値として読み込んだあと、範囲を確認せずに符号付き32ビット整数へ変換するため、特定の値（0x80000000）が負の数になり、配列の大きさの例外（NegativeArraySizeException）で電話サービスが終了する（Born City）。

報道が伝える影響——通話の切断と再起動ループ

不正なメッセージは1通（全長8バイト）で電話サービスをクラッシュさせる（Born City）。
約20件で再起動ループに陥る場合がある。約30件を短時間に受信した検証では、SMS用のデータベースが壊れ、起動のたびにクラッシュしたとされる（Born City）。
Google PixelとSamsung Galaxyでの検証では、再現率は100%と伝えられている（eSecurityPlanet）。
電話サービスは1〜2秒止まり、通話中なら切断される。研究者は、攻撃を繰り返せば緊急通話ができなくなり得ると指摘している（Born City）。
未確認のメッセージは保留キューに残り、再起動後に再び処理されて再度クラッシュすることがある。通信事業者が未確認のメッセージを再送する場合もある（eSecurityPlanet）。
研究者は概念実証（PoC）コードを公開している。実際の攻撃での悪用が確認されたという記載は、確認できた範囲の報道にはない。

次に読む：Google メッセージの強化保護モードとは？

Google メッセージにGeminiの詐欺検出「強化保護モード」――Androidの新しい詐欺対策

影響を受けるバージョンと修正——報道とCVE記録で食い違い

ここは情報源によって違う。

情報源	影響を受けるバージョン	修正についての記述
eSecurityPlanet	Android 12〜16	2026年10月のセキュリティアップデートにAndroid 14〜17向けの修正が含まれる。修正のコミットは6月15日。11月の公報に載る見込み（GrapheneOSの情報）
Born City	Android 12・13は公式パッチなし。14〜17は10月の更新で修正予定	Googleは10月29日に「セキュリティ上のバグではない」として分類し、正式な修正なしでクローズしたと報じている。コミットの日付は8月5日としている
CVE公式記録	Android 14・15・16・16-qpr2・17	修正・回避策の記載なし。公開日は2026年11月2日。CVSSの記載もない

出典：上表の各リンク。NVDも参照した。

Googleは当初CVE番号を割り当てなかったと報じられており、業界の一部が重大度「Critical」として扱っているという。一方、公式のCVE記録にはCVSSの記載がなく、CISAのKnown Exploited Vulnerabilities（KEV）にも掲載されていない。「Googleが重大度Criticalで修正した」という公式の発表は、確認できていない。

今、できること——更新の確認

最新のAndroidセキュリティアップデートを適用する。報道は、これが最も現実的な対策だとしている。メーカーや通信事業者によって配布の時期は異なる（eSecurityPlanet）。
更新が提供されない古い機種は、脆弱性が残る可能性がある。Android 12・13は公式パッチがないと報じられている。
研究者は、問題のメッセージをADBで削除して、初期化せずに復旧する方法も示している。事前に端末側の設定が必要で、詳細は元の報道と研究者の公開情報を参照してほしい。

公式の回避策は、確認できた範囲では示されていない。自社の機器が対象かどうかの判断や、すでに侵入されていないかの確認は、構成やログを見ないと判断できません。