文章总结： 2026年3月Apifox发生供应链投毒事件，攻击者篡改CDN脚本利用Electron架构漏洞窃取SSH密钥与Git凭证。文章剖析了攻击技术细节与恶意基础设施，指出官方在沙箱配置与应急响应上的不足，提出了更新软件、轮换凭证及封锁恶意域名等处置建议，强调需加强对开发工具环境的安全管控以防范此类风险。 综合评分： 89 文章分类： 供应链安全,安全大事件,漏洞分析,应急响应,恶意软件

Apifox被投毒：SSH密钥、Git凭证是如何在不知不觉中被偷走的

AI小智 AI小智

零知实验室

2026年3月25日 14:17 山东

2026年3月4日，一段代码悄悄出现在一个CDN服务器上。

没有公告，没有警报，没有任何提示。

那段代码，藏在一个叫做 apifox-app-event-tracking.min.js 的JavaScript文件里。文件大小，从原来的34KB，悄悄变成了77KB。

多出来的43KB，专门用来做一件事：偷走你的SSH密钥、Git凭证、命令行历史，然后把它们发到攻击者的服务器上。

这就是2026年3月爆发的Apifox供应链投毒事件。

一个开发者最信任的工具，成了最危险的入口

Apifox，中国最流行的API调试工具之一。

如果你是一名后端开发者，你大概率用过它，或者正在用它。它号称”Postman + Swagger + Mock + JMeter”的组合，基本上是国内开发团队API工作流的标配。

正因为这样，它成了攻击者的最佳目标。

道理很简单：攻击者不需要攻破你的服务器防火墙，不需要找到你的代码漏洞，只需要在你每天打开的工具里，悄悄放一段脚本，就能把你的机器变成它的情报站。

安全界把这种攻击方式叫做”供应链投毒”。

攻击路径不是从你身上开始的，而是从你信任的那个工具开始的。

这次攻击，是怎么做到的

要理解这次攻击，先要理解Apifox的技术架构。

Apifox的桌面端，基于Electron框架开发。Electron是什么？简单说，它是一个”套壳浏览器”——把Web技术（HTML、JavaScript、CSS）打包成桌面应用的框架。VS Code、Notion、Slack……你熟悉的很多桌面应用都是用它做的。

Electron有一个先天特性：它的渲染进程，可以调用Node.js的API，直接访问本地文件系统、执行系统命令。这相当于给浏览器里运行的网页，开了一扇通往操作系统的门。

正常情况下，Electron提供了一个叫sandbox的安全参数，可以把这扇门关上。

但Apifox，没有严格启用sandbox。

这还不够。Apifox在启动时，还会做一件事：从自己的CDN服务器上，动态拉取一段JavaScript脚本，用于用户行为统计追踪。

这是一个常见操作，很多应用都这么做。问题在于：

如果这个CDN上的文件被替换了，会发生什么？

2026年3月4日，这个假设，变成了现实。

攻击者，将 cdn.apifox.com 上的追踪脚本，替换为一个恶意版本。

这个恶意脚本，会进一步从另一个仿冒域名 apifox.it.com（注意，这不是Apifox官方域名）加载第二阶段的攻击载荷。

一旦在目标机器上执行，它会：

• 收集 ~/.ssh/ 目录下的所有SSH私钥
• 读取 Git 配置文件，提取GitHub、GitLab等平台的Token
• 扫描 ~/.bash_history、~/.zsh_history，寻找命令行历史中泄露的密码
• 枚举当前运行的进程列表，分析目标的开发环境
• 将上述数据，打包上传到 apifox.it.com/event/0/log

攻击者的目标，不是你的C盘文件，也不是你的照片视频——他们要的，是能帮他们进入你公司内网的凭证。

一把SSH私钥，可以登录生产服务器。一个GitHub Token，可以拉取私有代码仓库，甚至推送恶意代码。

这就是这次攻击的可怕之处：它的终点，不是你个人的电脑，而是你背后的那整家公司。

攻击者留下的痕迹

安全研究人员在分析这次事件时，整理出了一批恶意域名，这些是攻击者的基础设施：

• apifox.it.com — 仿冒Apifox官方的核心C2服务器
• cdn.openroute.dev — 用于分发第二阶段恶意载荷
• upgrade.feishu.it.com — 仿冒飞书，伪装成升级提示
• ns.feishu.it.com — 仿冒飞书DNS服务
• system.toshinkyo.or.jp — 疑似被黑的日本网站，充当跳板

注意几个细节。

apifox.it.com——乍一看像是Apifox的官方子域名，但it.com是一个公开注册的第三方域名服务商，任何人都可以注册。攻击者就是靠这个视觉欺骗，绕过了普通用户和部分安全工具的检查。

还有飞书。飞书是国内大量开发团队的协作工具，攻击者专门仿冒了飞书域名，说明他们对目标用户群体的工作习惯有深刻了解：用Apifox的人，大概率也在用飞书。

为什么这件事值得所有开发者认真对待

你可能觉得：这不就是又一个安全事件吗？跑去更新一下版本就好了。

但我想说，这件事的问题，比”及时更新”要深得多。

