Telegram贴纸零点击漏洞：iOS代码执行攻击链与客户端安全解析

近日，安全研究人员 Saifeldeen Aziz 声称在 Telegram 的贴纸处理机制中发现了新的零点击漏洞。通过组合多个漏洞，他称自己实现了在 iOS 版 Telegram 上执行代码的完整攻击链。

据研究人员公布的演讲摘要显示，这项研究历时约一年，涵盖了动画解析组件、客户端漏洞以及贴纸分发与校验逻辑等多个层面。相关成果原计划于 2026 年 10 月 28 日在东京举行的 OffensiveCon 安全会议上进行分享。

不过需要特别说明的是，目前公开的摘要尚未提供完整的技术细节、可复现的利用证据以及新漏洞的编号。因此，“零点击攻击链”和“iOS 代码执行”目前仍应视为研究人员披露的研究结论，而非已经得到公开独立验证的事实。

这项研究之所以值得关注，不仅在于其声称的攻击效果，更在于它再次抛出了一个值得思考的问题：如果客户端本身存在漏洞，而安全性主要依赖服务端过滤，那么这道防线究竟有多可靠？

一、从动画贴纸入手：问题出在客户端解析逻辑

Telegram 的动画贴纸使用 TGS 格式，本质上是经过压缩的 Lottie 动画数据。客户端需要对这些数据进行解析和渲染，相关工作涉及 rlottie 动画处理库。

这类功能看似与安全无关，却可能成为真实的攻击面。

客户端必须处理来自外部的数据。如果输入数据在解析过程中触发内存越界、整数处理错误等问题，就可能导致程序崩溃，严重时甚至可能为代码执行创造条件。

此次争议涉及的一个已公开漏洞，正是出现在 rlottie 相关代码中。

2026 年 10 月 15 日，趋势科技零日计划（Trend Micro Zero Day Initiative，ZDI）发布安全公告 ZDI-26-757，将该问题追踪为 CVE-2026-111105。

根据公告相关报道，该漏洞涉及数值截断问题，可能导致程序向内存缓冲区起始位置之前写入数据，进而引发内存破坏，存在进一步实现代码执行的风险。

此前，安全研究人员 Pasquale Pillitteri 也曾展示过一个仅有 269 字节的动画贴纸样本，可以导致 Telegram 客户端崩溃，甚至使相应聊天无法正常使用。

这也说明了一个关键点：即使文件体积很小，只要客户端解析逻辑存在缺陷，就可能造成安全问题。数据大小本身并不能代表输入是否安全。

需要区分的是，上述已公开漏洞与 Aziz 声称发现的新漏洞并非同一组已确认的问题。两者涉及相近的技术组件，但不能据此认定它们属于同一条攻击链。

二、争议焦点：服务端过滤能否挡住客户端漏洞？

此次研究的另一个背景，是 Telegram 与 ZDI 此前围绕贴纸漏洞展开的争议。

据相关报道，ZDI 早在 2026 年 3 月就向 Telegram 报告了贴纸处理代码中的漏洞。Telegram 当时认为，服务端会对贴纸进行检查，能够在客户端播放之前过滤存在问题的内容，因此相关漏洞的实际风险受到限制。

这一判断也影响了漏洞的严重性评级。据报道，ZDI 随后将该问题的评分从 9.8 下调至 7.0。

但 ZDI 研究人员 Michael DePlante 认为，即使服务端存在过滤机制，客户端中存在缺陷的代码依然值得关注。

根据公开报道，双方此后围绕漏洞验证、利用链披露及修复问题进行了多轮沟通。ZDI 于 10 月 15 日发布了相关安全公告。

而 Aziz 的研究则进一步将问题指向服务端校验机制本身。

他的演讲摘要称，研究人员发现了 Telegram 在贴纸分发和校验逻辑中的其他缺陷，并通过漏洞组合，使原本应当受到服务端检查限制的输入进入存在问题的客户端处理流程，最终声称在 iOS 版 Telegram 上实现了代码执行。

如果这一攻击链能够得到完整验证，它所揭示的问题就不只是某个动画解析组件存在内存漏洞，而是服务端安全检查与客户端自身安全之间可能存在的防护缺口。

当然，现阶段尚不能仅凭演讲摘要判断其具体绕过方式、攻击前提及实际影响范围。相关结论仍需等待完整演讲内容或技术报告进一步确认。

三、研究人员如何寻找漏洞？LLM 辅助模糊测试值得关注

