Apifox 在 3 月 25 日发布公告，确认公网 SaaS 版桌面客户端曾动态加载一个外部 JavaScript 文件，而这个文件在 2026 年 3 月 4 日到 3 月 22 日之间遭到恶意篡改。官方把这次事件定性为供应链攻击。
这件事最值得重视的地方，不是“某个网站挂了”这么简单，而是桌面端一旦把在线外部脚本纳入运行链路，风险就会直接传到用户本机。对开发工具来说，这个边界一旦被打穿，影响通常比普通网页脚本事件更重。
先说结论
如果你在 2026 年 3 月 4 日到 3 月 22 日 期间使用过 公网 SaaS 版 Apifox 桌面客户端，最稳妥的做法不是观望，而是把自己当成“可能受影响用户”处理：
- 立刻升级到 2.8.19 或更高版本。
- 立刻轮换你机器上可能暴露的敏感凭据。
- 检查本地高敏感目录和历史记录文件。
- 把恶意域名
apifox.it.com直接封掉。
如果你用的是 Apifox Web 版，或者 私有化部署版本，根据官方说法，这次事件 不在受影响范围内。
这次到底发生了什么
根据官方公告，问题出在公网 SaaS 版桌面客户端动态加载的一个外部 JS 文件。这个文件被篡改后，带有恶意行为，并且会向 apifox.it.com 这个域名上报数据。官方称这个恶意域名当时托管在 Cloudflare，存在了 18 天，目前已经无法访问。
更关键的是，官方结合用户反馈和安全团队分析后认为，被篡改的恶意脚本有较高概率会读取本地高敏感文件，比如：
~/.ssh/~/.zsh_history~/.bash_history~/.git-credentials
如果你的开发机上保存过 SSH 私钥、Git 凭据、数据库密码、云服务 Access Key、环境变量密钥，风险就不能只理解成“理论上可能”。这类信息一旦被读走，后续连锁问题往往发生在代码仓库、服务器、数据库和对象存储，而不是只停留在 Apifox 本身。
哪些用户需要重点自查
这次事件不是“所有 Apifox 用户都中招”，但下面这类用户应该优先处理：
- 在风险时间窗口内使用过公网 SaaS 版桌面客户端的人
- 本机长期保存 SSH 私钥的人
- 在 shell history 里执行过带密钥命令的人
- 使用
git-credentials、明文环境变量、脚本配置文件保存凭据的人 - 机器同时连着生产环境、云资源或客户环境的人
说得直接一点：开发机越“全能”，这次事件的后果就越值得认真看。
Apifox 已经做了什么
官方公告里提到，他们已经完成一轮紧急修复，核心动作有两个：
第一，发布 2.8.19 修复版本，并开启自动更新提醒。
第二，彻底废除外部在线动态加载机制，改为本地内置打包。这一步很重要。因为真正的问题，不只是某个域名被人利用，而是“桌面客户端居然允许这条在线脚本链路存在”。现在把这条链路删掉，才算是从结构上补洞，而不只是把当下的恶意脚本换掉。
用户现在最该做什么
1）先升级，不要拖
先把客户端升级到 2.8.19 或更高版本。这一步不能代替后面的排查，但至少先把继续暴露的口子堵上。
2）把凭据轮换当成正事做
如果你在受影响时间窗口内使用过相关版本，建议不要只改一个 Apifox 密码，而是把整台开发机上可能关联的敏感凭据都过一遍。重点包括：
- SSH 私钥和相关跳板机凭据
- Git 平台 token、账号密码
- 数据库账号密码
- 云平台 Access Key / Secret Key
- 存在本地
.env、脚本文件、shell 历史里的密钥
这一步很麻烦，但比起事后追查异常登录和资源滥用，成本通常更低。
3）检查这些目录和文件
建议重点排查：
~/.ssh/~/.zsh_history~/.bash_history~/.git-credentials- 项目目录中的
.env、部署脚本、备份配置
如果里面保存过真实凭据，就按“可能已泄露”来处理，不要赌。
4）把恶意域名直接拦掉
官方给出的建议是把 apifox.it.com 指向 127.0.0.1。如果你还没做，可以在 hosts 里加上：
127.0.0.1 apifox.it.com
现在该域名虽然已不可访问，但本地先封掉，仍然是个低成本动作。
这次事件真正暴露了什么问题
我觉得这次最值得行业反思的，不只是 Apifox 本身，而是一个更通用的设计问题：
桌面开发工具如果还保留“在线动态加载外部脚本”的能力，本质上就是把本机信任边界往外送。
一旦这条链路被拿下，受影响的就不只是某个前端页面，而可能是用户机器上本来不该被碰的凭据、历史命令和项目配置。对普通内容站来说，这类问题是页面投毒；对开发工具来说，这类问题可能直接变成开发环境失守。
所以这次事件的教训其实很明确：
- 能本地打包的能力，尽量不要在线注入
- 能缩小动态加载范围的，就不要把执行权交给远端
- 开发工具厂商不能只盯功能迭代，安全边界设计要前置
- 开发者自己也别把敏感凭据在机器上放得到处都是
最后
这次公告至少把几个关键问题说清楚了：影响范围、时间窗口、可能触达的本地文件、修复版本和用户动作建议，算是比较实在。但对用户来说，真正重要的不是“公告看完了”，而是后续动作有没有做。
如果你在那 18 天里用过公网 SaaS 版桌面客户端，现在最应该做的不是继续讨论，而是升级、排查、轮换凭据。