文章总结： 2026年3月Apifox桌面客户端遭供应链投毒，攻击者篡改CDN上动态加载的JS脚本，因Electron沙箱未启用导致远程代码执行。攻击窃取SSH密钥、Git凭证等敏感信息并回传至伪装C2服务器。该事件暴露了开发工具信任链的脆弱性。受影响用户需立即升级客户端、全量轮换凭证并排查持久化后门，建议企业加强对开发环境的安全审计与防护。 综合评分： 89 文章分类： 安全大事件,供应链安全,漏洞分析,应急响应

Apifox 供应链投毒事件

原创

🅼🅰🆈 🅼🅰🆈

独眼情报

2026年3月26日 12:41 湖北

2026 年 3 月 25 日，安全社区 2Libra 用户「Path」发布漏洞预警，首次公开披露 Apifox 桌面客户端遭遇供应链投毒。随后，安全研究者「白帽酱」在 rce.moe 发布了完整逆向分析，「离别歌」在 leavesongs.com 发布了独立复盘，AUTOSEC.DEV 也发布了 Critical 级安全公告，多方交叉印证了事件细节。Apifox 官方随后通过微信公众号发布通告，确认公网 SaaS 版桌面客户端动态加载的一个外部 JavaScript 文件遭遇了恶意篡改，明确影响窗口为 2026 年 3 月 4 日至 3 月 22 日，共计 18 天，私有化版不受影响。Windows、macOS、Linux 三个平台的用户均在攻击范围内。

Apifox 总部位于广州，是一款定位为「Postman + Swagger + Mock + JMeter」四合一的 API 全生命周期管理工具。据 Tracxn 数据，该公司于 2022 年 1 月完成 472 万美元种子轮融资，投资方包括华创资本和蓝驰创投。Crunchbase 同样记录了这一融资。Apifox 在中国开发者群体中使用率较高，尤其是前后端联调、自动化测试场景。

说白了，这不是一个边缘工具——它是很多中国互联网公司开发团队的日常工具之一。

核心事实

攻击入口：被篡改的 CDN 资源

Apifox 桌面端基于 Electron 框架构建。每次启动时，客户端会从官方 CDN 拉取一个名为 apifox-app-event-tracking.min.js 的埋点脚本。这个脚本正常大小约 34KB，但从 3 月 4 日开始，该资源被间歇性替换为约 77KB 的投毒版本。2Libra 的首发预警最先点出了这一关键事实，rce.moe 随后发布的逆向分析确认了更多技术细节。Wayback Machine 上保留了 2026 年 3 月 5 日的投毒快照。

这里有一个关键细节值得注意：被篡改的文件位于 Apifox 自己的 CDN（cdn.apifox.com）上，而不是某个第三方依赖包。这意味着攻击者要么攻破了 Apifox 的 CDN 管理权限，要么通过某种内部渠道实现了文件替换。正如社区讨论中多位开发者指出的：这个脚本是 Apifox 内部资源，不是第三方包，正常情况下不应动态下发。

Electron 的安全短板

攻击之所以能从一个 JS 文件升级为完整的系统级入侵，根源在于 Apifox 的 Electron 配置存在严重安全缺陷。

Electron 是一个用 Web 技术构建桌面应用的框架，内部集成了 Chromium 浏览器和 Node.js 运行时。问题在于：Apifox 没有严格启用 sandbox（沙箱）模式，并且向渲染进程暴露了 Node.js API。这相当于给了网页代码直接操作操作系统的能力——读写文件、执行命令、访问网络，全都不在话下。

Electron 官方文档明确指出，自 v20 起 sandbox 默认启用，并强烈建议开发者不要关闭它。Electron 安全博客还专门写了一篇「Breach to Barrier」的迁移指南，呼吁开发者迁移到沙箱模式。Apifox 显然没有遵循这一最佳实践。

用一个类比来理解：sandbox 就像银行柜台的玻璃隔板。没有它，恶意 JS 代码就像一个不受限的柜员，可以直接走进金库。

攻击链：从脚本到全面窃密

AUTOSEC.DEV 在 3 月 25 日发布的分析报告将此事件定级为 Critical，并完整还原了攻击链条：

第一阶段（侦察与指纹收集）： 投毒脚本执行后，首先收集主机标识信息（UUID、操作系统、用户名等），构造自定义 HTTP 头（如 af_uuid、af_name），然后向攻击者控制的域名 apifox[.]it[.]com 请求第二阶段指令。如果用户在 Apifox 客户端中处于登录状态，脚本还会利用本地存储的 accessToken 调用 Apifox 官方 API 获取账号邮箱和显示名——据安全研究者「离别歌」（leavesongs.com）的复盘分析确认了这一行为。

第二阶段（定向窃密）： C2 服务器返回 RSA 加密的密文，客户端用脚本中硬编码的私钥解密后得到调度脚本，再通过 eval() 执行。据 rce.moe 的分析，观测到的载荷分为 v1（凭据采集）和 v2（纵深窃取）两个版本。具体窃取目标包括：

• SSH 密钥：递归读取 ~/.ssh/ 目录下的私钥文件
• Git 凭证：窃取 ~/.git-credentials 中的明文用户名和密码
• Shell 历史：收集 .zsh_history 或 .bash_history，从中挖掘环境变量、API keys、数据库密码
• 应用缓存：打包 Apifox 本地缓存中的 API 定义、Token 和业务数据
• 进程列表：在 macOS/Linux 执行 ps aux，在 Windows 执行 tasklist

数据回传： 所有数据经 Gzip 压缩后再用 AES-256-GCM 加密（密钥衍生自 apifox/foxapi），通过 /event/0/log 接口外传——AUTOSEC.DEV 的报告指出这种加密回传方式有效规避了常规流量审计。

