崩溃不算漏洞？Telegram 四端持久化 DoS 疑云与成因分析

威胁简报 · 恶意软件 · 漏洞攻击

前言

2026 年 9 月 6 日，X 上一份报告把 Telegram 的一个老问题重新推到台前。用户 GangExposed RU（@GangExposed_RU）声称，他拥有的一个 Telegram 群组被人用恶意内容弄成了完全不可访问的状态：任何人在任何平台上尝试打开这个群组，客户端都会崩溃。他在 iOS、Android、Desktop 与 Web 四个端上复现了这一现象，并公开呼吁 Telegram 调查。

本文写作前对这份报告做了逐项核实。核实结果需要放在开头讲清楚：截至 2026 年 9 月 7 日，这份报告没有 CVE 编号，没有 Telegram 官方回应，没有独立媒体的二次确认，也没有公开的复现代码。它是一份未经证实的初步报告，不是已确认的漏洞。本文不会把它写成"Telegram 爆发新漏洞"，而是把它当作一次真实的取证起点，围绕"四端同时崩溃"这个现象，结合 Telegram 客户端历史上已确认的内容触发崩溃案例，给出成因分析框架与防护建议。

报告人的身份是这份报告值得认真对待的原因之一，第一章会展开。

一、事实钉死：一份推文报告说了什么

1.1 推文逐条拆解

推文发布于 2026 年 9 月 6 日 13:45（UTC），原文要点如下：

• 报告人称其拥有（own）的一个 Telegram 群组被蓄意做成完全不可访问
• 每次尝试打开该群组，Telegram 客户端崩溃
• 问题在 iOS、Android、Desktop、Web 四个端上均可复现，聊天完全不可访问
• 群组未被删除或封禁，报告人仍是所有者，邀请链接仍然有效
• 报告人称知道攻击者是谁
• 报告人怀疑有人故意把恶意内容放进群组以触发客户端崩溃
• 推文推断：若该状况可由特定内容远程触发，攻击者可能通过发送特制载荷让任意 Telegram 群组不可访问
• 报告人 @telegram 呼吁紧急调查，并表示可私下提供细节与证据

推文互动数据：33 赞、10 转、2 回复。配图是一张写着"NEW VULNERABILITY IN TELEGRAM"的封面图，不含技术细节。

这份推文里混合了三类信息，需要分开处理。第一类是现象陈述（打开即崩、四端复现、群组状态正常），这类信息可以被验证。第二类是归因判断（知道攻击者是谁、恶意内容被故意投放），这类是报告人的主观陈述，目前没有可公开验证的证据。第三类是威胁外推（任意群组都可能被攻击），这是基于第二类的推论，前提成立与否完全取决于第二类。

1.2 报告人背景：为什么这份报告值得认真对待

GangExposed 不是普通用户。2025 年，这个身份以一系列针对 Conti 与 Trickbot 勒索软件团伙的曝光行动进入公众视野：公布内部聊天记录、点名核心成员，其中包括被德国警方确认身份的 Conti 领导者 Stern（真名 Vitaly Kovalev），以及被指认为 Professor 的 Vladimir Kvitko。美国政府对 Conti 核心成员开出的悬赏高达每人一千万美元，而 GangExposed 公开表示对赏金没有兴趣。The Register 等媒体对其做过直接采访。

这份背景带来两个推论。其一，他运营的 Telegram 频道处在与网络犯罪团体直接对抗的位置，频道被其中被曝光的团体报复是存在现实动机的场景，而非纯粹的理论假设。其二，他具备辨识针对性攻击的动机与经验，"知道攻击者是谁"这句话在其身份背景下不是空话。

但背景不能替代证据。动机充分不等于攻击坐实，这一点与漏洞核实是同一套逻辑。

1.3 当前核实状态：三条全部缺位

本文在 2026 年 9 月 7 日做了如下核实：

• CVE 数据库中无对应编号，MITRE、NVD、GitHub Advisory 均未收录与本事件相关的记录
• Telegram 官方无公开回应，其官方安全通告渠道无相关条目
• 主流安全媒体无二次报道，无独立研究者公开复现
• ZDI 已发布通告列表（覆盖 2026-07-29 至 2026-08-31）与待发布列表中均无 Telegram 相关条目

