← 返回事件分析列表
分析日期：2026-11-01分類：漏洞揭露原始來源：Mark Blaszczyk（SMS of Death 研究專站）標籤：AndroidCVE-2026-58882WAP Push零點擊緊急通話PoC 公開

1. 事件概述

2026-10-29，獨立研究員 Mark Blaszczyk 公開「SMS of Death」研究：Android 處理 WAP Push 簡訊的元件存在一個未做邊界檢查的型別轉換缺陷，攻擊者只要知道受害者的電話號碼，傳送一則特製的資料簡訊（data SMS），就能在對方完全無感、無需任何操作（零點擊）的情況下，讓其手機的通話功能崩潰。訊息不會出現在收件匣，寄件號碼也不會顯示。研究員同時在 GitHub 公開了可實際運作的概念驗證（PoC）App 與完整原始碼，並直言這是「a working weapon」（可實際運作的武器），僅供授權測試與研究。

此漏洞已編列 CVE-2026-58882（依 BleepingComputer 報導）。修補已包含在 Google 2026 年 10 月安全性更新中，涵蓋 Android 14 至 17；但它沒有列入 Google 的 10 月安全性公告（依研究員與 BleepingComputer 的說法），GrapheneOS 表示預計列入 11 月安全性公告。Android 12 與 13 裝置因已不在安全性更新支援範圍，執行的是同一份有缺陷的程式碼，卻不會收到修補。截至公開時，沒有證據顯示此漏洞已被在野實際利用（依研究員與媒體報導）。

2. 時間線

日期事件
2026-05-05研究員透過 Android & Devices VRP 向 Google 回報此漏洞，並在回報當天提供他建議的修法（在轉換前做範圍檢查）
2026-06-15一名 Android 工程師提交修復 commit 735d967，標題「Fix remote DoS in decodeWapPdu」；Google 實際採用的修法與研究員建議不同（見第 3 節）
2026 年 10 月修復隨 Android 2026 年 10 月安全性更新釋出，涵蓋 Android 14 至 17；但漏洞未列入 10 月安全性公告
2026-10-29研究員公開完整技術分析與 PoC（專站與 GitHub）；依研究員公布的時間線，Google 在這段期間仍維持「非資安問題」的分類（見第 4 節的說法區分）
2026-10-31BleepingComputer 等媒體報導，CVE 編號為 CVE-2026-58882；GrapheneOS 表示預計列入 11 月安全性公告

3. 技術分析

3.1 根源：一個未檢查的型別轉換

當 Android 收到 WAP Push 訊息，元件 WapPushOverSms 的 decodeWapPdu() 會讀取 WSP 標頭長度。這個值以 uintvar 解出、型別是 long，程式碼在沒有任何範圍檢查的情況下直接轉型為 int，並拿這個值當作新位元組陣列的大小（研究員標示為 WapPushOverSms.java 第 217 行讀取、第 244 行使用）。

攻擊訊息的酬載只有 8 個位元組：01 06 88 80 80 80 00 BE，以資料簡訊送往連接埠 2948。其中 5 位元組的 uintvar 88 80 80 80 00 解出 0x80000000；轉成有號 32 位元整數後變成 -2147483648。程式接著嘗試配置 new byte[-2147483648]，在通話主執行緒上丟出未被捕捉的 NegativeArraySizeException，負責行動通訊的 com.android.phone 程序因此崩潰。

3.2 影響的放大機制

單一訊息只會造成約 1 至 2 秒的通話中斷（程序重啟期間無服務），但有三個放大因素：

  1. 通話直接被切斷：崩潰當下進行中的語音通話會以 CS_DEATH 原因中斷，包括緊急電話（研究員以澳洲 000 為例；在臺灣即 110、119 這類緊急通話）。
  2. 電信商重送：未被確認收妥的訊息會由電信商重送，等於反覆重新觸發崩潰；研究員測試中，單一訊息曾造成長達一週的間歇性斷訊。
  3. 開機重試與重開機迴圈：惡意訊息會留在待處理佇列、每次開機都重試；約 20 則訊息即可讓裝置長時間無法使用。研究員在一台 Android 12 裝置上觀察到，系統的 RescueParty 機制約每 90 秒把裝置重開進復原模式，一般使用者最後往往只能恢復原廠設定才能脫困。

研究員稱已在多款裝置上重現，包括 Pixel 9（2026 年 4 月韌體）與多款 Samsung Galaxy（含 A 系列），重現率 100%；受影響的程式碼自 Android 12 起即存在，崩潰已重現至 Android 16。

3.3 兩種修法

