Telegram Desktop 漏洞让一次点击变成文件窃取
Telegram Desktop 修复了一个高危漏洞,该漏洞可将一次外部链接点击变成任意本地文件窃取,并且在常见条件下可导致账户接管。该 Telegram Desktop 漏洞影响至 7.2.8 版本的发布版本,并已在 Windows 上得到确认。7.2.9 版本移除了易受攻击的功能,并改变了应用在进程间传递链接的方式。
此次攻击无需安装恶意软件、无需恶意可执行文件,也不需要受害者的 Telegram 密码。攻击链结合了 Telegram Desktop 内部的两个缺陷、群组自动下载功能以及浏览器重定向。成功的攻击者可使 Telegram 将受害者计算机中选定的文件上传到攻击者控制的群组。
安全研究员 BeakSec 在 2026 年 10 月 3 日公开披露了该攻击链;此前其已于 6 月 25 日通过 Zero Day Initiative 报告此问题。Telegram 已于 9 月 16 日独立移除了易受攻击的代码,7.2.9 版本于次日发布。CVE-2026-107181 于 10 月 7 日获分配编号。
核心问题不止是遗漏了一个转义字符。Telegram 将一个面向本地使用的发布工具视为可信,却意外让外部提供的链接能够访问它。一项便利功能跨越了原始设计从未预期会触及的安全边界。
该 Telegram Desktop 漏洞在公开前已被修复
眼下的消息令人安心:Telegram Desktop 7.2.9 在技术证明公开前就已封堵了这一已演示的攻击链。
研究员的技术披露指出,Telegram Desktop 7.2.8 及更早版本受到影响。测试覆盖了从 6.9.3 到 7.2.8 的 Windows 版本。研究员并未声称所有 Telegram 客户端或操作系统都存在漏洞。
该漏洞获得 CVE-2026-107181 编号,CVSS 3.1 评分为 8.1,属于高危范围。其公开的攻击向量反映出可远程触达、攻击复杂度低,但需要用户交互。攻击者需要诱导受害者点击链接,但不需要预先拥有 Telegram 权限。
其实际影响是任意文件读取。这意味着可诱导易受攻击的应用打开由攻击者选择的本地文件。在本案中,Telegram 还会将选中的文件发送至攻击者控制的 Telegram 聊天中。
这一能力可能暴露远不止 Telegram 数据。研究员列举的潜在目标包括 SSH 私钥、浏览器密码库、云端凭据,以及包含 API token 的配置文件。成功窃取仍取决于攻击者是否知道或能预测有价值的文件路径。
演示的账户接管攻击针对 Telegram Desktop tdata 目录中的三个文件。这些文件共同包含或索引了重建已授权 Telegram 会话所需的材料。攻击者可将恢复出的文件放入一个全新的安装环境中,并打开受害者的账户。
这属于会话窃取,而非密码恢复。会话授权会告诉 Telegram 的服务器,某个客户端已经通过身份验证。因此,在演示的接管中,持有有效的会话材料即可绕过对账户密码的需求。
当受害者未设置本地 Telegram 密码时,攻击最容易直接奏效。这与 Telegram 的云端密码或两步验证不同。本地密码用于保护桌面客户端在该计算机上存储的数据。
在没有本地密码时,Telegram 会从空输入和已存储的 salt 派生其本地包装密钥。因此,研究员在窃取相关文件后可以重建该密钥。强本地密码会使被窃取的加密数据更难被利用。
不过,本地密码并不能修复文件读取漏洞。易受攻击的客户端仍可上传攻击者选定的文件。密码仅保护 Telegram 的会话材料免遭直接复用。
Telegram 的修复提交移除了旧版辅助工具,并强化了本地消息格式。该公开提交的标题是“Remove legacy interpret path helper”,淡化了其安全影响。
随附的变更日志也没有描述账户接管漏洞。根据研究员的时间线,7.2.9 版本仅提到一项渲染修复。因此,阅读常规发布说明的用户几乎不会意识到更新已修复严重的安全缺陷。
这一低调的修补过程造成了本报道中不同寻常的时间关系。易受攻击的行为在公开证明出现前就已消失,但许多安装环境并不会立即更新。披露将风险转向仍在使用旧版本的用户。
一个分号将一条链接变成多条命令
核心失败在于边界处理错误:Telegram 将 URL 序列化为文本时,没有转义用于分隔内部命令的字符。
Telegram Desktop 通常只允许一个运行实例。当操作系统为 tg:// 链接启动另一个实例时,第二个进程会将链接转发给现有进程。它通过进程间通信(IPC)进行通信,使本地程序能够交换数据。
Telegram 的 IPC 格式将每条指令表示为命令、参数和一个分号。普通链接会变成以该分隔符结尾的 OPEN: 记录。接收进程会在每个分号处拆分传入文本。
这一格式仅在命令参数绝不会包含未转义分号的情况下才安全。Telegram 没有强制这一条件。精心构造的 URL 可包含自己的分隔符,使接收端将一个 URL 解释为多条内部命令。
这属于记录分隔符注入。问题类似于命令注入,不过注入值进入的是 Telegram 自身受限的命令语言。攻击者并非直接获得一个不受限制的操作系统 shell。
大多数受支持的内部命令影响有限。其中一个可显示应用,另一个可关闭应用。危险命令是另一条 OPEN: 记录,因为它接受 URL 时不限制其 scheme。
这一行为暴露了名为 interpret: 的内部 URI scheme。URI scheme 是告知软件如何处理地址的前缀。常见示例包括 https:、mailto:,以及 Telegram 注册的 tg: scheme。
Telegram 未向操作系统注册 interpret:。它仅存在于桌面客户端内部,用于支持 Telegram 的版本发布流程。内部脚本使用它读取文本指令文件,并将指定构建版本上传到 Telegram 频道。
该旧版辅助工具预期接收描述目标频道、本地文件和可选说明文字的字段。它还可以检查 from: 字段中列出的账户标识符。然而,只有在指令文件包含该字段时才会执行检查。
攻击者可以完全省略 from:。Telegram 随后会跳过账户比对,继续处理文件。更重要的是,该辅助工具读取并发送选定的本地文件前无需任何确认。
在可信的本地发布脚本中使用时,这一行为的威胁模型有限。任何能够在本地调用它的人,很可能已能访问该机器。IPC 注入改变了这一假设,因为它使 interpret: 能够通过外部输入访问。
浏览器完成了这座桥梁。在 Telegram 聊天中直接处理的 tg:// 链接不会经过易受攻击的 socket。但普通 HTTPS 链接会在系统浏览器中打开。
攻击者控制的网站可对该 HTTPS 请求返回重定向,跳转至精心构造的 tg:// URL。操作系统随后会启动另一个 Telegram 进程。该进程将未转义的 URL 转发给现有实例,注入的记录随即成为独立命令。
某些浏览器或操作系统配置可能会在打开 Telegram 前显示确认提示。该提示增加了操作阻力,但不会解释隐藏的命令序列。可见的 HTTPS 地址也可能看似与最终的 Telegram URI 毫无关联。
因此,该缺陷横跨多个组件,而非存在于某个引人注目的单一函数中。URL 解析、进程交接、基于分隔符的协议以及受信任的发布辅助工具,在各自局部范围内都按设计运行;它们的组合却造成了漏洞利用。
这一模式对开发者而言很重要。内部接口通常得到较少的防御性审查,因为设计者假定只有可信代码能够访问它们。一旦其他功能创建了意外路径,这些假设可能会一同崩塌。
自动下载让文件窃取路径变得可预测
该漏洞利用需要受害者计算机上存在一份指令文件,而 Telegram 默认的群组下载行为会将其放在已知位置。
interpret: 辅助工具不接受直接嵌入精心构造链接中的全部攻击指令。它需要一个本地文本文件,用于描述目标聊天和待上传文件。因此,攻击者需要先将该指令文件放到目标计算机上。
Telegram 群组提供了投递渠道。根据披露内容,在测试的默认配置下,Telegram Desktop 会自动下载不超过 8 MiB 的群组文件。频道广播下载的行为不同,因此概念验证使用了超级群组。
攻击者首先创建一个超级群组并将目标加入其中。Telegram 的默认隐私配置可能允许这一操作,无需单独批准。攻击者随后在群组中发布经过特殊准备的文本文件。
当受害者打开该群组时,Telegram 会自动保存这些附件。在 Windows 上,文件会落在用户的 Downloads\Telegram Desktop 目录下。除本地存在同名冲突外,发送者可控制每个附件的原始文件名。
可预测性至关重要。攻击者通常不会知道目标的 Windows 用户名,因此绝对路径并不可靠。不过,Telegram 的辅助工具也接受相对路径。
这些相对路径会从 Telegram Desktop 的应用数据目录开始解析。研究员可从该起点向上遍历至用户主目录,再进入已知的下载目录。精心构造的路径无需包含用户名。
每份指令文件都会指定一个本地目标,以及攻击者的超级群组作为目的地。Telegram 的辅助工具每份指令文档只能处理一个最终的 file: 值。攻击者可通过提供多份文档来绕过这一限制。
精心构造的链接同样携带多条注入的 OPEN:interpret: 记录。每条记录指向不同的已下载指令文件。因此,一次点击可能触发多次上传。
为实现账户接管,概念验证针对 Telegram tdata 文件夹中的三条可预测路径。第一份文件存储 salt 和一个加密的数据加密密钥。第二份保存加密的 MTProto 授权数据,第三份则索引已存储的账户数据。
MTProto 是 Telegram 的客户端—服务器协议。其授权数据可让已获批准的桌面客户端在不重复完整登录流程的情况下识别自身。即使这些文件不包含可读密码,它们依然具有价值。
研究人员报告称,相关文件夹名称在默认安装中保持一致。其中一个文件夹名称源自 Telegram 的默认数据名称,而不是随机生成的、特定于安装的值。这消除了远程定向攻击的另一项障碍。
点击后,注入的辅助命令会打开这三个文件,并将其发送到攻击者的群组。Telegram 在该内部发布路径中不会显示文件上传确认提示。攻击者随后可以在另一台计算机上重建该目录。
当攻击者已知文件路径时,同一原语也可用于针对无关文件。开发者经常将云令牌、软件包凭据、签名密钥和 SSH 材料保存在常规位置。桌面应用程序也会将有价值的数据库保存在可预测的配置文件目录下。
不过,“任何文件”需要谨慎解读。该漏洞使 Telegram 进程能够访问攻击者可以识别路径上的可读文件。操作系统权限仍然适用,用户名、自定义目录和文件名也依然存在不确定性。
攻击还需要满足若干环境条件。Telegram Desktop 必须正在运行,存在漏洞的版本必须处理重定向链接,并且指令附件必须能到达可预测的本地路径。随后,受害者还必须点击攻击者的链接。
这些要求意味着这是一次单击攻击,而非零点击攻击。自动下载在无需点击附件的情况下完成了部分准备工作,但仍然需要浏览器导航。准确描述这种区别,有助于组织在不淡化漏洞的前提下评估暴露风险。
便利性与信任在 Telegram Desktop 内部发生碰撞
更深层的安全权衡并非加密与可用性之间的取舍,而是受信任自动化与暴露于不受信任输入之间的冲突。
存在漏洞的 interpret: 功能服务于一个狭窄的运营目的。Telegram 的发布流程需要将构建产物和更新日志文本上传到某个频道。自动化这一任务减少了维护人员的重复工作。
然而,该辅助工具拥有相当大的权限。它可以读取本地路径,并通过已认证的 Telegram 账户发送结果。它不会请求确认,因为反复提示会破坏其自动化目的。
只要入口保持私有且仅限本地,这种设计仍然可以是合理的。当普通链接处理触达同一路径时,问题便出现了。为公共 URL 构建的输入边界继承了内部发布工具的权限。
Telegram Desktop 漏洞说明,“内部”不能替代授权。代码变更、协议处理程序、插件和进程桥接都可能使私有功能从意外上下文中变得可访问。每项特权操作都需要独立验证。
IPC 解析器还信任了从标点符号中推断出的结构。基于分隔符的格式可以是安全的,但在序列化前,数据必须对保留字符进行转义。接收端只能在识别出真正的记录边界后再对其解码。
Telegram 的修复同时处理了链条两端。它在通过套接字发送值之前对记录分隔符进行百分号转义,并在拆分记录后再解码。URL 中的分号不再能够创建另一条命令边界。
补丁还完全移除了 interpret: 方案及其发送路径辅助工具。这项变更减少了攻击面,而不是通过再增加一个条件检查来保留特权旧功能。在未使用的权限周围添加过滤器,通常不如直接移除它更安全。
额外保护措施阻止了危险的命令组合。更新后的代码会在同一连接包含 OPEN: 记录时跳过 CMD: 和 CTRL: 记录;在连接中出现非本地 URL 后,它还会拒绝本地文件路径。
这些层次很重要,因为安全补丁可能遗漏替代路径。转义分号解决了已展示的注入问题。移除特权方案则消除了最具破坏性的目标,即使日后再出现其他解析器缺陷也是如此。
CVE 记录将该问题归类为输出中未正确中和分隔符。这一描述捕捉到了首个缺陷,但未能完整体现其影响。账户接管还需要第二种权限更高的行为。
这种差异解释了为何自动化漏洞标签可能低估一条攻击链。单独审查时,解析错误似乎影响有限;但当注入命令能够抵达可上传本地机密的辅助工具时,其严重性就会改变。
该问题也挑战了人们对桌面消息安全的一项常见假设。用户通常关注传输加密、恶意附件和钓鱼凭据。而在这里,一次精心构造的导航之后,Telegram 本身成了文件传输机制。
无需执行任何可执行附件。因此,传统恶意软件扫描可能只会看到普通文本文件和一个常规 HTTPS 链接。关键行为是通过合法的 Telegram 功能发生的,这些功能使用的是用户现有的文件系统权限。
企业控制措施应考虑这类应用层风险。受管设备需要实施最低版本要求,而不仅仅是覆盖杀毒软件。安全团队还应盘点能够访问本地文档、浏览器配置文件或开发者凭据的消息客户端。
对开发者而言,相应的教训同样适用于深度链接、本地套接字、自动化钩子和命令行桥接。它们之间的每次转换都应保留原始输入是本地、远程、受信任还是经用户批准这一信息。
数据跨越这些边界时,权限不应悄然扩大。浏览器提供的 URL 不应仅仅因为最终都会变成字符串,就获得发布工程师本地脚本的权限。
补丁修复了攻击链,但公开证据存在局限
该披露提供了可信且有代码支持的证明,但并未证实存在大规模利用,也未证明所有平台上的暴露情况完全相同。
研究人员在 Windows 上确认了该漏洞利用,并记录了相关 Telegram 源代码。攻击链包括可预测的 Windows 路径,以及在 6.9.3 至 7.2.8 版本中观察到的行为。这为测试环境提供了有力证据。
但这并不能证明每个受支持的操作系统都具有完全相同的行为。文件位置、浏览器提示、URI 处理、沙箱和下载默认设置在 Windows、macOS 与 Linux 之间各不相同。用户不应超出已披露的测试范围进行泛化。
声称用户文件可能被窃取的标题也存在技术限制。Telegram 只能访问客户端操作系统账户可读取的文件。攻击者还需要可用的路径,或可靠地预测该路径的方法。
这些限制并不意味着漏洞影响轻微。许多有价值的文件位于常规位置,尤其是在开发者工作站上。演示中使用的 Telegram 会话路径在设计上就是可预测的。
账户接管还取决于本地密码状态。概念验证显示,在没有本地密码保护 Telegram 数据时,可以直接重建会话。强本地密码可以防止数据被窃后轻易解密。
Telegram 的云端两步验证未必能阻止已获授权桌面会话被复用。该控制措施保护的是认证事件,而漏洞针对的是认证后的会话材料。用户应区分这些防御层级。
另一个不确定性涉及现实世界中的滥用。公开材料没有提供补丁发布前已确认遭利用的证据。概念验证表明的是可行性,而非普遍性。
这一差异会影响事件响应。组织不应仅因安装了较旧版本的 Telegram 就假定已遭入侵;但在技术细节公开后仍处于易受攻击状态的系统,也不应被忽视。
披露时间线划定了明确的暴露边界。Telegram 于 2026 年 9 月 16 日提交修复,7.2.9 版本于 9 月 17 日发布。详细说明于 10 月 3 日公开,CVE 则在四天后发布。
尽管修复版软件已存在,攻击者在 10 月 3 日后获得了公开路线图。一旦防御者和攻击者都能研究同一条技术链,无法自动更新的系统便面临不断增加的风险。
Telegram 的公开代码库提供了验证修复的具体方式。研究人员指出的已修补代码行包含在 7.2.9 发布版本中。后续版本也应包含这一变更。
不过,版本号本身无法回答过去是否发生过利用。Telegram 账户持有者应检查活跃会话、意外加入的群组以及无法解释的上传。受管环境还应在条件允许时检查终端和代理记录。
从受害者账户发起的意外文件上传尤其值得关注。概念验证使用 Telegram 本身发送被窃数据。此类行为可能留下服务端或客户端可见的痕迹,尽管公开披露未提供完整的取证指南。
跳转到 tg:// 链接的陌生浏览器重定向也值得关注。来自未经请求的超级群组而下载的文本附件同样如此。两种信号单独出现都不能证明遭利用,但其组合与展示的准备和投递路径相符。
用户不应将删除可疑下载内容视为更新的替代方案。删除指令文件可以中断一次漏洞利用尝试,但不能修复解析器,也不能消除旧版辅助工具。
同样,禁用自动下载能够降低暴露风险,但不能关闭存在漏洞的代码。攻击者可能会找到其他方式,将指令文档放置到已知路径。版本 7.2.9 或更高版本仍然是决定性的控制措施。
Telegram 用户与安全团队接下来应关注什么
下一项检验在于易受攻击的安装是否会迅速消失、是否出现利用证据,以及 Telegram 是否会改善围绕低调修复的安全披露。
第一个信号是版本采用情况。个人用户应打开 Telegram Desktop 设置,并确认正在运行 7.2.9 或更高版本。组织应在所有允许使用 Telegram 的受管终端上强制执行这一基线。
如有可用版本,较新版本更为可取,因为其中包含相同修复以及后续维护。用户应通过 Telegram 的常规更新程序或经验证的分发渠道获取更新。非官方安装程序会带来无关的供应链风险。
任何无法立即更新的用户都应停止使用存在漏洞的桌面版本。仅关闭应用程序并非持久的企业控制措施,但它会移除公开 IPC 路径所需的运行实例。网页版或移动版使用不同的代码路径。
第二个信号是可信的利用报告。安全厂商、事件响应团队和 Telegram 本身可能会在将日志与公开概念验证进行比对后识别出攻击。已确认的案例会使这一事件从严重的设计失败转变为活跃事件。
在此类证据出现之前,报道应保留“可被利用”与“已被利用”之间的区别。已记录的攻击链支持紧急修补,但并不支持声称 Telegram 账户因这一特定漏洞而大规模遭入侵。
第三个信号是 Telegram 的披露实践。安全修复以克制的提交标题落地,而发布说明没有描述任何高严重性漏洞。在研究人员公开细节之前,用户几乎没有理由优先安装该更新。
协调披露并不总是允许立即公开技术细节。供应商有时会延后发布公告,以便在更新逐步覆盖期间保护用户。尽管如此,明确的安全通知仍可在不公开漏洞利用方法的前提下,推动用户安装更新。
Telegram 还可以进一步说明受影响的平台、遥测信息和检测建议。研究确认了 Windows 上的行为,而更广泛的平台暴露情况仍不明确。官方的影响范围信息将帮助安全团队避免既掉以轻心,也不必要地恐慌。
用户可通过多项辅助控制措施降低残余风险。启用“每次保存文件时询问保存位置”,避免群组附件自动落在可预测的路径中。当该设置符合你的通信需求时,可将群组添加权限限制为仅联系人。
还应为本地 Telegram 设置一个强密码。它无法阻止未修复客户端上的任意文件窃取,但能为本地存储的会话材料增加一层保护。避免重复使用账户密码或设备 PIN 码。
检查 Telegram 的活跃会话,并终止无法识别的条目。如果存在遭入侵的可能,请退出其他会话、更新客户端,然后重新进行身份验证。根据存在风险的文件,轮换可能泄露的开发者密钥、浏览器凭据或云端令牌。
组织应采取更进一步的措施。通过软件资产清单查询 Telegram Desktop 7.2.8 及以下版本,随后确认升级是否成功。检查异常的 Telegram 上传、可疑的群组邀请,以及通过 Telegram 协议链接启动浏览器的行为。
安全团队还应考虑该客户端能够读取哪些内容。开发者工作站可能存有 SSH 密钥、包注册表凭据、云配置和源代码机密。同一漏洞在自助终端或受到严格限制的端点上,后果会截然不同。
更广泛的教训应纳入应用评审。深层链接应比本地命令获得更低的信任,即使二者使用相同的解析器。只要操作会暴露数据,内部自动化端点就需要身份验证或明确的用户确认。
序列化的 IPC 消息应采用结构化格式,并进行严格的解析、转义和模式验证。当特权旧版处理程序的原始工作流已不再需要它们时,应将其淘汰。安全边界必须在最终的敏感操作处得到执行。
大多数读者无需复现漏洞利用过程,也无需检查 Telegram 的源代码。他们现在需要回答三个问题:桌面客户端是否为最新版本?它在披露后是否仍存在漏洞?可疑活动是否可能已导致敏感文件暴露?
先更新,再检查会话和近期群组活动。如果较旧的 Telegram Desktop 漏洞影响了一台存有重要凭据的设备,应将该事件视为可能的文件暴露,而不仅仅是消息账户风险。这样的响应与该漏洞实际能够触及的范围相符。