根据 Aziz 公布的演讲摘要，这项研究持续了约一年。研究人员首先对 rlottie 进行了模糊测试，并借助大语言模型（LLM）辅助研究过程。

模糊测试（Fuzzing）是一种常见的软件漏洞挖掘技术：研究人员持续向目标程序输入大量经过构造或变异的数据，观察程序是否出现崩溃、异常行为或其他违反预期的结果。

在此次研究中，研究人员称通过这一过程发现了多个与内存破坏有关的问题，涉及 Telegram 的 iOS、Android 和桌面客户端。

此后，研究人员又继续分析贴纸的分发与校验逻辑，尝试将不同类型的缺陷组合起来。

从研究路径来看，这项工作可以分为三个阶段：

1. 发现解析层漏洞：对动画处理组件进行模糊测试，寻找内存安全问题。
2. 分析客户端与服务端的交互：研究贴纸的分发、检查及客户端处理流程，寻找可能影响安全边界的逻辑缺陷。
3. 尝试构建漏洞利用链：将不同缺陷组合，研究能否突破现有防护并进一步实现代码执行。

这里值得注意的是，发现一个内存破坏漏洞，并不等于已经获得代码执行能力；发现多个漏洞，也不意味着它们必然能够串联成功。

从单个崩溃到稳定利用，通常还需要解决具体的利用条件、内存布局及目标环境限制等问题。此次研究的完整技术细节尚未公开，暂时无法判断其具体利用难度和适用范围。

四、真正值得讨论的，是客户端与服务端之间的信任边界

这起事件引出了一个更具普遍性的问题：如果客户端存在安全缺陷，依靠服务端过滤恶意输入，能否作为长期有效的安全措施？

服务端校验当然有价值。通过限制输入格式、过滤异常数据，可以减少恶意内容到达客户端的机会。

但服务端过滤并不意味着客户端就可以忽略输入验证。

一旦过滤规则存在遗漏，或者不同客户端、不同处理路径之间存在差异，原本预期不会进入客户端的数据就可能触发潜在漏洞。

而且，客户端软件往往运行在用户设备上。服务端能够控制数据分发，并不代表它可以完全控制客户端对数据的解析和处理过程。

因此，更稳妥的设计应当同时考虑服务端与客户端两侧的防护：

• 服务端：对输入进行格式校验、异常内容过滤及必要的风险限制。
• 客户端：对外部输入实施严格验证，并持续修复底层解析组件的内存安全问题。
• 漏洞研究与验证：对过滤机制的有效性进行测试，不能仅凭存在一层检查就认定风险已被消除。

这些原则并不意味着 Telegram 的服务端过滤必然失效，而是说明服务端检查与客户端安全应当形成纵深防御，而不应简单地相互替代。

五、漏洞是否已修复？仍需等待进一步信息

截至目前，关于 Aziz 所称的新漏洞，公开摘要尚未提供足够信息来确认其 CVE 编号、具体受影响版本、补丁状态及完整利用条件。

相关报道还提及 Telegram Desktop 此前修复过一个特定动画贴纸样本引发的问题，但这并不能证明此次研究所涉及的全部漏洞或攻击链均已修复。

对于普通用户，现阶段可以采取以下措施：

1. 将 Telegram 更新至官方提供的最新版本。
2. 及时更新 iOS 系统及其他使用 Telegram 的设备。
3. 谨慎处理来自陌生人的消息、文件和其他内容。
4. 关注 Telegram 官方公告及后续研究报告，确认受影响版本与修复情况。

需要强调的是，零点击漏洞的潜在风险在于，某些攻击场景可能不需要用户主动点击恶意链接。但目前公开信息尚不足以确认此次新攻击链的全部触发条件，因此不宜直接断言所有用户都会受到同等程度的威胁。

一张贴纸究竟能否成为进入设备的入口，最终仍取决于漏洞的具体条件、攻击链的可行性，以及相关防护措施是否有效。

这项研究后续最值得关注的，是完整技术报告能否证明服务端校验机制如何被绕过、漏洞链在实际设备上的执行条件，以及 Telegram 将如何回应和处理相关问题。

对于安全研究人员而言，这也是一次值得持续跟进的客户端安全案例：真正需要验证的，不只是程序有没有漏洞，还有既有防护是否经得起完整攻击链的检验。这类涉及 rlottie 解析、模糊测试与零点击利用链的分析思路，在 云栈社区 的移动安全讨论中也有不少值得参考的案例与工具分享。