Apifox 供应链攻击应急响应实录

Apifox 供应链攻击应急响应实录：一个普通开发者的自救指南

2026年3月25日，Apifox 发布安全公告：其桌面客户端动态加载的一个外部 JavaScript 文件遭遇恶意篡改，攻击者可借此读取用户本地敏感文件。

那天我正在用 Apifox 调接口，看到公告的那一刻，心里一紧——我确认自己在风险窗口内使用过。

这篇文章，记录了我收到公告后的完整排查与处置过程。如果你也是 Apifox 用户，或者你想知道遇到供应链安全事件时该怎么自救，这篇文章能帮到你。

事件背景

先说清楚发生了什么。

2026年3月25日，Apifox 官方发布紧急安全公告，核心信息：

• 风险窗口：2026年3月4日 — 3月22日

• 攻击方式：供应链攻击，篡改客户端动态加载的外部 JS 文件

• 攻击特征：恶意脚本概率性触发，读取本地敏感文件并上报至 C2 域名 apifox.it.com

• 可能泄露的文件：~/.ssh/、~/.zsh_history、~/.bash_history、~/.git-credentials 等

• 受影响范围：公网 SaaS 版桌面客户端，Web 版和私有化部署不受影响

我在风险窗口内（3月11日）使用过 Apifox 桌面客户端，确认受影响。

第一步：确认版本升级与域名屏蔽

1. 检查 Apifox 版本

官方要求升级至 2.8.19 或更高版本。这个版本已将外部 JS 改为本地内置，从物理层面切断了攻击路径。

macOS 下的检查方法：

defaults read /Applications/Apifox.app/Contents/Info.plist CFBundleShortVersionString

我当前版本为 2.8.21，已满足要求。

2. 屏蔽恶意域名

在 /etc/hosts 中添加：

127.0.0.1 apifox.it.com

验证一下：

grep"apifox.it.com" /etc/hosts

这两步是基础防护，但真正的风险在于：已经可能泄露的凭证。

第二步：排查本机泄露风险（最关键）

这是整个应急响应中最重要的环节。我按照风险等级逐一排查。

1. SSH 私钥

ls-la ~/.ssh/

发现了两个私钥：

• id_rsa（2018年生成，无 passphrase）

• webide_id_rsa（2022年生成）

私钥无 passphrase，一旦被读取，攻击者可直接冒用身份访问所有 SSH 目标。更糟糕的是，我的 history 中有大量 git clone git@gitlab.* 记录——攻击者连我的 SSH 目标地址都知道了。

2. Shell History 中的明文凭据（最严重的泄露源）

通过扫描 .zsh_history，我发现了大量明文敏感信息：

飞书 App Secret：

来源是通过 lark-cli auth login 命令登录时，secret 作为参数被记录到了 history。

API Key：

来源是 Cherry Studio 配置 Anthropic API Key 时，通过 export 命令设置环境变量被记录。

小红书创作者平台 access token：

来源是 curl 命令中携带的 cookie。

这里有个关键认知：恶意脚本读取的是整个 .zsh_history 文件，不是按时间范围读取。即使某个密钥是 2025 年写入 history 的，只要文件在风险窗口内被读取，所有历史记录都已暴露。

教训：命令行中传入的密钥会被 shell history 记录。应避免在命令参数中直接传入敏感信息，或事后及时清理。

3. Git Credentials

test-f ~/.git-credentials &&echo"EXISTS"||echo"NOT FOUND"

结果：不存在。此项无风险，松了口气。

第三步：凭证轮换与修复

排查完毕，开始按优先级逐项处理。

1. 各种 App Secret

到各种开放平台 → 找到对应应用 → 凭证与基础信息 → 重置 App Secret → 用新 secret 重新登录。

2. Anthropic API Key

到 各种 agent工具里替换 api key。

3. 小红书 Token

重新登录小红书创作者平台，旧 token 自动失效。