三条关键证据链（编号、厂商确认、独立复现）全部缺位。在这种情况下，严谨的写法只有一个：把它当作一份待验证的报告，而不是一个已确认的漏洞。

---

二、影响范围：个案与假设的边界

2.1 已确认的影响：一个群组的可用性

如果报告属实，当前被确认受影响的是这一个群组：其全部成员（含所有者）无法打开该群组查看或发送消息，聊天记录对日常使用而言处于事实上的不可达状态。

群组本身没有被删除，数据应该仍在 Telegram 服务端，邀请链接仍然有效。这意味着损害是可用性层面的，不涉及消息内容泄露。所有者无法打开群组这一细节尤其值得注意：如果打开动作本身触发崩溃，那么进入管理界面清理触发内容的常规路径可能同样被堵死，受害者自己无法完成修复。

2.2 若猜测成立的影响面

报告人的外推是：若触发条件是特定内容，攻击者可以向任意群组发送载荷，使该群组对所有人不可访问。这个外推成立的前提有三个：

一，触发物确实是群内存储的某条内容，而非攻击者对特定群组的其他操作；

二，触发不依赖特定账号或会话状态，即任何客户端打开都会崩；

三，Telegram 服务端的反滥用机制无法提前拦截该内容。

三个前提都验证通过，才构成"任意群组可被远程打死"的结论。报告本身没有提供任何一条的验证。本文第二章会说明，其中第二个前提有四端复现这个现象的间接支持，但间接支持不是证明。

从影响等级看，即使外推成立，这类问题的性质也是持久化的客户端拒绝服务（Denial of Service，DoS），不涉及保密性或完整性。它不会泄露聊天记录，不会接管账号，不会执行代码。评价它的影响时不能借用 RCE 的叙事。

2.3 明确不在影响范围内的

• 未加入该群组的普通用户：当前没有任何证据表明存在波及无关用户的影响
• Telegram 服务端：报告明确说明群组未被封禁，服务本身运行正常
• 消息内容与账号安全：现象是崩溃，不是泄露
• 已有历史 CVE 的已知问题：rlottie 漏洞（2021 年修复）与 Desktop 登录 URL 空指针（2026 年 5 月记录）均与本事件无关联证据，不能混为一谈

---

三、成因调查：四端同时崩溃意味着什么

这是本文的技术核心。报告中最有信息量的单一事实不是"崩溃"，而是"四端崩溃"。

3.1 四端复现排除了什么

Telegram 的四个客户端技术栈几乎完全不重叠：iOS 是原生 Swift 实现，Android 是 Kotlin 与 Java，Desktop 是 C++ 与 Qt，Web 是 TypeScript 与浏览器 API。四端只共享协议与服务端下发数据，不共享界面渲染代码。

这个事实直接排除了一类解释：某个单一客户端的内存安全缺陷。历史案例里，rlottie（动画贴纸渲染库，C++ 实现）的四个 CVE 只影响使用原生渲染的 Android、iOS 与 macOS 端，Desktop 与 Web 天然免疫。如果本事件是同类缺陷，Web 端不应复现。Web 端崩溃，说明触发物大概率不在某一个渲染库内部，而在四个客户端都必须处理的公共数据路径上。

3.2 三个技术方向

方向 A：数据驱动的解析失败。群组内存在一条或多条格式非法或极端的数据，四个客户端的解析器在这份数据上各自失败。候选载体包括消息文本与实体（entity，消息内的富文本标注结构）、媒体文件头、动画贴纸、群组名称、置顶消息。这个方向与"恶意内容被故意投放"的报告人猜测直接兼容。

方向 B：资源耗尽。数据本身格式合法，但声明了极端的取值，例如天文数字的图层计数、异常的嵌套深度、超大的尺寸字段。四个客户端各自进入内存耗尽（OOM）或长时间无响应，在用户感知上等同于崩溃。这个方向的历史对应物是 ZDI-CAN-30207 报告中提到的贴纸元数据解析问题（该案例本身有争议，见第四章）。

