
截至 2026 年 5 月 25 日,这起事件可以概括为:APKPure 的 Telegram 12.6.5 下载页提供了一个包名为 org.telegram.messenger、标称开发者为 Telegram FZ-LLC、页面显示 「无病毒 / 无间谍软件 / 无恶意软件」 的 APK,但该 APK 的签名证书与 APKPure 上随后版本 12.7.3 的 Telegram 签名不一致;同一文件哈希已被 MalwareBazaar、ANY.RUN、Triage 等平台收录或分析,安全研究员 Eric Parker 也公开提示「APKPure 正在分发恶意 Telegram 副本」。


一、事件最早是如何被注意到的

事件在 2026 年 5 月 24 日左右进入安全社区视野。安全研究员 Eric Parker 在 X 上发布警示,称 APKPure 正在分发一个恶意版本的 Telegram;随后 Reddit、Telegram 社区、俄语安全媒体以及多个样本分析平台开始跟进。公开样本名为 Telegram_12.6.5_APKPure.apk,SHA-256 为 7d44e0009d251ae4983f5bf29f7d8aa9af668df88dba05a17a7a314f6780ceff。MalwareBazaar 页面显示该样本文件名、哈希、大小、文件类型以及首次收录时间:2026-05-24 07:03:32 UTC。

表面上看,这不是「有人做了一个仿冒 Telegram 网站」的普通钓鱼事件,而是更严重的第三方分发链问题。APKPure 的 12.6.5 页面自身显示该版本由 「Telegram FZ-LLC」 发布,更新时间为 2026 年 5 月 9 日,文件大小 47.8 MB,下载量 8K+,页面还给出 「可信任应用」 标识,并声明安全检查完成、无病毒、无间谍软件、无恶意软件。
真正的问题在于同一页面暴露出的技术矛盾:Telegram 12.6.5 的签名为 17eb76bfc3614c90068e8e5d45691ecf4f2c71a9,而 APKPure 当前 Telegram 12.7.3 页面显示的签名是 9723e5838612e9c7c08ca2c6573b6026d7a51f8f;12.6.5 的 SHA-256 正好与 MalwareBazaar 收录的疑似恶意样本一致。
二、为什么「签名不一致」是关键证据
Android 的安全模型要求 APK 在安装或更新前必须经过数字签名;对于一个已发布应用,应用签名密钥在应用生命周期内通常不应变化,用户也只能用相同签名密钥签署的包进行正常更新。Google 的 Android 开发者文档明确说明,Android 要求所有 APK 在安装或更新前都必须用证书签名,并且应用签名密钥是安装到用户设备上的 APK 所使用的身份密钥。
因此,Telegram 12.6.5 与 12.7.3 在 APKPure 页面上表现为同一包名 org.telegram.messenger,但签名不同,这不是一个小版本更新差异,而是身份链断裂。它意味着 12.6.5 并不是由与正常 Telegram Android 版本相同的私钥签出来的包。更直白地说,这更像是「拿 Telegram 重新打包、注入额外代码、再用攻击者或第三方私钥重新签名」的结果,而不是 Telegram 官方正常构建链产物。
这一点也能解释为什么它未必会感染所有用户:如果设备上已经安装了官方签名的 Telegram,Android 正常情况下不会允许一个签名不同但包名相同的 APK 直接覆盖更新;但如果用户是首次安装、卸载后重装,或在没有 Google Play 的设备上依赖第三方 APK 源安装,就可能安装上这个被重新签名的版本。一旦用户登录 Telegram,恶意代码就在「Telegram 自身进程和权限上下文」中运行,读取聊天缓存、媒体、联系人等数据的难度就显著降低。
三、样本与恶意行为证据链
目前公开证据可分为三层。
第一层是 APKPure 页面与样本库的哈希闭环。APKPure 的 Telegram 12.6.5 页面显示 SHA-256 为 7d44e0009d251ae4983f5bf29f7d8aa9af668df88dba05a17a7a314f6780ceff,MalwareBazaar 收录的 Telegram_12.6.5_APKPure.apk 也是同一 SHA-256,文件大小也对应 50,159,716 字节,即约 47.8 MB。
第二层是第三方分析平台结论。ANY.RUN 对同一 SHA-256 的报告给出了 「Malicious activity」 判定;Recorded Future Triage 对该样本给出 7/10 分,标签包括 Android、defense evasion、discovery,并记录了检查 Android 模拟器相关管道、获取 wake lock、查询活动数据网络等行为。
第三层是静态分析与 C2 线索。VPNrevie.ws 的分析称,该 APK 包含一个名为 DataCollector 的类,会收集消息、媒体、联系人、位置等数据,并向 38.190.225.166 下的 /api/collect、/api/collect_batch、/api/config、/api/image、/api/doc、/api/media、/api/avatar 等接口上传。SecurityLab 的报道也提到,沙箱中 org.telegram.messenger 进程曾访问 38.190.225.166,但同时谨慎指出,公开沙箱数据尚不能直接证明网络请求中已经包含用户全部聊天内容。
这里需要区分「高可信恶意重打包」与「全部数据外传已被完全公开证明」。从签名不一致、哈希入库、沙箱恶意判定、C2 接口、DataCollector 类名与收集逻辑来看,该 APK 被恶意重打包的可信度很高;但「所有对话都已被实际上传」的说法,目前更多来自研究者和后续分析推断,公开沙箱报告本身还没有完整展示外传 payload 的明文内容。
四、事件可能的攻击链
最合理的攻击链是:攻击者基于 Telegram Android 官方或近似官方版本进行重打包,在 APK 内新增 DataCollector 等恶意代码或额外 DEX,再使用非 Telegram 官方证书重新签名,最后让该包进入 APKPure 的 Telegram 12.6.5 分发页面。APKPure 页面仍把它包装成 Telegram FZ-LLC 发布的版本,并给出 「可信任应用」 与安全扫描通过提示。
这种方式的隐蔽性来自两点。第一,Telegram 本身需要联系人、文件、媒体、通知、位置等权限时并不罕见,恶意代码可以藏在「看起来合理」的权限集合后面。第二,恶意代码运行在 Telegram 应用自身上下文中,用户登录后,它不需要像普通外部木马那样跨应用突破沙箱,就能接触 Telegram 客户端本地保存或同步下来的数据。
这类攻击尤其适合针对无法或不愿使用 Google Play 的用户:例如部分地区用户、没有 Google Mobile Services 的设备用户、习惯从 APKPure/类似镜像站下载旧版本 APK 的用户,以及出于功能限制原因主动寻找「官网外版本」的用户。Telegram 官方实际上提供了 Android 直链下载和 Google Play 下载,并强调其应用支持可验证构建;这意味着在 Telegram 这个案例中,绕过官方渠道下载第三方镜像 APK 本身就扩大了供应链攻击面。
五、为什么 APKPure 的安全标识失效了