5. SSH 密钥重置（核心操作）

这是最重要的一步。我选择了沿用 id_rsa 文件名，避免到处改配置：

# 备份旧密钥
mkdir-p ~/.ssh/backup_old &&mv ~/.ssh/id_rsa ~/.ssh/id_rsa.pub ~/.ssh/backup_old/

# 生成新的 ed25519 密钥
ssh-keygen -t ed25519 -C"leon@2026"-f ~/.ssh/id_rsa

# 部署到各平台
ssh-copy-id -i ~/.ssh/id_rsa.pub webmaster@<server-ip>
# GitHub / Gitee：复制公钥到后台 SSH Keys 页面
pbcopy < ~/.ssh/id_rsa.pub

# 验证
ssh-T git@github.com

# 确认无误后清理旧密钥
rm-rf ~/.ssh/backup_old ~/.ssh/webide_id_rsa ~/.ssh/webide_id_rsa.pub

为什么选 ed25519 而不是 RSA？

• 更安全：目前无已知实际攻击能破解

• 密钥更短：公钥只有一行

• 性能更好：连接速度更快

6. 清理 known_hosts

顺便把已废弃的服务器条目也清理了：

ssh-keygen -R sshllm.top
ssh-keygen -R ec2-*.compute.amazonaws.com
ssh-keygen -R<已销毁的服务器IP>

完整处置清单

给开发者的安全建议

这次事件让我重新审视了自己的安全习惯。以下四条建议，都是我亲身踩坑后的总结。

1. 不要在命令行中直接传入密钥

# ❌ 错误做法：密钥会被记录到 shell history
lark-cli auth login --app-secret my_secret_here

# ✅ 正确做法：用环境变量或交互式输入
exportAPP_SECRET=$(cat ~/.secrets/lark_secret)
lark-cli auth login --app-secret $APP_SECRET

或者更简单的习惯：凡是命令行里输入过密钥的，事后检查是否被 history 记录，及时清理。

2. 给 SSH 密钥设置 passphrase

ssh-keygen -t ed25519 -C"your@email.com"
# 提示输入 passphrase 时不要留空！

即使私钥被偷走，没有 passphrase，攻击者也无法直接使用。这是最简单的一道防线。

3. 感知到风险时立即轮换，比定期轮换更现实

定期轮换密钥对个人开发者来说维护成本太高——你要逐个平台重新部署，很容易遗漏。更务实的做法是：

• 发现安全事件时立即轮换（就像这次一样）

• 离职时轮换与公司相关的所有凭证

• 淘汰旧设备前轮换密钥

• 不再使用的密钥及时删除

4. 敏感文件权限要收紧

Linux/macOS 的文件权限决定了"谁可以读这个文件"。默认情况下，~/.ssh/ 目录里的私钥只有你自己能读。但如果权限设错了（比如 777），任何程序都能直接读取你的私钥。

chmod700 ~/.ssh          # 只有你自己能进入这个目录
chmod600 ~/.ssh/id_rsa   # 只有你自己能读写私钥
chmod644 ~/.ssh/id_rsa.pub  # 公钥可以被读取，但不能修改

不过说实话，桌面应用一般以你的用户身份运行，权限拦不住同用户的程序。但这是最基本的安全习惯，至少能防止其他用户或服务读到你的密钥。

写在最后

这次 Apifox 供应链攻击事件给我敲了警钟。

作为开发者，我们习惯性地信任开发工具——IDE、API 调试工具、CLI 客户端……但工具本身也可能成为攻击向量。当你装了越多开发工具，攻击面就越大。

快速响应、系统性排查、彻底轮换凭证——这是应对此类事件的核心原则。

希望这篇文章对你有帮助。如果你也是 Apifox 用户，请立即检查。

事件时间线：2026-03-04 攻击开始 → 2026-03-22 风险窗口结束 → 2026-03-25 官方发布公告 → 2026-03-29 完成本机处置