X记录空间2026 年 4 月 28 日，pnpm 11 发布，它拥有主流 JavaScript 包管理器中最强大的安全默认设置。
此次发布正值 npm 供应链遭受一系列攻击之后，其中包括最近的 TanStack 攻击和范围更广的 Mini Shai Hulud 攻击活动。
这两起事件都暴露了 GitHub Actions 工作流、CI/CD 流水线和自动化依赖安装方面的漏洞。
现代前端应用程序通常依赖于成百上千个传递的 npm 包，这使得依赖项安装成为供应链攻击最容易传播的地方之一。
TanStack攻击内部
该攻击利用了 GitHub Actions 工作流和 CI 信任边界的漏洞，发布了多个@tanstack/*软件包的恶意版本。
简而言之，攻击者能够污染 CI 缓存、泄露运行时令牌，并将恶意软件包直接发布到 npm。
TanStack官方事后总结（TLDR）。
2026年5月11日19:20至19:26 UTC期间，攻击者通过以下手段发布了42个@tanstack/* npm包的84个恶意版本：使用pull_request_target“Pwn Request”模式、利用fork↔base信任边界对GitHub Actions缓存进行投毒，以及从GitHub Actions运行进程中提取运行时内存中的OIDC令牌。此次攻击未窃取任何npm令牌，npm发布工作流本身也未被破坏。这些恶意版本在20分钟内被stepsecurity的外部研究员ashishkurmi公开发现。所有受影响的版本均已被弃用；npm安全团队已介入从注册表中拉取tar包。我们没有证据表明npm凭据被窃取，但我们强烈建议所有在2026年5月11日安装了受影响版本的用户轮换安装主机可访问的AWS、GCP、Kubernetes、Vault、GitHub、npm和SSH凭据。
pnpm 11 中的新安全默认设置
长期以来，软件包管理器主要以便捷性为优化目标：立即安装软件包、自动运行脚本，并默认信任外部来源。
pnpm 11 开始对一些既有假设进行调整，新的默认设置侧重于更安全的安装和更严格的依赖项验证。在早期的 pnpm 版本中，许多此类保护措施都是需要用户选择启用的。
以下是一些最大的变化：
minimumReleaseAge: 1440— 将新发布软件包的安装延迟 24 小时blockExoticSubdeps: true— 阻止有风险的非注册表依赖项strictDepBuilds: true— 收紧安装时构建行为verifyDepsBeforeRun: install— 执行前验证依赖关系
默认延迟安装新软件包
pnpm 11 现在默认会将新发布的软件包的安装延迟 24 小时。
minimumReleaseAge: 1440
软件包发布后的最初几个小时通常是风险最高的。延迟发布可以提供更多时间在恶意版本传播之前将其拦截。
以 TanStack 为例，由于延迟了 24 小时，受影响的版本根本就无法到达用户手中。
这将改变软件包的安装方式：
从install immediately
到allow time for ecosystem verification.
限制高风险依赖来源
另一个重大变化是默认情况下对特殊子依赖项的处理更加严格。
传统上，JavaScript 包管理器允许从 Git 仓库、tarball 和自定义注册表中引入依赖项，限制非常少。
例子：
{
"dependencies": {
"some-lib": "github:user/repository"
}
}
问题在于，这些来源不像 npm 注册表那样经过严格的审核和透明化，因此更难监控或审计。这使得它们更容易被滥用。
收紧安装脚本权限
依赖项不仅仅会向项目中添加代码。它们还可以通过脚本在安装过程中运行代码，例如postinstall……
pnpm 11 对此进行了大幅改进，将安装脚本的使用变成了用户明确选择启用的功能。
这样就堵住了恶意软件在安装过程中执行代码的最简单方法之一。如果某些软件包确实需要构建脚本，您可以显式地允许它们运行：
allowBuilds:
- esbuild
- sharp
要点总结
- pnpm 11 出厂时默认启用了多个以安全为中心的功能。
minimumReleaseAge将新发布的软件包的安装延迟 24 小时。- 一些新的默认设置旨在使常见的 npm 攻击更加困难。
- 包管理器在保障 JavaScript 应用安全方面正发挥着越来越重要的作用。
有关所有更改的完整列表，请参阅 pnpm 11 官方发行说明。
结论
pnpm 11 感觉像是对 npm 生态系统不断遭遇的各种攻击的回应。
在发生像 TanStack 安全漏洞这样的事件之后，这类变化很难被忽视。