持续轮询机制： 脚本每 30 分钟到 3 小时随机间隔轮询 C2 服务器。rce.moe 的分析特别强调：由于 eval() 可执行任意代码，且每次轮询返回的载荷可以完全不同，已捕获的 v1/v2 仅是侦察阶段的脚本。对于被标记为高价值的目标（如金融机构、加密货币交易所），攻击者完全有能力下发定制化的深度入侵载荷。

C2 域名的伪装手法

攻击者选用的 C2 域名 apifox.it.com 具有高度迷惑性。.it.com 看起来像是意大利国别域名 .it 的子域，但实际上它是 CentralNic Group 旗下的一项商业性三级域名注册服务。URLert 的情报分析将 it.com 标记为高风险域名平台，指出该平台下注册的大量网站被识别为恶意站点。

AUTOSEC.DEV 的 IoC 列表还包含了其他关联域名：cdn.openroute.dev、upgrade.feishu.it.com、ns.feishu.it.com、system.toshinkyo.or.jp。其中 feishu.it.com 同样利用了 .it.com 的域名服务，伪装成飞书（Feishu）的域名——这一选择暗示攻击者对目标群体的工具生态非常熟悉。

深度研判

攻击者画像推断

研判： 从攻击的精密程度来看，这不是一次机会主义的投毒。攻击者对 Apifox 的技术架构有相当深入的了解——知道客户端会动态拉取哪个脚本、知道 Electron 的 sandbox 未启用、知道如何利用 Apifox 的本地 Token 获取用户身份信息。C2 域名的选择（伪装为 apifox 和 feishu 的近似域名）也显示出对中国开发者工具生态的熟悉。

研判： 攻击的最终目标很可能不是 Apifox 本身，而是通过 Apifox 作为跳板，接触到使用该工具的企业的内部开发环境。SSH 密钥、Git 凭证、K8s 配置——这些都是进入企业内网和代码仓库的「金钥匙」。这种「打开发者工具链、收割企业资产」的策略与近年来多起供应链攻击高度一致。

「内部泄露还是外部入侵」之辩

社区讨论中存在一个争议焦点：被篡改的文件位于 Apifox 自己的 CDN 上，是否意味着存在内部人员参与？

论坛上多位开发者认为，CDN 资源被替换「怎么说也是内部所为」。但也有人指出，CDN 配置错误、管理凭证泄露、或 CDN 服务商本身被攻击都可能导致外部攻击者实现文件替换。Apifox 官方已通过微信公众号发布通告，确认事件性质为「遭受供应链攻击」。2Libra 讨论中有用户转述 Apifox 内部说法：旧版本这个 JS 是在线加载的，在遇到「网络被劫持」的情况下才会发生被篡改的风险。但该说法遭到社区质疑——攻击持续 18 天、涉及完整 C2 基础设施，仅用「网络劫持」难以解释全貌。

研判： Apifox 目前的公开解释仍不够充分，CDN 资源究竟是如何被替换的这一根本问题没有得到直接回答。

2026 供应链攻击的大背景

这次事件并不孤立。2026 年 3 月堪称供应链攻击的「密集轰炸月」：

| 时间 | 事件 | 手法 | | — | — | — | | 3月4日起 | Apifox CDN 投毒 | 篡改官方 CDN 上的 JS 脚本 | | 3月19日 | Aqua Security Trivy 供应链攻击 | GitHub Actions tag 投毒 + 二进制篡改 | | 3月下旬 | LiteLLM 供应链投毒 | 利用 Trivy 攻击窃取的凭证，向 PyPI 植入恶意版本 |

据 Palo Alto Networks 的分析，Trivy 攻击由 TeamPCP（又名 DeadCatx3、PCPcat）实施，手法包括凭证窃取、tag 投毒、二进制篡改和自传播蠕虫。Cyble 的年度报告显示，2025 年供应链攻击同比增长 93%，全年记录了 297 起事件。2026 年开局的这几起事件表明，这一趋势还在加速。

研判： 攻击者越来越倾向于攻击开发者信任的工具本身——安全扫描器、API 管理平台、CI/CD 流水线——因为这些工具通常拥有高权限且很少在运行时被审查。这是一种「信任链武器化」的趋势。

影响评估

直接影响

所有在 2026 年 3 月 4 日至 3 月 22 日期间启动过 Apifox 桌面端（低于 v2.8.19）的用户均在攻击范围内。受影响数据包括 SSH 密钥、Git 凭证、Shell 历史中的敏感信息、Apifox 本地缓存的 API 定义和 Token。

潜在影响

由于 C2 平台的灵活性，已捕获的侦察载荷仅是冰山一角。rce.moe 的分析明确警告：对于被攻击者标记为高价值的目标，后续可能已遭受后门植入、横向移动、源代码窃取甚至生产环境接管。受影响用户应按「已失陷」的最高级别进行应急响应。

处置建议

1. 立即升级至 Apifox v2.8.19 或更高版本。该版本已将埋点脚本改为安装包内资源，不再从 CDN 动态加载
2. 全量凭证轮换：SSH 密钥重新生成并在服务器端移除旧公钥；Git 凭证文件删除，Personal Access Token 吊销重建；所有 API keys 按已泄露处理
3. 检查持久化机制：审计 cron、Launch Agents、systemd 等，排查异常计划任务
4. 网络日志审计：检查是否存在对 apifox.it.com 及关联域名的出站连接
5. 本地存储检查：在 Apifox 开发者工具中查看 Local Storage 是否存在 _rl_mc、_rl_headers 等键值；检查 Chromium Network Persistent State 文件中是否包含 apifox.it.com

免责声明：

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

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

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

本文转载自：独眼情报 🅼🅰🆈 🅼🅰🆈《Apifox 供应链投毒事件》