# Apifox 公网 SaaS 桌面端外部 JS 被篡改：影响范围、风险点与用户该做什么

**URL:** <https://www.sunai.net/t/topic/1345>\
**Category:** IT\
**Tags:** 安全, apifox, saas, 攻防, javascript\
**Created:** [2026 年3 月 25 日 16:39 UTC](https://www.sunai.net/t/topic/1345 "2026-03-25T16:39:14Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

作者： ![Logos](https://www.sunai.net/user_avatar/www.sunai.net/logos/32/2077_2.png) [@Logos](https://www.sunai.net/u/Logos)\
发布日期： [2026 年3 月 25 日 16:39 UTC](https://www.sunai.net/t/topic/1345/1 "2026-03-25T16:39:14Z")

</div>

Apifox 在 3 月 25 日发布公告，确认公网 SaaS 版桌面客户端曾动态加载一个外部 JavaScript 文件，而这个文件在 2026 年 3 月 4 日到 3 月 22 日之间遭到恶意篡改。官方把这次事件定性为供应链攻击。

这件事最值得重视的地方，不是“某个网站挂了”这么简单，而是桌面端一旦把在线外部脚本纳入运行链路，风险就会直接传到用户本机。对开发工具来说，这个边界一旦被打穿，影响通常比普通网页脚本事件更重。

## 先说结论

如果你在 **2026 年 3 月 4 日到 3 月 22 日** 期间使用过 **公网 SaaS 版 Apifox 桌面客户端** ，最稳妥的做法不是观望，而是把自己当成“可能受影响用户”处理：

1. 立刻升级到 **2.8.19** 或更高版本。
2. 立刻轮换你机器上可能暴露的敏感凭据。
3. 检查本地高敏感目录和历史记录文件。
4. 把恶意域名 `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 里加上：

```plaintext
127.0.0.1 apifox.it.com

```

现在该域名虽然已不可访问，但本地先封掉，仍然是个低成本动作。

## 这次事件真正暴露了什么问题

我觉得这次最值得行业反思的，不只是 Apifox 本身，而是一个更通用的设计问题：

**桌面开发工具如果还保留“在线动态加载外部脚本”的能力，本质上就是把本机信任边界往外送。**

一旦这条链路被拿下，受影响的就不只是某个前端页面，而可能是用户机器上本来不该被碰的凭据、历史命令和项目配置。对普通内容站来说，这类问题是页面投毒；对开发工具来说，这类问题可能直接变成开发环境失守。

所以这次事件的教训其实很明确：

- 能本地打包的能力，尽量不要在线注入
- 能缩小动态加载范围的，就不要把执行权交给远端
- 开发工具厂商不能只盯功能迭代，安全边界设计要前置
- 开发者自己也别把敏感凭据在机器上放得到处都是

## 最后

这次公告至少把几个关键问题说清楚了：影响范围、时间窗口、可能触达的本地文件、修复版本和用户动作建议，算是比较实在。但对用户来说，真正重要的不是“公告看完了”，而是后续动作有没有做。

如果你在那 18 天里用过公网 SaaS 版桌面客户端，现在最应该做的不是继续讨论，而是升级、排查、轮换凭据。

原文链接：[关于 Apifox 公网 SaaS 版外部 JS 文件受篡改的风险提示与升级公告](https://mp.weixin.qq.com/s/GpACQdnhVNsMn51cm4hZig)