方向 C：公共逻辑缺陷。Telegram 的消息实体有一套跨端的解析约定（哪些实体类型、如何渲染、如何处理嵌套）。如果某个约定本身存在逻辑错误，且四个客户端都忠实实现了这个约定，一份按约定构造的恶意数据就能让四端同时出问题。这个方向的严重性最高，因为它意味着问题在协议或产品层，而不在某一个客户端。

三个方向不互斥，真实案例可能是组合形态。

3.3 打开路径分析：崩在哪一步

"打开群组"不是一个原子操作，客户端要依次完成多个步骤：

1. 拉取该群组的最近消息列表
2. 更新会话列表预览（群组名称与末条消息摘要）
3. 渲染聊天背景与消息气泡
4. 解析消息实体（加粗、链接、提及、自定义 emoji 等）
5. 预加载与解码媒体资源（图片、视频、贴纸）
6. 渲染置顶消息与引用

任何一步失败都会表现为"打不开"。步骤 2 是关键：群组名称与末条消息摘要出现在会话列表里，如果触发物是群名或末条消息，用户甚至不需要主动点开群组，回到主列表就可能崩。报告描述的是"尝试打开群组导致崩溃"，说明触发物更可能在步骤 1 与步骤 6 之间，即消息内容本体。

这个路径分析对受害者的自救有直接意义：如果崩在消息渲染，那么通过不渲染消息的方式访问群组（例如某些客户端的省流量模式、或服务端导出接口）或许可以绕过；如果崩在列表预览，绕过空间会更小。报告未提供这类细节，属于待验证项。

3.4 一个值得记录的佐证细节

报告人称群组邀请链接仍然有效。这一点如果属实，说明服务端没有判定该群组异常，问题不在 Telegram 的服务端风控侧，而在客户端对某份数据的处理侧。这与三个技术方向都兼容，同时进一步削弱了"群组被平台限制"这类平凡解释。

3.5 给后续验证者的路径

本事件从"待验证报告"走向"确认漏洞"，需要补齐的验证动作是可以明确列出的。以下清单同时适用于研究者复核与报告人自证：

一，锁定触发物。在受控环境中用逐条方式定位触发内容：备份群组数据后，将嫌疑消息分批移除并观察崩溃是否消失。触发物锁定前，任何归因都只是猜测。

二，采集四端崩溃日志。iOS 的崩溃日志在设置、隐私与安全性、分析与改进中可导出；Android 通过开发者选项获取 tombstone；Desktop 从终端启动捕获标准错误输出；Web 端读取浏览器开发者工具的控制台与网络记录。四端日志的调用栈若落在相似的数据解析层，方向 A 与方向 C 的可能性将大幅上升。

三，核对客户端版本。四端的精确版本号决定崩溃是否只发生在旧版：若最新版本不复现，说明缺陷已被某次更新顺带修复，事件性质降级为已修复的历史缺陷。

四，区分崩溃与资源耗尽。崩溃日志中的信号类型（如空指针解引用与内存耗尽被系统查杀）直接区分方向 A 与方向 B。二者的影响评估与修复路径完全不同。

五，向厂商提交正式报告。公开推文不进入修复流程，正式报告（邮件、附带复现步骤与日志）才会被分配处理资源。本事件的推文属于公开喊话，正式报告是否已提交，外界无从得知，这是目前信息缺口的一部分。

这五步里任何一步的公开结果，都比再写十篇推断文章更有价值。本文将成因讨论严格限定在框架层面，不做超出证据的定性，原因即在于此。

---

四、历史先例：Telegram 的内容触发崩溃攻击面

本事件虽然未经证实，但"一份内容让 Telegram 客户端崩溃"这件事本身，在 Telegram 的历史上是被反复证实过的攻击面。梳理这些已确认的案例，是评估本事件可信度的最好参照。

4.1 rlottie 四连 CVE：贴纸渲染的旧账

2021 年 2 月，意大利安全公司 Shielder 的研究者系统性地审计了 Telegram 的动画贴纸攻击面，在其自维护的 rlottie 库（Samsung 开源的 Lottie 动画渲染库的 C++ fork）中发现了四个漏洞，全部为 CWE-787（越界写入），全部由恶意动画贴纸远程触发：

