8 字节短信秒废安卓机：SMS of Death 漏洞 CVE-2026-58882 复盘

导语：一条 8 字节的畸形短信发过来，手机用户什么都不用点，Android 的电话服务进程当场猝死，正在进行的通话——包括紧急呼叫——被一并切断。独立研究者马克·布拉斯齐克（Mark Blaszczyk）把它叫作「死亡短信」，漏洞编号 CVE-2026-58882，等级 Critical。谷歌一开始判定这不是安全问题，最后还是把补丁发了出去。

8 个字节，扔进 raw 队列

整个 payload 就 8 个字节：01 06 88 80 80 80 00 BE，以数据短信形式发往 WAP Push 端口 2948。谷歌的漏洞奖励计划（VRP）档案和研究者公开的原始代码里，根因一目了然：

// WapPushOverSms.java:217  头长度按 uintvar 读成 long，直接强转 int，没有范围校验
int headerLength = (int) pduDecoder.getValue32();
// WapPushOverSms.java:244  强转的结果直接当数组长度
byte[] header = new byte[headerLength];

88 80 80 80 00 这 5 个字节按 uintvar 展开是 0x80000000，强转成有符号 int 就是 -2147483648。于是 new byte[-2147483648] 抛出 NegativeArraySizeException，而它发生在 telephony 主线程上，没人接，com.android.phone 进程直接死。

杀伤力不在“崩一下”，在它不放手

零点击、静默，这两条是它最难防的地方。消息以数据短信形式进入 raw 队列，不进收件箱、不弹通知，用户连发送方号码都看不到，也没有任何提示让自己去怀疑。

真正的破坏在三处。正在进行的语音通话会以 CS_DEATH 原因被切断，每次进程重启电话服务有 1 到 2 秒空白。更麻烦的是运营商会重投没被确认的消息，毒消息被反复送达、反复触发，研究者在测试中用一条短信造成了最长一周的间歇性掉线。二十条左右就足以让设备长时间不可用。

最狠的是持久化：毒消息留在 raw 队列里，每次开机都被重新处理，手机开机即崩。系统的 RescueParty（救援机制）大约每 90 秒把机器拉进 recovery 并弹出擦除提示，普通用户很可能直接选了“抹掉全部数据”。复现率是 100%，在 Pixel 9（2026 年 4 月固件）以及多款三星（Samsung）Galaxy 和 A 系列机型上都验证过。

谷歌说“这不是安全问题”，然后还是修了

时间线很能说明问题：2026 年 5 月 5 日提交 VRP，6 月 15 日谷歌工程师写下 commit 735d967，7 月预览通道先行放出、GrapheneOS（开源安全系统）当月就合入，10 月补丁随月度更新下发到 Android 14–17，10 月 29 日研究者公开，拿到 CVE-2026-58882，评级 Critical，列入 11 月安全公告。

谷歌最后没有采用研究者当天就提交的范围校验建议，而是把 catch 从 ArrayIndexOutOfBoundsException 放宽成 RuntimeException 吞掉异常，并在收信侧新增 deleteFromRawTable()，把毒消息直接删掉——这样才真正断掉重投和开机重试的循环。

影响范围这边要泼盆冷水：Android 12 到 17 都跑着这段代码，而 12 和 13 早已出了安全更新窗口，厂商不会再发补丁。也就是说，这个 Critical 漏洞在老机型上是长期裸奔状态。

中招了，只剩 ADB 一条路

清理毒消息必须用 ADB，命令行大致是这几步：

# 找出 WAP Push 毒消息（destination_port=134020）
adb shell content query --uri content://sms/raw --projection _id:destination_port:date:deleted
# 临时放行 shell 写短信权限，删掉对应地址的行，再把权限改回去
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
# 兜底：清空全部短信、彩信与 APN 设置
adb shell pm clear com.android.providers.telephony

研究者自己还有一招：把实体 SIM 插到非安卓机上，让运营商把未回执的消息确认掉，从源头掐断重投。eSIM 用户没这个便利。最后一句必须重复：recovery 界面里千万别选 wipe data。

这个漏洞真正瞄准的东西：紧急呼叫

澳大利亚的监管设计很能说明这条攻击的价值。《电信（紧急呼叫服务）决定》要求运营商识别出打不通 000 的手机，协助用户换到能用的设备，并在通知 28 天后停用该终端，澳洲电信（Telstra）也明说要封机。

讽刺的地方在这儿：监管给出的补救手段是把这台机踢出网络，而不是给系统打补丁。攻击者等于可以远程让受害者自己的手机被运营商封停，直到它更新系统为止。2024 年 3G 退网后规则收紧过一次，起因就是有一批手机能打普通电话却打不通紧急电话——和这个漏洞制造出来的状态一模一样。

给防守方的三句话

第一，补丁基线卡死在 2026 年 10 月，14–17 已经拿到补丁；12 和 13 的用户基本只能换机。第二，把 content://sms/raw 里出现 destination_port=134020 的行当成入侵告警，别等用户来报修。第三，防守的眼睛要盯住 telephony framework 这条独立通道，而不是“信息”应用的用户界面——那里什么都显示不出来。

PoC 与完整分析（只在自己或获得书面授权的设备上运行）：完整报告 https://smsofdeath.com/ ，源码与测试用 APK https://github.com/MarkBlah/smsofdeath 。

参考来源：

SMS of Death 完整技术报告（2026-10-29）：https://smsofdeath.com/
heise online（2026-10-30）：https://www.heise.de/news/SMS-des-Todes-Sicherheitsluecke-laesst-Android-Smartphones-abstuerzen-11506526.html
Cybernews（2026-10-30）：https://cybernews.com/security/android-sms-of-death-critical-vulnerability/
GrapheneOS 公告：https://grapheneos.social/@GrapheneOS/117525460785264691

文章版权归作者所有，未经允许请勿转载。

THE END