第一个问题：你怎么知道你安装的是官方版本？

Apifox有一批用户，是从第三方渠道下载的——镜像站、百度网盘分享、各种”懒人包”。那些版本，有多少是干净的？没有人知道。

这次攻击发生在CDN层，影响的是从官方渠道正常使用的用户。那些从非官方渠道下载的版本，风险只会更高，不会更低。

第二个问题：你的机器，被感染了多久？

攻击从2026年3月4日开始，官方2.8.19版本修复这个问题，距今已过去数周。在这段时间里，你的SSH密钥、Git Token、命令行历史，已经被上传到哪里了？

密钥泄露不像账号密码，你无法简单地”改密码”。泄露的SSH私钥，可能已经被用于横向移动，进入你公司的内网。泄露的GitHub Token，可能已经被用来偷走代码，或者在你的仓库里种下了后门。

第三个问题：开发者群体，为什么成了攻击者的首选目标？

回答这个问题，你需要想清楚一件事：开发者的机器上，有什么？

有连接生产环境的SSH密钥，有访问代码仓库的Token，有公司内网的VPN配置，有测试环境的数据库密码……

开发者的笔记本，是整个企业安全体系里，最脆弱的那个环节，但同时又连接着最核心的资源。

攻击者早就知道这件事。

Apifox的问题，不只是这一次

Apifox这次暴露的问题，有两个层面。

一是架构决策问题：在Electron应用里不启用sandbox，同时又动态加载远程脚本——这是两个已知的高风险组合，行业里早有警示。Electron官方文档明确建议：所有处理不受信任内容的渲染进程，都应该启用sandbox。

二是应急响应问题：攻击从3月4日开始，官方发现并修复的时间，以及是否主动通知用户，目前没有公开的透明披露。

对比一下行业标准：2020年的SolarWinds供应链攻击发生后，微软、Mandiant等公司在48小时内发布了详细的技术分析，用户在事件确认后的第一时间就收到了通知。

一家面向开发者的工具公司，当它的产品成为攻击者的载体时，它有责任让受影响的用户知道发生了什么，并给出明确的排查步骤。

沉默，不是一种负责任的态度。

如果你现在正在用Apifox，这是你需要做的事

立即更新版本。 官方2.8.19及以上版本已将相关脚本内置到安装包中，不再动态加载，从根本上消除了这个攻击向量。

排查是否已被感染。 重点检查：

• 2026年3月4日至今，是否有和 apifox.it.com、cdn.openroute.dev 的网络通信记录
• 系统进程中是否存在异常的网络连接
• 如果有条件，用EDR工具扫描机器

立即轮换凭证。 如果你在受影响的时间段内使用了Apifox，建议：

• 重新生成所有SSH密钥，并更新到所有服务器上
• 吊销并重新生成GitHub/GitLab的Personal Access Token
• 检查公司内网，看是否有异常的登录记录

在防火墙和DNS层封锁上述恶意域名。 如果你有权限操作公司防火墙，把以下域名加入黑名单：

• apifox.it.com
• cdn.openroute.dev
• upgrade.feishu.it.com

供应链攻击，是这个时代最难防的攻击

SolarWinds、XZ Utils、npm eslint-config-prettier……近几年，供应链攻击的案例越来越多，目标越来越精准，手法越来越隐蔽。

它们有一个共同的逻辑：攻击者不突破你的防御，而是从你已经信任的东西开始。

你信任Apifox，所以你不会怀疑它发出的网络请求。你信任npm包，所以你不会审计每一行代码。你信任GitHub Action，所以你不会怀疑CI流水线的行为。

在这种攻击面前，”保持警惕”是苍白的。没有人能在使用每一个工具之前都审计它的源码。

但有一些事情，是开发者和企业可以做到的：

最小权限原则。 开发机器不应该直接连接生产环境。SSH密钥应该分级管理，不同环境使用不同密钥。

网络流量监控。 开发环境应该有基础的出站流量监控，能够发现异常的数据上传行为。

软件来源管控。 企业的开发工具，应该从统一的、经过审核的内部镜像分发，而不是让每个人自己去网上下载。

定期轮换凭证。 SSH密钥和API Token，不是”设置一次用到死”的东西。定期轮换，是降低泄露影响半径的最有效手段之一。

最后，我想说的是

这篇文章写完，我回头看了一下这次事件的时间线。

攻击开始于3月4日。

到今天，我们才开始大规模讨论它。

有多少人，在这段时间里，每天打开Apifox，毫不知情地上班、写代码、调接口——然后在某个夜晚，把自己公司的SSH私钥送到了攻击者手里？

这不是Apifox一家的问题，也不是某几个开发者的问题。

这是整个行业，对”开发工具安全”这件事，关注还远远不够的问题。

我们花了大量时间讨论应用安全、API安全、数据安全，但对开发者每天使用的这些工具，却几乎没有系统性的安全审查和监控机制。

开发者，是整个软件供应链的起点。

保护好开发者的工作环境，才是真正的从源头开始。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：零知实验室 AI小智 AI小智《Apifox被投毒：SSH密钥、Git凭证是如何在不知不觉中被偷走的》