CVE	函数	类型	评分
CVE-2021-31320	VGradientCache::generateGradientColorTable	堆缓冲区溢出	7.1
CVE-2021-31321	gray_split_cubic	栈缓冲区溢出	7.1
CVE-2021-31315	blit	栈越界读取	5.5
CVE-2021-31322	LOTGradient::populate	堆缓冲区溢出	5.5

影响范围为 Telegram Android 低于 7.1.0（2090）、iOS 与 macOS 低于 7.1，2021 年 5 月随 7.1 版本修复。这组漏洞确立了两个事实：动画贴纸是 Telegram 攻击面上被反复证明的高危区；渲染库的内存安全问题可以让"收到即崩"成为现实。

值得记录的长期问题是 rlottie 的维护状态。研究者指出该库的大部分提交已停止更新多年，作为 C++14 项目，其复杂度与维护投入之间的落差，使这类缺陷被发现只是时间问题。2026 年的 ZDI-CAN-30207 争议（下节）又一次落在这个组件附近，这不是巧合。

4.2 ZDI-CAN-30207：一场未完成的争议

2026 年 3 月 26 日，趋势科技 Zero Day Initiative（ZDI）的研究员 Michael DePlante 报告了一个针对 Telegram Android 与 Linux 版的零点击（zero-click）远程代码执行漏洞，初始 CVSS 评分为 9.8，攻击路径是恶意动画贴纸：客户端收到贴纸后自动解析生成预览，解析阶段即触发代码执行，全程无需用户交互。

事件随后进入罕见的争议状态。意大利国家网络安全局（ACN）发布通告，Telegram 正式否认漏洞存在，理由是所有上传的贴纸在分发到客户端之前均经过服务端验证与扫描，恶意贴纸在技术上不可能到达用户设备。ZDI 因服务端缓解措施将评分从 9.8 下调至 7.0，并给出 2026 年 7 月 24 日的披露期限。

heise 的评论点出了这类回应的局限：服务端扫描不能关闭客户端代码中的缺陷，它只是提高了利用难度。扫描器解析不了的数据，目标软件未必解析不了，混淆与差异化解析是绕过服务端扫描的常见路径。

本文在 2026 年 9 月 7 日核查了 ZDI 的已发布与待发布通告列表，未检索到 ZDI-CAN-30207 的正式通告，其最终状态（发布、撤销或以其他形式解决）没有公开结论。这个案例与本事件的关联在于它证明了两件事：贴纸渲染管线直到 2026 年仍是争议中的高风险区；Telegram 对内容触发类问题的第一反应是否认，这直接影响此类问题的披露节奏。

4.3 CVE-2026-7701：厂商对崩溃类的定价

2026 年 5 月，VulDB 收录了一条 Telegram Desktop 的空指针解引用报告：6.7.0 至 6.7.5 版本中，Bot API 组件的 RequestButton 函数（url_auth_box.cpp 文件）在处理 login_url 参数时触发崩溃，可远程发起，需要用户交互。修复版本为 6.7.6。

这个条目最有价值的部分是它的状态：Disputed（争议中）。Telegram 对争议给出的理由原文是：所描述场景不构成任何安全问题或漏洞，仅导致一次性崩溃，目标用户必须执行主动操作，应用重启后不产生任何后果。

厂商的表述在其定义域内没有错：一次崩溃、重启即恢复、无数据影响，按传统安全影响评估确实接近于无。但 CVE-2026-7701 的触发点在按钮确认弹窗，属于一次性交互崩溃；本事件报告的是持久化崩溃，每次打开都复现，且所有者可能失去管理入口。两者在"重启能否恢复"这个关键维度上不同。把厂商对一次性崩溃的低定价，套用到持久化 DoS 上，是评估本事件影响时需要避开的错误。

4.4 地下市场背景

Telegram 客户端漏洞在地下市场的定价提供了另一个视角。2025 年 3 月，漏洞经纪公司 Operation Zero 公开为 Telegram 全链漏洞开出最高 400 万美元的收购价：一键 RCE 50 万美元起，零点击 RCE 150 万美元起，全链（突破到操作系统层）400 万美元。更早的案例包括 2024 年 7 月的 EvilVideo（CVE-2024-7014，恶意 APK 伪装成视频借自动下载落地，10.14.5 修复）与同年的 .pyzw 文件误标记问题。

