post cover

APIFox 供应链投毒：你的开发机可能已经不是你的了

APIFox 供应链投毒：你的开发机可能已经不是你的了

3月末，国内主流API协作工具 APIFox 官方发布紧急预警，确认其公网SaaS版桌面客户端遭遇供应链投毒攻击。恶意代码通过CDN分发，潜伏时间长达18天（3月4日至3月22日），受影响用户数万名。

又是一次”低级失误”式的安全事件。又一次，没有黑客攻破谁，只是攻击者找到了一道敞开的门。

事件经过

攻击手法并不复杂，但很有效。

APIFox 桌面客户端基于 Electron 框架开发，运行时会动态加载一个 CDN 上的 JavaScript 文件：apifox-app-event-tracking.min.js。

3月4日起，攻击者篡改了这个文件——正常的文件大小约 34KB，被替换后膨胀到 77KB，注入了恶意代码。

客户端启动时，恶意脚本会从攻击者控制的域名 apifox[.]it[.]com（托管在日本AWS）动态加载攻击载荷，在特定条件下开始采集本机敏感数据。

恶意代码偷了什么

根据腾讯云安全团队的详细分析，恶意脚本会扫描并窃取以下内容：

数据类型文件路径
SSH 私钥~/.ssh/id_rsa 等
Git 凭证~/.git-credentials、GitHub/GitLab Personal Access Token
命令行历史~/.bash_history、~/.zsh_history
SSH 配置~/.ssh/config
Kubernetes 配置~/.kube/config
npm Token~/.npmrc
进程列表主机上运行的所有进程信息
主机身份主机名、用户名、MAC 地址等

这些数据经加密后上传至攻击者控制的服务器。攻击者拿到这些凭证后，可以横向移动——登录你的服务器、拉取你的私有代码仓库、控制你的K8s集群。

为什么说是”敞开的门”

这起事件的本质不是高超的黑客技术，而是 APIFox 桌面客户端的安全架构存在根本性缺陷：

  1. Electron 未启用 sandbox：渲染进程可以访问 Node.js API，等于给恶意代码开了系统级权限
  2. CDN 资源缺乏完整性校验：客户端加载外部 JS 文件时没有做签名/哈希校验，文件被篡改后客户端”照单全收”
  3. 桌面应用暴露了过大的攻击面：这让”升级桌面软件”从一个体验优化变成了安全刚需

影响范围

根据官方公告：

  • 受影响版本：APIFox 桌面客户端 < 2.8.19
  • 受影响时间：2026年3月4日至3月22日期间启动过应用的用户
  • 不受影响：SaaS Web 版用户、私有化部署版用户

这件事值得每个开发者警惕

表面上这又是一起”赶紧升级”的日常安全事件，但往深了想，有几个问题值得我们持续担忧：

1. 开发工具正在成为攻击跳板

APIFox、Postman、Swagger……这类工具运行在开发者本人的电脑上，而开发者的电脑上往往存着：生产服务器SSH密钥、GitHub/GitLab凭证、私有仓库Token、云服务AK/SK。拿下开发机，比直接打生产服务器容易十倍，回报却高得多。

攻击者显然深谙这一点。2026年3月，同期还发生了 LiteLLM 和 Context Hub 的大模型工具供应链投毒事件——大模型工具链正在成为新目标。

2. CDN/第三方资源是盲区

大多数桌面应用在加载外部资源时，没有做完整性校验。这不是APIFox一家的问题，是整个行业的通病。上一次 Claude Code 源码泄露，也是因为 source map 文件混入了 npm 包。第三方依赖的可信链，是一个长期被忽视的安全死角。

3. 供应链攻击的平均发现周期是”数月”

这次APIFox事件，攻击从3月4日持续到3月22日，直到3月25日官方才发公告。18天的窗口期里，数万名开发者的凭证可能已经泄露，而大多数人至今不知道自己的密钥是否被访问过。

如果你用过旧版APIFox桌面客户端，请立即操作

以下非可选，而是必须：

  1. 卸载APIFox桌面客户端，并清除 ~/Library/Application Support/apifox 等缓存目录
  2. 立即轮换所有SSH密钥：在服务器上移除旧的 authorized_keys，本地生成新密钥对
  3. 撤销所有Git Token：GitHub、GitLab、公司内网Git平台，全部重新生成
  4. 轮换npm Token和K8s凭证
  5. 修改命令行历史中暴露的所有密码、API Key和Token
  6. 升级到APIFox >= 2.8.19，并启用Electron的sandbox模式
  7. 通过防火墙阻断 apifox[.]it[.]com、cdn[.]openroute[.]dev 等恶意域名

写在最后

写这篇文章的时候，我其实有点不舒服。

不舒服不是因为APIFox”怎么会被攻击”——供应链攻击防不胜防，再怎么小心也不为过。不舒服是因为：这类事件的发生，本质上是因为开发工具在安全上长期”将就”。

Electron sandbox没开、CDN资源无校验、桌面应用攻击面大……这些问题不是APIFox独有的。国内外的开发工具，但凡带桌面客户端的，大多数都有类似的隐患。APIFox只是这次被选中了。

作为开发者，我们能做的事很有限：尽量用Web版而非桌面版、关注官方安全通告、对开发机上的密钥实行最小权限原则、定期轮换凭证。但工具侧的安全水位，最终还是需要工具厂商来兜底。

希望这次事件能让APIFox和其他开发工具厂商真正把安全当成基础设施来对待，而不是”出了事再打补丁”。

IOC指标（仅供安全排查参考）：恶意域名 apifox[.]it[.]com、C2服务器IP 13.192.121.27（日本AWS）、upgrade[.]feishu[.]it[.]com、cdn[.]openroute[.]dev。如发现访问记录，请立即按上述步骤处置。