夜雨聆风Axios（npm 生态里最常见的 HTTP 请求库之一）被曝在极短时间窗内遭遇“供应链投毒”。OpenAI 随后披露，在 3 月 31 日（UTC）其用于macOS 应用签名的 GitHub Actions 工作流曾下载并执行了被投毒的恶意 Axios 版本。OpenAI 强调未发现用户数据被访问、系统被攻破或软件被篡改，但仍将相关macOS 代码签名证书按“最坏情况”处理并轮换/吊销，并要求所有 macOS 用户在 2026 年 5 月 8 日前把 ChatGPT Desktop、Codex、Codex CLI、Atlas 更新到采用新证书签名的版本，以降低“伪造 OpenAI 应用”分发风险。
1）发生了什么：Axios 被“投毒”，而且是典型的软件供应链攻击
这次事件的起点，是 Google Threat Intelligence Group（GTIG）披露的一次 npm 供应链攻击。
GTIG 公开信息显示，攻击者在2026 年 3 月 31 日 00:21–03:20（UTC）的窗口内，将一个恶意依赖 `plain-crypto-js` 注入到 Axios 的发布版本中：
被投毒版本：axios 1.14.1、0.30.4 恶意依赖：plain-crypto-js（被描述为混淆的 dropper） 触发方式：利用 npm 的postinstall钩子静默执行 `setup.js` 归因判断：GTIG 将活动归因为UNC1069（朝鲜关联、以经济动机为主）
"Between March 31, 2026, 00:21 and 03:20 UTC, an attacker introduced a malicious dependency named `plain-crypto-js` into axios NPM releases versions 1.14.1 and 0.30.4."
「在 2026 年 3 月 31 日 00:21 到 03:20（UTC）之间，攻击者将名为 `plain-crypto-js` 的恶意依赖注入到了 axios 的 1.14.1 与 0.30.4 版本。」
（来源：GTIG）
这类攻击最危险的地方在于，它不是去“打某家公司的网站”，而是去污染大家默认会信任、会自动拉取的开发依赖。只要你的 CI/CD、构建或签名流程在那个时间窗里“刚好拉到了恶意版本”，就可能在不知情的情况下执行攻击者的代码。
2）OpenAI 为什么会被波及：恶意 Axios 在其 macOS 签名工作流被执行
OpenAI 在官方技术说明里披露：当 Axios 被投毒时，OpenAI 的一个GitHub Actions 工作流（用于 macOS app-signing 流程）下载并执行了恶意 Axios（1.14.1）。该工作流拥有用于签名/公证（notarization）的证书与材料。
"At that time, a GitHub Actions workflow we use in the macOS app-signing process downloaded and executed a malicious version of Axios (version 1.14.1)."
「当时，我们用于 macOS 应用签名流程的一个 GitHub Actions 工作流下载并执行了恶意版本的 Axios（1.14.1）。」
（来源：OpenAI 官方说明）
这里的关键点在于：
- 这不是“某个用户电脑装了恶意软件”
，而是发生在“构建/签名流水线”这种高权限环境里。 如果签名材料真的被窃取，攻击者未来可能制作一个“看起来是 OpenAI 的合法应用”的伪造安装包，用旧证书签名后诱导用户安装。
3）OpenAI 为何强调“没证据”同时又要求 macOS 用户立刻更新
OpenAI 在 X 的对外口径很明确：
"We found no evidence that OpenAI user data was accessed, that our systems were compromised, or that our software was altered."
「我们没有发现证据表明 OpenAI 用户数据被访问、系统被攻破或软件被篡改。」
同时它也强调，出于谨慎要保护 macOS 应用“合法性认证”的流程，并要求 macOS 用户更新。
▲ OpenAI 在 X 发布的主声明：强调“未发现证据”，同时要求 macOS 用户更新到最新版。
这看似矛盾，其实是两类风险：
- 现状风险（OpenAI称未发现）
：用户数据被访问、系统被攻破、已发布软件被篡改。 - 未来风险（OpenAI要堵住）
：签名证书材料若曾暴露，可能被用于伪造“像真的一样”的 OpenAI 安装包。
OpenAI 在官网说明中写到，他们的分析认为签名证书材料很可能没有被成功外传，原因包括恶意 payload 执行时机、证书注入到 job 的时序、job 执行顺序等缓解因素。但即便如此，仍按最坏情况处理：轮换并计划吊销旧证书。
4）对用户影响：5 月 8 日是关键节点，最低版本门槛已给出
OpenAI 给出的时间点是2026 年 5 月 8 日：从这天起，旧版本 macOS 桌面应用将不再获得更新或支持，并且“可能无法正常工作”。同时它列出了“最早采用新证书签名”的版本下限：
ChatGPT Desktop：1.2026.051 Codex App：26.406.40811 Codex CLI：0.119.0 Atlas：1.2026.84.2
并强调只通过应用内更新或官网链接下载，不要点第三方渠道的“安装包”。
▲ OpenAI 引导用户查看“技术细节与 FAQ”，并提示通过官方渠道更新。
▲ OpenAI 给出的 ChatGPT Desktop 官方下载入口。
▲ Codex CLI 官方链接入口。
5）真正值得警惕的教训：一个“配置细节”，就可能让流水线吞下恶意依赖
OpenAI 在根因部分点名了一个非常具体、也非常常见的坑：
工作流里使用了floating tag（浮动标签），而不是固定到某个 commit hash 没有配置minimumReleaseAge（最小发布时间门槛）
通俗一点说：
浮动标签意味着你的流水线可能在某次运行中“自动拿到更新后的东西”，而你并没有审查那个更新。 最小发布时间门槛则可以避免“刚发布几分钟的包”直接进入生产流水线，在供应链投毒这种“短窗口”事件里尤其关键。
这也是为什么在讨论区里，有安全从业者把焦点放在“依赖治理”和“SBOM/扫描策略”上。
▲ 有讨论提到 GTIG 的归因判断，以及 Axios 作为基础依赖的“爆炸半径”。（注意：这是网友观点与引用公开报告，不等同于 OpenAI 自己的结论。）
6）FAQ（基于 OpenAI 官方说明）
Q：需要改密码或重置 OpenAI API Key 吗？A：OpenAI 表示不需要，密码与 OpenAI API keys 未受影响。
Q：会影响 iOS / Android / Linux / Windows 吗？A：OpenAI 表示不影响，仅涉及 OpenAI 的 macOS apps，不影响 web 版本。
Q：是否发现“被旧证书签名的 OpenAI 恶意软件”？A：OpenAI 表示没有证据表明相关材料被滥用，也确认受影响材料对应的 notarization 事件均为预期。
7）你现在该做什么
如果你是 macOS 用户
1) 通过应用内更新或 OpenAI 官方页面更新：ChatGPT Desktop、Codex、Codex CLI、Atlas。 2) 在 2026-05-08 前完成升级，至少达到 OpenAI 公告给出的最低版本门槛。 3) 对任何“邮件、短信、广告、第三方下载站”的 OpenAI/ChatGPT/Codex 安装包保持怀疑，尽量只走官网。
如果你是开发者/团队（尤其有 CI/CD 流水线）
1) 立即排查 lockfile 与依赖树，确认是否曾拉取axios 1.14.1 / 0.30.4，以及是否出现plain-crypto-js。 2) 固定依赖版本（pin）、尽可能固定到已验证的提交/哈希，避免“浮动标签”。 3) 给关键流水线加 minimumReleaseAge 或等效机制，给依赖更新留出观察窗口。 4) 对构建机、签名机等高权限环境的 secrets 管理与出网策略做更强隔离。
资料来源（按文中出现顺序）：
OpenAI（X）：https://x.com/OpenAI/status/2042780052669239782 OpenAI（技术说明/FAQ）：https://openai.com/index/axios-developer-tool-compromise/ Google Threat Intelligence Group（GTIG）：https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package npm axios 页面：https://www.npmjs.com/package/axios
— END —
