安全研究員 Mark Blaszczyk 於二零二六年十月二十九日公開披露名為「死亡短訊」（SMS of Death）的 Android 零點擊遠端拒絕服務缺陷，編號 CVE-2026-58882：攻擊者只需向目標門號送出畸形 WAP Push 數據短訊，即可在無需點擊、亦無收件匣提示的情況下令系統電話進程崩潰，打斷進行中的通話（包括緊急求助），並可因電信商重送與開機重試而演變成反覆當機甚至復原模式迴圈。Google 已將修補納入二零二六年十月 Android 安全更新（涵蓋 Android 14 至 17）；Android 12／13 等已離開更新窗口的裝置仍可能暴露。來源真實性已驗證：本文以研究員公開技術頁為主，並對照 BleepingComputer、Android Authority、Cybernews 等報道核對影響範圍與修補狀態。
研究員／公開披露：Android「死亡短訊」CVE-2026-58882——畸形 WAP Push 零點擊癱瘓通話；十月更新涵蓋 14–17，12／13 暫無補丁
智能電話的通話與緊急求助依賴系統電話進程穩定運行。當一則對使用者完全不可見的數據短訊即可遠端打斷該進程，風險便從「惱人當機」升級為流動通訊可用性與公共安全問題。來源真實性已驗證。
一、核心事件：零點擊、靜默、可持續的遠端拒絕服務
披露時間線
研究員於二零二六年五月五日經 Android／裝置漏洞懸賞計劃（VRP）通報；公開寫作頁標示二零二六年十月二十九日公開披露。多家科技媒體於十月三十一日跟進報道，指相關概念驗證已公開，未修補裝置風險上升。公開頁將缺陷定位於 Android 核心電話框架的 WAP Push 解碼路徑（WapPushOverSms），攻擊向量為遠端短訊、目標埠 2948，互動需求為「無」——受害者無需點擊、開啟或看到任何通知。
影響表現（公開測試描述）
公開技術說明列明多項後果：
- 零點擊且靜默：畸形訊息以數據短訊送達，不會出現在一般短訊收件匣，亦不會顯示發送者門號。
- 通話中斷：
com.android.phone進程崩潰時，進行中的語音通話會被切斷，公開頁指包括緊急求助通話；進程重啟期間約有一至兩秒無法使用流動服務。 - 電信商重送放大傷害：裝置若未確認收妥，電信商可能重送同一訊息，令崩潰反覆發生；測試中單則訊息曾造成長達約一星期的間歇性中斷。
- 持續拒絕服務：畸形訊息可留在待處理佇列，每次開機重試；約二十則訊息可使裝置長時間無法正常使用。Android 12 測試中，RescueParty 約每九十秒把裝置帶入復原模式，一般使用者往往只能選擇重設出廠才能脫困。
- 機型覆蓋：公開頁指在 Pixel 與多款 Samsung Galaxy／A 系列等裝置上重現率為百分之百（按其測試範圍）。
修補與殘留風險
公開頁與跟進報道指 Google 工程師於二零二六年六月十五日提交名為「Fix remote DoS in decodeWapPdu」的修補，並隨二零二六年十月 Android 安全更新發放予 Android 14 至 17。修補策略是擴大例外處理並刪除觸發崩潰的訊息，避免電信商重送或開機重試再次擊中同一缺陷，而非僅在解碼前加入長度邊界檢查。BleepingComputer 等指出，該 CVE 未見列於 Google 十月安全公告公開條目；部分報導引述 GrapheneOS 指相關項目可能改於十一月公告呈現。Android 12、13 等已離開官方安全更新窗口的裝置，公開評估為仍可能運行同一脆弱程式碼而得不到對應修補。
二、技術原理深度解析
問題本質：長度欄位未經邊界檢查的整數轉換
WAP Push 屬舊式營運商推送機制，可在使用者無感情況下觸發裝置處理。公開分析指出，解碼函式讀取 WSP 標頭長度後，將較大整數直接轉成三十二位元有符號整數，再用作位元組陣列大小。當長度欄位被構造成特定極大值時，轉換結果變為負數；以負數配置陣列會拋出未捕捉的 NegativeArraySizeException，落在電話主執行緒上，直接令 com.android.phone 終止。
為何「看不見」反而更危險
傳統惡意短訊常依賴使用者點擊連結。此缺陷在訊息進入收件匣可見層之前已觸發系統層解碼，受害者既看不到異常寄件人，也難以把「突然斷線／無服務」與短訊攻擊聯想起來。對事故應變而言，日誌若只看應用層收件匣會完全漏掉根因。
從單次崩潰到「破壞性遠端拒絕服務」
公開頁強調其與漏洞懸賞「破壞性遠端拒絕服務」形態相符：不僅瞬時當機，更可透過佇列重試把裝置推入反覆復原、逼使重設出廠的狀態。對企業流動裝置管理（MDM／EMM）而言，這代表攻擊面不只是資料外洩，而是大量前線員工手機能否維持通話與雙重驗證推送通道。
概念驗證公開後的風險窗口
媒體報道指概念驗證已公開，令「知悉門號即可嘗試」的門檻下降。防禦重心應放在：盡快確認裝置安全修補等級是否已達二零二六年十月一日或之後、淘汰無法再收官方修補的舊機、以及在企業環境限制不明來歷數據短訊／營運商推送處理面（視平台與電信商能力而定）。本文不會轉載任何可直接復現攻擊的位元組樣本或操作步驟。
三、日常應用場景
1. 開發者與技術團隊
負責 Android 企業應用、遠端支援或內部通訊 App 的團隊，應把「安全修補等級」納入裝置合規檢查（例如要求 2026-10-01 或更新），並在事故 runbook 加入「無收件匣紀錄卻出現週期性電話進程崩潰／復原迴圈」的排查分支。對仍須支援 Android 12／13 的產品線，應明確標示該版本可能長期暴露於此類框架缺陷，並評估強制升級或汰換時程。
2. 企業與隱私敏感行業
銀行、醫療、物流與外勤團隊高度依賴 Android 工作機與 BYOD。通話被遠端打斷會直接影響客戶服務與緊急協調；若裝置陷入復原迴圈，更可能同時失去 MFA 推送、工作即時通訊與定位回報。資安與 IT 應優先盤點未達十月修補等級的機隊、加快 OEM／電信商更新通道，並對無法更新的裝置執行網絡隔離或更換。事故通報方面，即使沒有個資外洩，大規模可用性攻擊仍可能觸發業務連續與客戶通知義務，須按行業監管自行評估。
3. 一般用戶
請到「設定 → 關於手機」確認安全更新日期；若尚未安裝二零二六年十月或之後的安全修補，應盡快經系統更新或電信商通道安裝並重新開機。暫時無法更新的舊機，宜避免作為唯一緊急聯絡裝置，並留意是否出現無故斷線、反覆重啟或進入復原畫面。不要下載來路不明的「檢測工具」或掃描來歷不明的二進位檔。
4. 香港與亞洲市場視角
香港與亞洲市場 Android 佔比高，中小企與前線行業大量使用中階 Android 機，OEM 推送安全修補的節奏不一，容易出現「新機已修、舊機長期裸奔」的雙軌風險。本地企業若以 WhatsApp、企業通訊 App 與短訊 OTP 作為營運神經，裝置層拒絕服務會同步打擊身份驗證與客服熱線。把流動裝置基線納入雲端遷移與網絡安全治理——強制修補等級、淘汰停止支援的系統版本、分離高權限工作負載——比單靠應用層防毒更貼近此漏洞的根因。對同時服務粵港澳或多國外勤的團隊，更需統一「最低安全修補等級」政策，避免一地已修、另一地機隊仍暴露。
四、專業評價與潛在考量
優勢
研究員經 VRP 負責披露，公開技術頁清楚區分機制、影響與修補狀態；Google 已在十月更新向 Android 14–17 發放修補，並嘗試從「刪除毒訊息」打斷重送／開機迴圈，屬對症的可用性修復。媒體廣泛跟進有助提高使用者更新意識。
需要留意的地方
CVE-2026-58882 雖獲多家媒體引用，但公開十月安全公告條目未必逐一點名，企業盤點時不能只搜公告關鍵字，而應以實際安全修補等級與供應商說明為準。Android 12／13 等停止支援版本可能長期無官方修補；概念驗證公開後，針對特定門號的騷擾式拒絕服務門檻下降。公開頁亦提醒：干擾他人緊急通訊在多地屬嚴重罪行，任何測試只應在自有或獲書面授權的裝置上進行。
結語
「死亡短訊」把舊式 WAP Push 解碼路徑上的整數轉換缺陷，轉化成零點擊、靜默且可持久化的流動通訊拒絕服務——對個人是斷線與重設風險，對企業則是機隊可用性與緊急聯絡韌性問題。短期內最有效的防線仍是確認並安裝二零二六年十月或更新的 Android 安全修補，並加速淘汰無法再更新的舊裝置。若香港團隊需要把流動與雲端攻擊面納入同一套基線——裝置合規、零信任存取、事故應變與持續監控——可參考 YSK Limited 的雲端遷移與網絡安全服務（https://ysk.hk/services/cloud-security）。
參考來源
- SMS of Death 公開技術披露（研究員主頁）：https://smsofdeath.com/
- BleepingComputer：New Android SMS of Death exploit can remotely crash unpatched phones（2026-10-31）：https://www.bleepingcomputer.com/news/security/new-android-sms-of-death-exploit-can-remotely-crash-unpatched-phones/
- Android Authority 跟進報道：https://www.androidauthority.com/android-sms-of-death-google-fix-3729929/
- Cybernews 跟進報道：https://cybernews.com/security/android-sms-of-death-critical-vulnerability/
- Android 安全公告（2026-10-01）：https://source.android.com/docs/security/bulletin/2026/2026-10-01