研究員建議的修法是在轉型前做範圍檢查（小於 0 或大於 PDU 長度即拒絕）。Google 實際出貨的修法不同：把 decodeWapPdu 捕捉的例外範圍放寬到 RuntimeException，讓崩潰被吞下；同時在 InboundSmsHandler 中，解碼失敗時直接把該則毒訊息自原始簡訊表刪除，避免它在重送或開機時反覆觸發。裝上 2026 年 10 月（或之後）安全性更新的裝置即受保護；更早的更新等級仍曝險。

3.4 自救：陷入迴圈時的 ADB 復原法

GitHub 貢獻者 Sakis（@sakisdog）在儲存庫 issue #2 紀錄了較不具破壞性的復原法：毒訊息留在 content://sms/raw 待處理佇列裡，在開機完成後的短暫窗口用 ADB 查詢並只刪除那些 WAP Push 列（destination_port=134020），再還原權限設定，即可打破迴圈、不必恢復原廠設定；最後手段才是清除 telephony provider 資料（會一併清掉所有簡訊與 APN 設定）。此法需要電腦與 ADB 操作能力，對一般使用者門檻仍高，且研究員提醒：在復原模式畫面不要選「wipe data」。

4. 歸因與證據限制

本案沒有攻擊者歸因問題（這是漏洞揭露，不是入侵事件），但有幾項說法必須分清來源與狀態：

  1. 「Google 判定為非資安問題」是研究員單方面的揭露時間線。研究員稱他 2026-05-05 回報後，Google 初步分類為非資安議題，他多次申覆，Google 至 2026-10-29 仍維持該分類；但修復 commit 在 2026-06-15 就已存在並隨 10 月更新出貨——「不承認是資安問題、但修了」是研究員敘事的核心張力。Google 官方未見對此分類爭議的公開回應，本篇不替任何一方下定論。
  2. CVE 與公告狀態以媒體查核為準：CVE-2026-58882 的編號來自 BleepingComputer 報導；「未列入 10 月安全性公告、預計列入 11 月公告」分別來自研究員／BleepingComputer 與 GrapheneOS 的說法，仍待 Google 11 月公告落地確認。
  3. 沒有在野利用證據：截至 2026-10-31，沒有任何一方通報此漏洞已被實際用於攻擊；風險評估應建立在「PoC 已公開、門檻低（只需電話號碼）」而非「已發生攻擊」。
  4. 影響範圍的數字來自研究員測試：100% 重現率、單一訊息造成一週間歇斷訊、約 20 則造成迴圈等，皆為研究員在其裝置與電信環境下的測試結果，不等於所有機型與所有電信商都會有相同表現。
  5. 緊急通話的法規論述是研究員的主張：研究員以澳洲 ACMA 的緊急通話規範論證此漏洞的公共安全嚴重性（在澳洲，無法撥打 000 的手機依法可能被電信商停話），這是他的論證角度，不是監管機關對本漏洞的正式認定。

本工作坊的判讀：這個漏洞的技術成因並不複雜——一個漏掉的邊界檢查；真正值得記錄的是兩件事。第一，傳統通訊協定（WAP Push 是功能手機時代的遺產）在現代手機裡仍以高權限默默運行，零點擊、無痕、只需號碼就能觸及通話核心。第二，揭露過程顯示「有沒有 CVE、有沒有列入公告」與「問題是否真實、是否已修」可以完全脫鉤；防守方若只盯公告清單，會漏掉這種已修但未被正式承認的洞，反之只聽揭露者敘事也會失真，兩邊的原始紀錄都要看。

5. 防守建議

  1. 確認安全性更新等級：Android 14 至 17 的裝置，確認「Android 安全性更新」日期為 2026 年 10 月或之後，即已修補；注意各廠牌與電信商的推送時程不同，更新後可能需要重新開機才完成安裝。
  2. Android 12／13 裝置不會收到修補：同一份缺陷程式碼仍在，且已不在安全性更新支援期。若這類裝置承載重要聯絡或緊急通話角色，應評估更換；至少要知道它面對已公開的 PoC 沒有官方防線。
  3. 辨識症狀：通話無故中斷、手機反覆自動重開機、開機後很快又當機，且收件匣裡看不到任何可疑訊息——符合這組症狀時，可考慮本漏洞的可能性（但同症狀也可能來自其他故障，先保留證據再處理）。
  4. 陷入重開機迴圈時不要急著恢復原廠設定：先試第 3.4 節的 ADB 復原法，或交由有 ADB 能力的維修人員處理；復原模式畫面出現時不要點選 wipe data。
  5. 組織面：配發 Android 裝置的單位應盤點裝置的 Android 版本與安全性更新等級，把停留在 12／13 或長期未更新的裝置列入汰換或隔離清單；緊急聯絡用途的備援通訊不要只押在單一支未修補裝置上。

6. 原始來源與參考

← 返回事件分析列表