这件事情发生有2天了，起初根本没在意。
今天在 v2 再次刷到 此次 ApiFox 是否中招自查命令。
【包括不限于: SSH 私钥、Git 凭证和命令行历史】，这段话让我有了后怕。
接着，迅速检查电脑和采取修复以及防御手段。
检查电脑
下列涉及的命令都是 macOS 支持的，其他平台参考。
- 检查 Electron localStorage 中是否存在 _rl_headers、_rl_mc 键
grep -arlE "rl_mc|rl_headers" ~/Library/Application\ Support/apifox/Local\ Storage/leveldb
- 检查 dns 历史中是否存在 apifox.it.com 的解析记录
sudo dscacheutil -q host -a name apifox.it.com
- 检查历史 HTTP 请求头中是否包含 af_uuid、af_os 等异常字段，
这个事情处理有点难度，建议使用 AI 工具来执行。
修复和防御
特别说明，本次事件受影响范围：受影响用户为“公网 SaaS 版 Apifox 桌面客户端”用户。SaaS Web 版用户不受影响；私有化部署版用户不受影响。
立即采取的行动:
-
立即升级： 请尽快将 Apifox 客户端升级至 2.8.19 或最新版本。
-
重置凭证： 若您在上述风险时间段内使用过受影响版本，请务必联系您的团队，全面排查并重置在设备里 ~/.ssh/、~/.zsh_history、~/.bash_history、~/.git-credentials 等处存储过的敏感凭证（包括但不限于 Git 密钥、鉴权密钥、数据库密码、云服务 Access Key 及环境变量等）。
-
阻断恶意域名：apifox.it.com ，可以在 host 文件里增加配置：127.0.0.1 apifox.it.com
为什么会发生这样的事情？
供应链攻击，本质不是漏洞，而是“信任链被利用”。
为了防范此类事情再次发生，作为开发者，有必要列一个自检清单。
本地开发环境
- 是否开启自动更新？
- 是否验证安装包来源（hash / 签名）？
- 是否区分“工作环境 / 测试环境”？
👉 建议：
- 关键工具关闭自动更新
- 下载后的安装包做 hash 校验（哪怕是关键工具）
- 严格区分“工作环境 / 测试环境”
依赖管理
- 是否锁版本（package-lock.json / go.sum 等）
- 是否盲目 latest
- 是否使用第三方镜像源（npm mirror / pip 源）
👉 建议：
- 关键依赖锁定版本
- 建立私有化仓库，减少第三方镜像源依赖
CI/CD 与自动化
- CI 是否每次重新拉依赖？
- 是否有缓存污染风险？
- 构建流程是否可追溯？
👉 建议：
- 固定依赖版本
- 构建环境可复现（Docker / lockfile）
权限与隔离
- 是否在开发机使用高权限运行工具？
- 是否把敏感 token 放在本地明文？
- 是否做最小权限控制？
👉 建议：
Ref