Axios npm 供应链投毒波及 OpenAI：四款 macOS 应用紧急换签，开发者须知

Axios npm 包遭供应链投毒，恶意代码通过 GitHub Actions 渗入 OpenAI macOS 应用签名流程。OpenAI 紧急撤换证书，要求用户在 5 月 8 日前更新 ChatGPT、Codex 等四款应用。

Axios 投毒波及 OpenAI，四款 Mac 应用紧急换签

OpenAI 昨天（4 月 10 日）发了一份安全公告，承认自家 macOS 应用的签名流程被 Axios 供应链攻击波及，要求所有 Mac 用户尽快更新 ChatGPT、Codex、Atlas 和 Codex CLI 四款应用。如果你在 5 月 8 日之前不更新，macOS 的 Gatekeeper 会直接拦截旧版应用的启动。

这不是一次针对 OpenAI 的定向攻击，但 OpenAI 确实踩了坑——而且踩得很典型。

OpenAI 安全公告页面截图，展示受影响的四款 macOS 应用及更新链接

到底发生了什么

事情要从 3 月底说起。

3 月 31 日前后，npm 上出现了两个被投毒的 Axios 版本：axios@1.14.1 和 axios@0.30.4。攻击者在这两个版本中植入了远程控制代码——简单说，就是一个 RAT（Remote Access Trojan）。任何在 CI/CD 流程中拉取了这两个版本的项目，都可能在构建环节执行恶意代码。

Axios 是什么不用多说了。几乎每个写 JavaScript 的人都用过它，npm 周下载量长期在 5000 万以上。它是前端和 Node.js 生态里最主流的 HTTP 客户端库，地位大概相当于 Python 里的 requests。正因为用的人太多，它才成了供应链攻击的理想目标。

攻击者的手法并不新鲜，但依然有效：通过某种方式获取了 npm 包的发布权限（具体途径尚未完全公开，业界推测与维护者凭证泄露或 npm 账户劫持有关），然后发布了看起来像正常版本迭代的恶意包。1.14.1 这个版本号紧跟在当时的最新稳定版之后，如果你的 package.json 里写的是 ^1.14.0 或者类似的宽松版本范围，npm install 就会自动拉到投毒版本。

这正是 OpenAI 中招的原因。

OpenAI 是怎么踩坑的

OpenAI 用于 macOS 应用签名的流程跑在 GitHub Actions 上。这套 CI 工作流在构建过程中会安装依赖，而其中就包括 Axios。3 月 31 日，工作流因为配置缺陷，拉取并执行了 axios@1.14.1——也就是被投毒的那个版本。

注意这里的关键词：配置缺陷。

OpenAI 没有明确说这个缺陷具体是什么，但根据公告的措辞和业界常见的 CI/CD 安全问题，大概率是以下几种情况之一：

依赖版本没有锁定（没有用 lockfile，或者 lockfile 没有纳入 CI 流程）
GitHub Actions 工作流中直接执行了 npm install 而没有使用 npm ci
没有对依赖包做完整性校验（比如没有启用 npm 的 --ignore-scripts 或者没有用 npm audit 做前置检查）

这些问题在开发团队里太常见了。很多团队的 CI 配置是早期搭建的，之后就很少有人回头审计。尤其是签名流程这种「配好了就不动」的环节，往往是安全审查的盲区。

恶意代码在签名环节被执行，意味着攻击者理论上可以接触到签名证书和相关密钥。这是整件事里最严重的部分——不是因为已经造成了实际损害，而是因为如果证书泄露，攻击者就可以用它来签名伪造的应用，而 macOS 会认为这些伪造应用是合法的 OpenAI 软件。

OpenAI 的应对：没出事，但按出事处理

OpenAI 在公告中说得很明确：目前没有证据表明有任何用户数据被访问，也没有发现软件被篡改的迹象。

但他们选择了最保守的处理方式——把证书当作已泄露来对待。

具体措施包括：

撤销旧的代码签名证书，生成并启用新证书
用新证书重新签名所有受影响的应用
与苹果合作，阻止旧证书的新公证（Notarization）请求
从 5 月 8 日起，macOS 将拦截使用旧证书签名的应用

这个处理思路是对的。在安全事件响应中，「没有证据表明被利用」和「确认没有被利用」是两回事。前者只是说你目前没发现，后者需要完整的取证分析才能下结论。OpenAI 选择不赌这个概率，直接换证书，是负责任的做法。

受影响的四款应用：

应用名称	类型
ChatGPT	macOS 桌面客户端
Codex	代码辅助工具
Atlas	内部/企业工具
Codex CLI	命令行工具

用户需要在 5 月 8 日之前从 OpenAI 官方渠道下载最新版本。过了这个日期，旧版应用会被 macOS 的 Gatekeeper 机制拦截，无法正常启动。

供应链攻击：老问题，新烈度

这已经不是 npm 生态第一次出这种事了。

2021 年的 ua-parser-js 事件、2022 年的 colors.js 和 faker.js 事件、2024 年的 xz-utils 后门——供应链攻击的频率和影响范围一直在升级。但 Axios 这次的投毒有几个特点值得注意：

第一，目标库的影响面极大。Axios 不是什么小众工具，它是 JavaScript 生态的基础设施级别的库。被投毒意味着全球范围内大量的 CI/CD 流水线都可能在不知情的情况下执行了恶意代码。

第二，攻击路径从「运行时」转向「构建时」。传统的恶意包攻击通常瞄准的是应用运行时——比如窃取用户的环境变量、上传敏感文件。但这次 Axios 投毒的影响更多体现在构建环节，也就是 CI/CD 流水线。构建环境通常拥有比运行时更高的权限：代码签名证书、部署密钥、云服务凭证……这些东西一旦泄露，后果远比窃取几个用户 token 严重。