APKPure 的 12.6.5 页面同时出现了几个互相矛盾的信号:它显示 「可信任应用」,显示 「安全检查已完成」,显示 「无病毒 / 无间谍软件 / 无恶意软件」,又显示该版本签名与 12.7.3 签名不同,还显示 12.6.5 的 SHA-256 与 MalwareBazaar 样本一致。
这说明 APKPure 的「安全检查」更像是依赖杀软扫描、元数据检查或自动化安全报告,而不是严格执行「同一包名、同一官方发布者、同一签名链」的供应链完整性校验。事实上,APKPure 当前 12.7.3 页面仍显示 0/60、无病毒 / 无间谍软件 / 无恶意软件;但 12.6.5 的页面也出现了类似安全承诺,这说明「0 检出」或「平台已验证」不能等价于「来源可信」。
这也是移动安全中长期存在的问题:杀软多引擎扫描对于新样本、低分发样本、重打包但行为延迟触发的样本,常常存在时间窗口。MalwareBazaar 页面显示该样本当时 vendor detections 为 5;VPNrevie.ws 也提到在其写作时 VirusTotal 上只有 AhnLab 检出该恶意 APK,而 MalwareBazaar 上只有 FileScan 和 Incinerator 将其归为危险。
六、APKPure 不是第一次出现相关信任危机
这起事件并非 APKPure 第一次与 Android 恶意分发风险联系在一起。2021 年,Kaspersky 与 Doctor Web 曾披露 APKPure 官方客户端 3.17.18 被植入恶意模块,能够下载木马;Kaspersky 称 APKPure 后续发布 3.17.19 修复了该问题。
2025 年 10 月,Doctor Web 又披露 Android.Backdoor.Baohuo.1.origin 被植入恶意修改版 Telegram X;其报告明确提到,恶意修改版 Telegram X 曾通过 APKPure 等第三方应用目录分发,并且在 APKPure 中以真实开发者名义发布,但数字签名与原版不同。Doctor Web 估计该后门感染设备数超过 58,000。
这两个历史事件让 2026 年的 Telegram 12.6.5 事件更值得重视:问题不只是某个单一 APK 文件,而是第三方应用目录在「来源证明、签名连续性、开发者身份验证、旧版本分发治理」上的系统性薄弱。
七、影响范围与风险评估
对普通用户来说,最大风险是 Telegram 账号与隐私数据暴露。若用户安装并登录了该 12.6.5 版本,恶意代码可能接触聊天记录、媒体文件、联系人、SIM 信息、位置数据以及账号相关状态。即使端到端加密的 Secret Chat 在协议层有保护,客户端一旦被替换成恶意版本,攻击者仍可能从终端侧读取用户已经解密并展示或缓存的数据。相关收集范围来自公开逆向分析与报道,但具体每台设备实际外传了哪些字段,需要依赖设备取证和网络日志确认。
对组织来说,风险更高。Telegram 常被用于威胁情报协作、灰产监控、加密货币社群、媒体联络、跨境通信和内部小组沟通。如果情报人员、记者、开发者或运维人员在测试设备或主力设备上安装了该 APK,泄露的不只是个人聊天,还可能包括频道访问记录、联系人图谱、下载的样本、截图、文档、群组关系和二次认证线索。
目前公开可量化的一个指标是 APKPure 页面显示 12.6.5 下载量 8K+,但这不能直接等同于感染数。下载量可能包含重复下载、失败下载、研究人员下载、未安装下载,也可能低估通过缓存、镜像、APKPure 客户端或其他渠道继续传播的数量。
八、用户与企业应如何处置
如果用户在 2026 年 5 月 9 日之后从 APKPure 安装或更新过 Telegram 12.6.5,应立即卸载该版本,并从 Google Play 或 telegram.org 重新安装官方版本。Telegram 官方 Android 页面提供直接下载与 Google Play 下载入口,并说明其应用支持可验证构建。
处置时不应只「覆盖安装」。由于签名不一致,官方包与恶意重签包之间可能无法正常互相更新;更稳妥做法是先备份必要资料,卸载可疑包,重新安装官方版本,然后在 Telegram 设置中检查所有活动会话,结束不认识的设备,启用或重置两步验证密码。SecurityLab 也建议安装过 APKPure 12.6.5 的用户删除可疑版本、安装可信来源版本、检查活动会话并开启两步验证。
企业侧应在 MDM、EDR、DNS、代理和移动威胁防护系统中排查以下指标:包名 org.telegram.messenger,版本 12.6.5,构建 66689,文件 SHA-256 7d44e0009d251ae4983f5bf29f7d8aa9af668df88dba05a17a7a314f6780ceff,SHA-1 d0953b36a6e6e09fbd7d93c07921ab2eecaf23b7,MD5 78336a1c63ba008af99fd984ef8f2775,异常签名 17eb76bfc3614c90068e8e5d45691ecf4f2c71a9,以及访问 38.190.225.166 和 /api/collect、/api/collect_batch、/api/config 等路径的网络行为。
九、事件结论
这起事件的本质是一次第三方 APK 分发链的信任失败。Telegram 官方构建链目前没有公开证据显示被攻破;相反,签名不一致强烈指向「第三方重打包后上架或被分发」。APKPure 页面本身提供了最关键的反证:它既声称该版本可信,又展示了与正常 Telegram 版本不同的签名,还给出了与公开恶意样本库一致的哈希。
对用户来说,教训是不要把「知名 APK 站」「页面显示 Trusted」「多引擎 0 检出」当成等价于官方来源。对平台来说,教训更明确:第三方应用商店必须把签名连续性、官方证书指纹、开发者身份和版本来源作为分发前置校验,而不是仅靠文件扫描与页面标签。对安全团队来说,这类事件应被归类为移动端供应链风险,而不是普通仿冒 App 风险,因为它利用的是用户对 APKPure 这类分发平台的既有信任。
夜雨聆风