重大安全播报！Apifox遭遇投毒 请使用该平台的开发者立即轮换所有密钥

国内不少团队都在用的 Apifox 出事了。简单说，这不只是个 Bug，而是实打实的供应链投毒。如果你在 3 月 4 日至 3 月 23 日 期间启动过 Apifox 桌面端，别犹豫，立刻、马上轮换（Rotate）你本地机器上所有的敏感密钥。

这次投毒的恶意载荷（Payload）逻辑非常激进，目标直指开发者的“命根子”。它会自动扫描并窃取你本地的 SSH 凭证、Git 令牌、AWS/k8s 配置文件 以及各类环境变量。说白了，只要你在这期间跑过那个版本的软件，你的服务器登录权限和代码仓库权限可能已经躺在黑客的数据库里了。

为什么只更新版本是不够的？

这里有个坑：Apifox 已经在 3 月 23 日发布了修复版本，但目前官方似乎并未在显眼位置发布正式的安全公告。很多开发者习惯性地点个“更新”就以为万事大吉了，其实大错特错。

被动更新只能阻止后续泄露，但无法撤回已经流出的密钥。 这种攻击最阴的地方在于“潜伏性”。黑客拿到你的 SSH Key 或 Git Token 后，通常不会立刻搞破坏，而是等几个月甚至更久再发起攻击。

必须执行的“止损”清单

别抱侥幸心理，请按照以下步骤彻底排查并重置环境：

1. 轮换 SSH Key：
   立刻生成新的公私钥对，并把服务器 ~/.ssh/authorized_keys 中旧的公钥全部删除。
2. 重置 Git Personal Access Tokens (PAT)：
   无论是 GitHub、GitLab 还是公司内网的 Gitea，所有在本地配置过的 Access Token 全部废弃重发。
3. 重新颁发云平台凭证：
   检查你的 ~/.aws/credentials 或阿里云的 OSS/ECS 访问密钥。只要是写在配置文件里的 AccessKey/SecretKey，全部视为已泄露。
4. 清理 K8s 配置文件：
   检查你的 ~/.kube/config。恶意脚本对这类包含集群高权的配置文件有极高的扫描优先级。
5. 检查环境变量：
   执行 env 命令，看看里面有没有数据库连接字符串、第三方 API Key 等敏感信息。

(实测建议：不仅要换密钥，还要检查一下各平台的异常登录审计日志，看看这段时间有没有来自陌生 IP 的访问记录。)

供应链攻击现在越来越频繁，尤其是这类基于 Electron 的工具，一旦依赖链条出问题，开发者几乎是全裸奔状态。这种事发生后，比起等官方那份迟迟不来的公告，实战派的做法永远是：先假设自己已经中毒，然后立刻止损。

你在使用这类 API 协作工具时，会为了方便把生产环境的 Token 直接写在环境变量里吗？针对这种防不胜不扣的供应链投毒，你有什么更硬核的防御手段？