第三，版本号伪装越来越精细。1.14.1 这个版本号不是随便起的，它精确地卡在了正常版本迭代的路径上，让自动化工具和人工审查都很难第一时间发现异常。

对开发者来说，这件事再次敲响了一个老生常谈但很多人仍然没做到的警钟：锁定你的依赖版本。

开发者该怎么做

不只是 OpenAI 的用户需要关注这件事。如果你的项目依赖了 Axios，以下几件事建议立刻检查：

1. 检查是否引入了投毒版本

# 检查项目中实际安装的 axios 版本
npm ls axios

# 如果看到 1.14.1 或 0.30.4，立即处理
# 降级到已知安全的版本
npm install axios@1.14.0

2. 锁定依赖版本

在 package.json 中，把 Axios 的版本范围改为精确版本：

{
  "dependencies": {
    "axios": "1.14.0"
  }
}

或者更好的做法是，确保你的 package-lock.json 或 yarn.lock 始终被提交到版本控制，并且 CI 中使用 npm ci 而不是 npm install：

# GitHub Actions 示例
steps:
  - name: Install dependencies
    run: npm ci  # 严格按照 lockfile 安装，不会自动升级

3. 审计 CI/CD 流水线的依赖安全

# 运行 npm 内置的安全审计
npm audit

# 如果使用 yarn
yarn audit

4. 考虑使用 Socket.dev 或类似工具

Socket.dev 可以在 PR 阶段检测依赖变更中的可疑行为（比如新增了网络请求、文件系统访问等），对供应链攻击的防御效果比单纯的漏洞扫描好得多。

对 API 调用者的影响

如果你是通过 API 调用 OpenAI 服务的开发者，这次事件对你没有直接影响——受影响的是 macOS 桌面应用的签名流程，不涉及 API 端点或服务端基础设施。

但这件事提醒了一个容易被忽视的点：你调用 AI API 的代码里，HTTP 客户端库本身也可能成为攻击面。

如果你在项目中用 Axios 调用 OpenAI 或其他 AI 模型的 API，确保你的 Axios 版本是安全的。比如通过 OpenAI Hub 调用模型时的典型代码：

import openai

client = openai.OpenAI(
    api_key="your-openai-hub-key",
    base_url="https://api.openai-hub.com/v1"
)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "解释一下 npm 供应链攻击的常见手法"}]
)

print(response.choices[0].message.content)

如果你用的是 Node.js，并且自己封装了 HTTP 请求而不是用官方 SDK：

// 确保 axios 版本安全
import axios from 'axios'; // 确认版本不是 1.14.1 或 0.30.4

const response = await axios.post(
  'https://api.openai-hub.com/v1/chat/completions',
  {
    model: 'claude-sonnet-4-20250514',
    messages: [{ role: 'user', content: '分析 Axios 供应链攻击的影响范围' }]
  },
  {
    headers: {
      'Authorization': 'Bearer your-openai-hub-key',
      'Content-Type': 'application/json'
    }
  }
);

console.log(response.data.choices[0].message.content);

OpenAI Hub 兼容标准 OpenAI 格式，所以无论你用 Python SDK 还是直接发 HTTP 请求，接口层面不受这次事件影响。但底层依赖的安全性，是每个开发者自己要把关的事。

更大的图景：AI 公司的软件供应链安全

这件事暴露的不只是一个依赖管理的疏忽，而是整个 AI 行业在快速迭代中积累的安全债务。

OpenAI 是全球估值最高的 AI 公司之一，工程团队的水平毋庸置疑。但即便是这样的团队，CI/CD 流水线中依然存在「配置缺陷」——这说明问题不在于能力，而在于优先级。

当所有人都在拼模型能力、拼产品迭代速度的时候，构建流程的安全加固很容易被排到后面。签名证书的管理、依赖版本的锁定、CI 环境的隔离——这些事情不性感，不会出现在发布会上，但一旦出问题，影响的是整个用户基础的信任。

值得肯定的是，OpenAI 这次的响应速度和透明度都不错。从发现问题到发布公告、撤换证书、与苹果协调拦截机制，整个流程在两周内完成。公告中也没有试图淡化问题的严重性，而是直接建议用户按「证书已泄露」的最坏情况来处理。

相比之下，很多公司在遇到类似事件时的第一反应是「先确认影响范围再说」，然后拖上几周甚至几个月才发公告。OpenAI 这次的做法，可以作为安全事件响应的一个正面案例。

时间线梳理

时间	事件
3 月 31 日	恶意版本 axios@1.14.1 被发布到 npm
3 月 31 日	OpenAI 的 GitHub Actions 工作流拉取并执行了恶意版本
4 月初	Axios 投毒事件被安全社区发现并公开
4 月 10 日	OpenAI 发布安全公告，启动证书撤换
5 月 8 日	macOS 开始拦截使用旧证书签名的 OpenAI 应用

写在最后

供应链安全不是新话题，但每次出事都能让人意识到，我们离「解决这个问题」还很远。npm 生态的信任模型建立在「维护者是可信的」这个假设上，而这个假设一次又一次被证明是脆弱的。

对于普通开发者，能做的事情其实很明确：锁定依赖版本、审计 CI/CD 配置、关注安全公告。这些事情不难，但需要养成习惯。

对于 macOS 上使用 OpenAI 应用的用户，现在就去更新。别等到 5 月 8 日应用打不开了才想起来。

参考来源：

IT之家：OpenAI 回应 Axios 工具安全事件，敦促苹果 Mac 用户更新 ChatGPT 等应用 — 事件详细报道及 OpenAI 官方公告内容
GitHub - tanjiti/sec_profile：安全资讯聚合 — 收录了 Axios npm 供应链投毒攻击的分析报告链接