把这些价格与本事件对照，可以得出一个明确的判断：单纯让客户端崩溃的 DoS 在这个市场上几乎不值钱，价值集中在 RCE。因此，如果本事件背后真存在一个未公开的缺陷，报告人选择公开 DoS 现象而非出售，逻辑上更可能是他没有能力（或没有必要）把它升级为 RCE，而不是存在一个被隐藏的高价值漏洞。

五、定性辨析：一次性崩溃与持久化 DoS

5.1 两者的区别

把崩溃类问题一概而论是评估本事件时最常见的错误。两类问题在三个维度上不同：

维度	一次性崩溃（CVE-2026-7701 形态）	持久化 DoS（本事件报告的形态）
触发条件	用户执行特定操作（点击 login_url）	打开群组即触发，无主动选择
恢复方式	重启应用即恢复	触发物持久存储于群组，每次打开复现
自救空间	有，重启后避开该内容即可	存疑，管理入口可能同样不可达
波及范围	主动触发的个体	群组全部成员，含后续加入者

持久化 DoS 的本质是把触发物存储进了受害者的必经数据路径。它与垃圾消息的区别在于，垃圾消息可以被删除、被忽略，而触发崩溃的内容删除它本身就要求先打开群组。这构成了一个自锁结构：修复动作的前置条件被故障本身破坏。

5.2 Disputed 状态的启示

CVE-2026-7701 的 Disputed 处理透露了厂商对这类问题的真实优先级。对 Telegram 而言，客户端崩溃影响的是单次体验，服务端数据与安全边界没有受损，投入研发资源修复的回报很低。这个优先级排序在商业上可以理解，但它给防御侧留下了一个结构性空档：针对高价值目标的持久化内容攻击，可能长期处于无人修复的状态。

对使用者而言，这个空档意味着不能把希望完全寄托在官方补丁上。第六章的处置建议会基于这一点展开。

5.3 高价值群组的真实风险

报告人的身份让这个案例的风险模型更具体。对一个运营着曝光勒索团伙内容的频道所有者来说，群组不可访问造成的损失不只是使用不便：信息发布的连续性中断、关注者流失、以及在对抗场景中被对方达成了一次低成本的成功骚扰。

这类场景下，攻击的成本与收益严重不对称。攻击者只需要一次投毒，防御者面对的是持久化故障与可能缺位的官方修复。这正是本文在处置建议中把冗余与备份放在高优先级的原因。

七、结束语

回到最初的问题：这个漏洞是真的吗。截至 2026 年 9 月 7 日，诚实的回答是：现象报告未经验证，归因判断无从核实，威胁外推缺乏前提。本文能确认的只有三件事：报告人的身份使其陈述具备基本可信度；四端同时崩溃这一细节把问题指向跨端的公共数据路径而非单一渲染缺陷；Telegram 的历史上存在大量已确认的内容触发崩溃先例，这个攻击面是真实存在的。

本文给出的成因框架（数据驱动解析失败、资源耗尽、公共逻辑缺陷三个方向）适用于后续所有同类报告的初判。当 Telegram 回应、或独立复现出现时，三个方向中的哪一个被证实，会直接决定影响范围的最终大小：数据驱动是客户端缺陷，补丁可修；资源耗尽是工程问题，缓解可解；公共逻辑缺陷则是协议层问题，修复成本最高，影响也最持久。

比结论更重要的是这次事件暴露出的处置结构问题。内容触发类缺陷的攻击成本极低，而官方修复的优先级偏低，两者之间的落差完全由防御侧承担。对普通用户，这个落差可以用更新与关闭自动下载来弥合；对运营着高价值频道的人，只能用冗余、备份与取证习惯来对冲。报告中那位举报人失去的是一个群组的可用性，而他做对的一件事值得所有运营者效仿：在第一时间留下了可核查的公开记录。

唯有把这类报告当作取证起点而非流量素材，才能在厂商响应缺位的环境里，把零散的个案积累成可定位、可修复的证据链。类似的安全事件追踪与深度分析，也将在云栈社区持续更新，欢迎关注后续进展。