2026 年 3 月，知名 API 开发工具 Apifox 桌面客户端遭遇供应链攻击，攻击者通过官方 CDN 注入恶意 JavaScript 代码，Windows、macOS、Linux 三平台均受影响。
事件概述
2026 年 3 月初，Apifox 桌面客户端被曝遭遇严重的供应链投毒攻击。攻击者通过官方 CDN 托管的前端脚本文件注入了高度混淆的恶意 JavaScript 代码，导致用户面临：
- 凭证窃取：SSH 密钥、Git 凭证、API Token
- 敏感数据泄露：命令行历史、进程列表、系统环境变量
- 远程命令执行：攻击者可控制用户终端
影响范围：Windows、macOS、Linux 三大平台的 Apifox 桌面客户端用户均受影响。
攻击技术细节
1. 攻击时间线
- 2026 年 3 月 4 日：恶意代码首次出现在 CDN 服务器上
- 2026 年 3 月中旬：安全社区发现异常并发出预警
- 截至 3 月 25 日：Apifox 官方尚未发布正式安全公告
2. 攻击手法
文件投毒：
攻击者篡改了 CDN 上的 apifox-app-event-tracking.min.js 文件：
- 正常版本：约 34KB
- 被投毒版本：77KB（增加了 43KB 恶意代码）
恶意代码行为：
- 动态加载非官方域名
apifox.it.com上的apifox-event.js - 在满足特定条件下窃取敏感信息：
- SSH 私钥（
~/.ssh/） - Git 凭证（
.git-credentials） - 命令行历史（
.bash_history、.zsh_history） - 进程列表和系统环境变量
- SSH 私钥（
- 将窃取的数据上报到
apifox.it.com/event/0/log
3. 为什么攻击能成功？
Electron 安全缺陷：
Apifox 桌面端基于 Electron 框架开发，但存在关键安全配置问题：
- 未严格启用 sandbox 参数：允许渲染进程访问 Node.js API
- 暴露 Node.js API 接口：使得 JavaScript 代码可以直接调用系统命令
这意味着，一旦恶意 JS 代码被加载，攻击者就能通过 Node.js API 完全控制用户的终端。
域名迷惑性：
攻击者使用的 apifox.it.com 域名极具迷惑性：
- 看起来像是 Apifox 的意大利区域域名
- 实际上是攻击者注册的恶意域名
- 用户和安全工具都很难第一时间识别
应急响应建议
如果你使用了 Apifox 桌面客户端，建议立即采取以下措施：
立即行动
- 撤销所有 Token：GitHub、GitLab、云服务商的 API Token
- 重置密码：所有关键账号的密码
- 重新生成 SSH 密钥：删除旧密钥，生成新密钥对
- 退出并重新登录：使所有会话失效
网络层防护
# 阻止恶意域名（添加到 hosts 文件）
echo "0.0.0.0 apifox.it.com" | sudo tee -a /etc/hosts
echo "0.0.0.0 *.apifox.it.com" | sudo tee -a /etc/hosts
清理本地数据
# macOS/Linux
rm -rf ~/Library/Application\ Support/apifox-app/
rm -rf ~/.config/apifox-app/
# Windows
# 删除 %APPDATA%\apifox-app\
审查日志
- 检查 API 调用日志，寻找异常活动
- 审查 Git 提交历史，确认没有未授权的提交
- 检查云服务商的操作日志
供应链攻击的新趋势
Apifox 事件不是孤立的。2025-2026 年，软件供应链攻击呈现出明显的演变趋势：
从仿冒到入侵
早期（2020-2024）：攻击者主要通过发布仿冒包（typosquatting）进行攻击
- 例如：
react-native→react-nativ - 依赖用户的拼写错误
现在（2025-2026）：攻击者直接入侵合法项目
- 窃取维护者凭证
- 在官方包中植入恶意代码
- 通过 CI/CD 流水线传播
2025-2026 年重大事件
2025 年 9 月：chalk 和 debug 等流行 npm 包被入侵
- 每周下载量超过数十亿次
- 攻击者通过钓鱼窃取维护者凭证
2025 年 12 月：Shai-Hulud 3.0 恶意软件
- 能够自我传播
- 窃取 npm 和 GitHub Token
- 自动发布恶意版本
- 影响近 800 个包
2026 年 1 月：180+ npm 包被发现不安全
- 帮助传播恶意软件
- 自动更新机制成为攻击载体
2026 年 2 月：SANDWORM_MODE 行动
- 19 个 typosquatting 包
- 窃取凭证并在开发环境中传播
如何防御供应链攻击
对开发者
-
审查依赖项
- 定期检查
package.json和package-lock.json - 使用
npm audit或yarn audit扫描漏洞 - 关注依赖项的更新频率和维护者变更
- 定期检查
-
锁定版本
{ "dependencies": { "react": "18.2.0", // 精确版本，不用 ^18.2.0 "axios": "1.6.0" } } -
启用 2FA
- npm、GitHub、GitLab 等平台必须启用双因素认证
- 使用硬件密钥（YubiKey）更安全
-
使用监控工具
- Socket.dev：实时监控依赖项变化
- Snyk：漏洞扫描和修复建议
- Dependabot：自动化依赖更新
对企业
-
私有 npm 仓库
- 使用 Verdaccio、Nexus 等搭建私有仓库
- 所有依赖先经过内部审核再使用
-
CI/CD 安全
- 限制 CI/CD 流水线的权限
- 使用短期 Token，避免长期凭证
- 审计所有自动化脚本
-
网络隔离
- 开发环境与生产环境隔离
- 限制开发机器的外网访问
对 Electron 应用开发者
Apifox 事件给 Electron 开发者的教训：
-
启用沙箱模式
const win = new BrowserWindow({ webPreferences: { sandbox: true, // 必须启用 nodeIntegration: false, // 禁用 Node.js 集成 contextIsolation: true // 启用上下文隔离 } }); -
CSP（内容安全策略）
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'"> -
验证远程资源
- 对 CDN 资源进行完整性校验（Subresource Integrity）
- 使用 HTTPS 并验证证书
写在最后
Apifox 供应链攻击事件揭示了一个残酷的现实：没有绝对安全的软件。
当攻击者能够入侵官方 CDN、篡改合法代码时，传统的安全防护手段几乎失效。用户信任官方渠道，但官方渠道本身可能已被攻陷。
这不是 Apifox 的问题，而是整个软件供应链的系统性风险。从 SolarWinds 到 Log4j，从 npm 生态到 Electron 应用，供应链攻击已经成为最难防御的威胁之一。
我们能做的：
- 保持警惕，定期审查依赖项
- 启用多因素认证，保护好凭证
- 锁定版本，避免自动更新带来的风险
- 建立应急响应机制，快速处理安全事件
对 Apifox 官方的期待：
- 尽快发布正式安全公告
- 公开攻击细节和影响范围
- 加强 CDN 安全防护
- 改进 Electron 应用的安全配置
供应链安全，没有旁观者。
参考资料：
- Safeheron：《npm 供应链攻击 2025-2026 年度报告》
- 安全社区预警报告（2026 年 3 月）
相关链接：
- Apifox 官网：https://apifox.com
- npm 安全最佳实践：https://docs.npmjs.com/security-best-practices
如果你使用了 Apifox，请立即检查你的系统并采取应急措施。如果发现异常活动，请及时上报。
