文章总结： 这篇文章详细描述了Trigger.dev公司遭受Shai-Hulud2.0供应链攻击的全过程，包括入侵途径、17小时的侦察阶段和10分钟的破坏性攻击。攻击者通过恶意npm软件包窃取了工程师的GitHub凭证，导致199个分支被强制推送，42个PR被关闭。公司通过快速响应和全面恢复措施控制了损失，并采取了禁用npm脚本、升级pnpm10、启用分支保护等防御措施。文章提供了关于供应链攻击防御的实用建议，包括使用OIDC进行npm发布、限制新软件包安装时间等。
综合评分： 95
文章分类： 应急响应,供应链安全,漏洞分析,威胁情报,安全建设
亲身遭遇 Shai-Hulud 攻击后的完整事件复盘
Dubito
云原生安全指北
2025年12月3日 08:35
江苏
注：本文翻译自trigger.dev的文章《How we got hit by Shai-Hulud: A complete post-mortem》[1]，可点击文末“阅读原文”按钮查看英文原文。
全文如下：
一、引言
2025年11月25日，我们正像往常一样在Slack上进行日常线上会议，调试一个生产环境问题。这时我们注意到一件怪事：内部代码库中一个PR突然被关闭，显示零更改，并且只有一个提交记录，提交者竟然是……Linus Torvalds？
提交信息只有 “init”。
几秒钟内，我们的 #git Slack 频道就被通知消息淹没。数十次强制推送（force-pushes）。多个代码仓库中的PR被关闭。所有操作都归因于我们的一位工程师。
我们遭受了 Shai-Hulud 2.0[2] 的攻击，这是一个复杂的 npm 供应链蠕虫，它入侵了超过500个软件包，影响了25,000多个代码库，并在整个JavaScript生态系统中传播。我们并非孤例：PostHog[3]、Zapier、AsyncAPI、Postman 和 ENS 也在受影响之列。
以下是我们所经历事件的完整过程、我们的应对措施，以及我们为防止此类事件再次发生所做出的改变。
Trigger.dev 的所有软件包均未受损。
@trigger.dev/*软件包和trigger.devCLI 从未感染 Shai-Hulud 恶意软件。本次事件源于我们的一位工程师在其开发机器上安装了一个受感染的软件包，导致凭证被盗，攻击者获得了对我们GitHub组织的未授权访问。我们已发布的软件包在整个过程中始终保持安全。
二、攻击时间线
| 时间 (UTC) | 事件 |
| — | — |
| 11月24日 04:11 | 恶意软件包上线 |
| 11月24日 ~20:27 | 工程师机器被入侵 |
| 11月24日 22:36 | 攻击者首次活动 |
| 11月25日 02:56-05:32 | 夜间侦察活动 |
| 11月25日 09:08-15:08 | 工程师正常工作（来自德国） |
| 11月25日 09:10-09:17 | 攻击者监控工程师活动 |
| 11月25日 15:17-15:27 | 最终侦察 |
| 11月25日 15:27-15:37 | 破坏性攻击 |
| 11月25日 ~15:32 | 检测到攻击 |
| 11月25日 ~15:36 | 访问权限被撤销 |
| 11月25日 16:35 | AWS 会话被阻止 |
| 11月25日 22:35 | 所有分支恢复 |
| 11月26日 20:16 | GitHub App 密钥轮换 |
三、入侵过程
11月24日晚，大约在UTC时间20:27（德国当地时间晚上9:27），我们的一位工程师正在试验一个新项目。他运行了一个触发 pnpm install 的命令。就在那一刻，依赖树中的某个恶意软件包执行了。
我们无法确切知道是哪一个软件包执行了恶意负载。该工程师当时正在进行实验，并可能在清理过程中删除了项目目录。等我们开始调查时，已无法追溯到具体的软件包。工程师检查了他的shell历史记录，他只在我们主要的 trigger 仓库、cloud 仓库和一个实验性项目中运行过 install 命令。
这就是此类攻击令人沮丧的现实之一：一旦恶意软件运行，追溯其源头就变得极其困难。该软件包不会自我宣告。pnpm install 会顺利完成。一切看起来都正常。
我们所知道的是，Shai-Hulud 恶意软件运行了一个 preinstall 脚本，该脚本：
- 1. 下载并执行 TruffleHog[4]，这是一款合法的安全工具，但被篡改用于窃取凭证。
- 2. 扫描工程师机器上的敏感信息（secrets）：GitHub令牌、AWS凭证、npm令牌、环境变量等。
- 3. 将所有发现的凭证外泄。
后来，当工程师从被入侵的笔记本电脑（在恢复模式下启动）中恢复文件时，他发现了确凿的证据：
在被入侵机器上发现的 TruffleHog 残留文件
在被入侵的机器上发现了 .trufflehog-cache 目录和 trufflehog_3.91.1_darwin_amd64.tar.gz 文件。extract 目录是空的，很可能被恶意软件清理过以掩盖痕迹。
四、长达17小时的侦察
在采取任何可见行动之前，攻击者已能访问我们工程师的 GitHub 账户长达17小时。根据我们的 GitHub 审计日志，他们的操作非常有条理。
在最初的入侵发生约两小时后，攻击者验证了他们窃取的凭证，并开始大规模克隆：
| 时间 (UTC) | 地理位置 | 活动 |
| — | — | — |
| 22:36:50 | 美国 | 首次攻击者访问，开始大规模克隆 |
| 22:36-22:39 | 美国 | 克隆了73个仓库 |
| 22:48-22:50 | 美国 | 克隆了约70个仓库（第二波） |
| 22:55-22:56 | 美国 | 克隆了约90个仓库（第三波） |
| 22:59-23:04 | 美国 | 克隆了约70个仓库（第四波） |
| 23:32:59 | 印度 | 攻击者切换到位于印度的基础设施 |
| 23:32-23:37 | 印度 | 克隆了73个仓库 |
| 23:34-23:35 | 美国 + 印度 | 同时从两个地理位置进行克隆 |
同时来自美国和印度的活动证实，我们是在与一个使用多个VPN或服务器的单一攻击者打交道，而非多个独立攻击者。
当我们的工程师在德国睡觉时，攻击者继续进行侦察。在UTC时间02:56-02:59（德国凌晨）进行了更多克隆，零星活动一直持续到UTC时间05:32。总计克隆的仓库数：669个（527个来自美国基础设施，142个来自印度）。
接下来发生的情况令人不安。我们的工程师醒来，开始了正常工作：
| 时间 (UTC) | 操作者 | 活动 |
| — | — | — |
| 09:08:27 | 工程师 | 在 cloud 仓库触发工作流（来自德国） |
| 09:10-09:17 | 攻击者 | 从美国进行 Git fetch 操作，监控工程师活动 |
| 09:08-15:08 | 工程师 | 正常的PR审查、CI工作流（来自德国） |
攻击者在工程师工作时监控着他的活动，而工程师对此毫不知情。
在此期间，攻击者创建了以随机字符串命名的仓库来存储窃取的凭证，这是已知的 Shai-Hulud 模式：
- •
github.com/[username]/xfjqb74uysxcni5ztn - •
github.com/[username]/ls4uzkvwnt0qckjq27 - •
github.com/[username]/uxa7vo9og0rzts362c
他们还创建了三个以 “Sha1-Hulud: The Second Coming” 为标记的仓库作为名片。当我们检查时，这些仓库是空的，但根据记录的 Shai-Hulud 行为，它们很可能包含经过三重 base64 编码的凭证。
五、十分钟的破坏
11月25日UTC时间15:27，攻击者从侦察阶段转向了破坏阶段。
攻击从我们的 cloud 仓库开始，基于印度基础设施：
| 时间 (UTC) | 事件 | 仓库 | 详情 |
| — | — | — | — |
| 15:27:35 | 首次强制推送 | triggerdotdev/cloud | 攻击开始 |
| 15:27:37 | PR关闭 | triggerdotdev/cloud | 关闭了 PR #300 |
| 15:27:44 | 被阻止 | triggerdotdev/cloud | 分支保护规则拒绝了强制推送 |
| 15:27:50 | PR关闭 | triggerdotdev/trigger.dev | 关闭了 PR #2707 |
攻击继续在我们的主仓库进行：
| 时间 (UTC) | 事件 | 详情 |
| — | — | — |
| 15:28:13 | PR关闭 | triggerdotdev/trigger.dev PR #2706 (发布PR) |
| 15:30:51 | PR关闭 | triggerdotdev/trigger.dev PR #2451 |
| 15:31:10 | PR关闭 | triggerdotdev/trigger.dev PR #2382 |
| 15:31:16 | 被阻止 | 分支保护规则拒绝了对 trigger.dev 的强制推送 |
| 15:31:31 | PR关闭 | triggerdotdev/trigger.dev PR #2482 |
在UTC时间15:32:43-46，jsonhero-web 上的12个PR在3秒内被关闭。这显然是自动化的。PR #47, #169, #176, #181, #189, #190, #194, #197, #204, #206, #208 都在3秒内被关闭。
我们的关键基础设施仓库成为下一个目标：
| 时间 (UTC) | 事件 | 详情 |
| — | — | — |
| 15:35:41 | PR关闭 | triggerdotdev/infra PR #233 |
| 15:35:45 | 被阻止 | 分支保护规则拒绝了强制推送（印度） |
| 15:35:48 | PR关闭 | triggerdotdev/infra PR #309 |
| 15:35:49 | 被阻止 | 分支保护规则拒绝了强制推送（印度） |
最后一个PR于UTC时间15:37:13在 json-infer-types 仓库被关闭。
六、检测与响应
我们很幸运。当通知消息如潮水般涌来时，我们的一位团队成员正好在监控Slack：
攻击期间我们的 #git Slack 频道。一整面的强制推送通知，所有提交信息都是 “init”。
每个恶意提交的作者信息都显示为：
Author: Linus Torvalds <[email protected]>
Message: init
一个被攻击的分支：一个归因于 Linus Torvalds 的 “init” 提交，落后主分支数千个提交。
我们尚未发现其他 Shai-Hulud 受害者报告了相同的 “Linus Torvalds” 破坏模式。该蠕虫记录的行为侧重于凭证外泄和 npm 软件包传播，而非仓库破坏。这种破坏阶段可能是攻击者独有的行为，也可能是自动化蠕虫完成凭证收集后的人工后续操作。
在检测到攻击的4分钟内，我们识别出被入侵的账户，将其从 GitHub 组织中移除，攻击随即停止。
以下是事发最初几分钟我们内部Slack的对话：
“呃，伙计们？发生什么事了？”
“把我加到通话里 @here”
“Nick，你能在 Infisical 里再检查一下是否有任何机器身份凭证吗？”
“有人能查一下我们的 CLI 依赖中有没有软件包被入侵的报告吗？”
一小时内我们采取了以下行动：
| 时间 (UTC) | 行动 |
| — | — |
| ~15:36 | 从 GitHub 组织中移除 |
| ~15:40 | 从 Infisical（secrets管理器）中移除 |
| ~15:45 | 从 AWS IAM Identity Center 中移除 |
| ~16:00 | 从 Vercel 和 Cloudflare 中移除 |
| 16:35 | 通过拒绝策略阻止了 AWS SSO 会话（无法直接撤销会话） |
| 16:45 | 删除了 IAM 用户的控制台登录权限 |
七、造成的损害
仓库克隆操作：669次（包括公共和私有仓库），涉及基础设施代码、内部文档和工程计划。
分支被强制推送：16个仓库中的199个分支。
PR请求（Pull Requests）被关闭：42个。
受保护分支拒绝操作：4次。我们部分仓库启用了主分支保护，但事件发生时并非所有仓库都开启。
npm软件包未被入侵。这是“我们的仓库遭到破坏”和“我们的软件包被入侵”之间的关键区别。
我们的工程师机器上没有npm发布令牌（publishing token），即使有，我们也早已要求发布到npm需进行双重身份验证（2FA）。若非如此，Shai-Hulud 很可能已经发布了 @trigger.dev/sdk、@trigger.dev/core 等软件的恶意版本，可能影响数千下游用户。
生产数据库或任何AWS资源未被访问。我们的 AWS CloudTrail 审计日志显示，被入侵的账户只进行了读取操作：
| 事件类型 | 次数 | 服务 |
| — | — | — |
| ListManagedNotificationEvents | ~40 | notifications |
| DescribeClusters | 8 | ECS |
| DescribeTasks | 4 | ECS |
| DescribeMetricFilters | 6 | CloudWatch |
经确认，这些是我们的工程师进行的合法操作。
一个意外的惊喜是：AWS 实际上就 Shai-Hulud 向我们发送了主动告警。他们在一个数月未使用的旧测试账户上检测到了该恶意软件的典型行为（ListSecrets、GetSecretValue、BatchGetSecretValue API调用），我们随后删除了该账户。但 AWS 的主动检测和通知值得称赞。
八、恢复过程
GitHub 没有服务器端的引用日志（reflog）。当有人进行强制推送（force-push）时，相关历史记录就会从 GitHub 服务器上消失。
但我们找到了恢复的方法。
通过 GitHub Events API 找回提交：推送事件（Push events）会在 GitHub Events API 中保留90天。我们编写了一个脚本来获取攻击前的提交 SHA：
# Find pre-attack commit SHA from events
gh api repos/$REPO/events --paginate | \
jq -r '.[] | select(.type=="PushEvent") |
select(.payload.ref=="refs/heads/'$BRANCH'") |
.payload.before' | head -1
利用公共仓库的forks：公共仓库的fork仍然包含原始提交。我们利用这些来验证和恢复分支。
利用本地引用日志（local reflog）：没有运行过 git fetch --prune 的开发人员（我们所有人？）在本地引用日志中仍然保存着旧的 SHA。
在7小时内，所有199个分支都得到了恢复。
九、GitHub App 私钥泄露
在调查期间，我们的工程师检查了从被入侵笔记本电脑中恢复的文件，并发现了一个令人担忧的情况：我们 GitHub App 的私钥位于回收站文件夹中。
当你在 GitHub App 设置中创建私钥时，GitHub 会自动下载它。这位工程师在某个时间点创建过一个密钥，虽然活动文件已被删除，但它仍留在垃圾桶里，TruffleHog 有可能访问到它。
我们的 GitHub App 在客户仓库上拥有以下权限：
| 权限 | 访问级别 | 风险 |
| — | — | — |
| contents | 读/写 | 可以读取/写入仓库内容 |
| pull_requests | 读/写 | 可以读取/创建/修改 PR |
| deployments | 读/写 | 可以创建/触发部署 |
| checks | 读/写 | 可以创建/修改检查运行（check runs） |
| commit_statuses | 读/写 | 可以将提交标记为通过/失败 |
| metadata | 读 | 可以读取仓库元数据 |
要生成有效的访问令牌（access tokens），攻击者需要同时拥有私钥（可能已泄露）和特定客户的安装ID（installation ID）。安装ID存储在我们的数据库中，并未泄露，且不在被入侵的机器上。
我们立即轮换了密钥：
| 时间 (UTC) | 行动 |
| — | — |
| 11月26日 18:51 | 在回收站文件夹中发现私钥 |
| 11月26日 19:54 | 新密钥部署到测试环境 |
| 11月26日 20:16 | 新密钥部署到生产环境 |
我们未发现任何未经授权访问客户仓库的证据。如前所述，攻击者需要从我们的数据库获取安装ID才能生成令牌，而我们的数据库并未被入侵。
然而，我们无法完全排除这种可能性。理论上，拥有私钥的攻击者可以调用 GitHub API 来枚举所有安装项。我们已经联系了 GitHub 支持，请求提供额外的访问日志。我们还分析了发送到我们 GitHub App 的 Webhook 有效载荷，查找来自已连接安装项和仓库的可疑推送或 PR 活动。在这些 Webhook 有效载荷中，我们尚未发现任何未经授权活动的证据。
我们已向可能受影响的客户发送了邮件，通知他们此次事件，并附上了如何检查是否受影响的详细说明。如果您使用过我们的 GitHub App，请检查您的邮件以获取更多详情。
十、技术剖析：Shai-Hulud 如何运作
对于那些对技术细节感兴趣的读者，以下是我们从 Socket的分析报告[2] 以及我们自己的调查中了解到的关于该恶意软件的信息。
当 npm 运行 preinstall 脚本时，它会执行 setup_bun.js：
- 1. 检测操作系统/架构。
- 2. 下载或定位 Bun[5] 运行时。
- 3. 将 Bun 缓存到
~/.cache目录。 - 4. 启动一个后台运行的、输出被抑制的独立 Bun 进程，执行
bun_environment.js。 - 5. 立即返回，使
npm install顺利完成且不产生任何警告。
在你以为一切正常时，恶意软件已在后台运行。
该有效负载使用 TruffleHog 扫描 $HOME 目录，寻找：
- • GitHub 令牌（来自环境变量、gh CLI 配置、git 凭证助手）。
- • AWS/GCP/Azure 凭证。
- • 来自
.npmrc的 npm 令牌。 - • 包含任何类似敏感信息的环境变量。
- • GitHub Actions 的敏感信息（如果在 CI 中运行）。
窃取的凭证会被上传到一个新创建的、使用随机名称的 GitHub 仓库。数据经过三重 base64 编码，以规避 GitHub 的敏感信息扫描。
创建的文件包括：
- •
contents.json（系统信息和 GitHub 凭证）。 - •
environment.json（所有环境变量）。 - •
cloud.json（云服务提供商凭证）。 - •
truffleSecrets.json（来自 TruffleHog 的文件系统secrets）。 - •
actionsSecrets.json（GitHub Actions 敏感信息，如果有）。
如果发现 npm 发布令牌（publishing token），恶意软件会：
- • 向 npm 注册表验证该令牌。
- • 获取该账户维护的所有软件包。
- • 下载每个软件包。
- • 使用恶意软件打补丁。
- • 提升版本号。
- • 重新发布，从而感染更多软件包。
这就是该蠕虫如何在 npm 生态系统中传播的方式，始于 PostHog被入侵的 CI[3]（UTC时间11月24日凌晨4:11）。我们的工程师在恶意软件包上线大约16小时后被感染。
如果没有找到可窃取或传播的凭证，恶意软件会试图删除受害者的整个home目录。彻底摧毁一切。
需要注意的文件残留痕迹：setup_bun.js、bun_environment.js、cloud.json、contents.json、environment.json、truffleSecrets.json、actionsSecrets.json、.trufflehog-cache/ 目录。
恶意软件文件哈希值（SHA1）：
- •
bun_environment.js：d60ec97eea19fffb4809bc35b91033b52490ca11 - •
bun_environment.js：3d7570d14d34b0ba137d502f042b27b0f37a59fa - •
setup_bun.js：d1829b4708126dcc7bea7437c04d1f10eacd4a16
我们已发布一个 检测脚本[6]，用于检查是否存在 Shai-Hulud 的迹象。
十一、我们做出的改变
我们全局禁用了 npm 脚本：
npm config set ignore-scripts true --location=global
这会阻止 preinstall、postinstall 及其他生命周期脚本的运行。虽然有些激进，部分软件包可能会因此出错，但这是防御此类攻击唯一可靠的方法。
我们升级到了 pnpm 10。 这耗费了很大精力（必须先从 pnpm 9 迁移），但 pnpm 10 带来了关键的安全改进：
- • 默认忽略脚本。
- • 可以通过
pnpm.onlyBuiltDependencies明确地将需要运行脚本的软件包加入白名单。 - •
minimumReleaseAge设置可以防止安装最近发布的软件包。
# pnpm-workspace.yaml
minimumReleaseAge: 4320 # 3 days in minutes
preferOffline: true
将真正需要构建脚本的软件包加入白名单：
pnpm approve-builds
这会提示你选择允许哪些软件包（如 esbuild、prisma、sharp）。
对于你的全局 pnpm 配置：
pnpm config set minimumReleaseAge 4320
pnpm config set --json minimumReleaseAgeExclude '["@trigger.dev/*", "trigger.dev"]'
我们将 npm 发布切换为 OIDC 方式。 不再在任何地方使用长期有效的 npm 令牌。现在，发布操作使用 npm 可信发布者[7] 功能，结合 GitHub Actions OIDC。即使攻击者入侵了开发者的机器，他们也无法发布软件包，因为没有可窃取的凭证。发布只能通过 CI 进行，使用的是短期的、作用域限定的令牌。
我们在所有代码仓库启用了分支保护。 不仅仅是关键仓库或开源仓库。所有包含重要代码的仓库现在都已启用分支保护。
我们已采用 Granted[8] 来管理 AWS SSO。与 AWS CLI 以明文存储 SSO 会话令牌不同，Granted 在客户端加密这些令牌。
基于 PostHog 的分析报告[3] 关于他们最初如何被入侵（通过 pull_request_target），我们审查了所有的 GitHub Actions 工作流。我们现在要求，在我们所有仓库上运行外部贡献者的工作流都必须经过审批（之前的政策仅针对公共仓库）。
十二、对其他团队的启示
软件包在安装期间运行任意代码的能力就是攻击面。在 npm 做出根本性改变之前，请将以下配置添加到你的 ~/.npmrc 文件中：
ignore-scripts=true
是的，有些东西会因此出错。请将它们明确加入白名单。这点不便是非常值得的。
pnpm 10 默认忽略脚本，并允许你为软件包设置最短发布时间限制：
pnpm config set minimumReleaseAge 4320 # 3 days
新发布的软件包在3天内无法被安装，这为检测恶意软件包提供了时间。
分支保护只需30秒即可启用。它可以阻止攻击者向主分支推送，从而可能阻止恶意 GitHub Action 工作流的执行。
开发机器上的长期 npm 令牌是一种负担。应改用支持 OIDC 的可信发布者[7]功能。
如果你本地机器上不需要某个凭证，就不要把它放在那里。发布操作应仅通过 CI 进行。
我们的 #git Slack 频道很嘈杂。正是这种嘈杂（的实时通知）救了我们。
十三、关于人性的一面
这次事件中最艰难的部分之一，是它发生在一个真实的人身上。
“对不起给大家带来这么多麻烦，这是一次可怕的经历”
我们被入侵的工程师感到非常难过，尽管他绝对没有做错任何事。这可能发生在任何一位团队成员身上。
运行 npm install 并非疏忽。安装依赖项也不是安全失误。真正的安全失误在于一个允许软件包静默运行任意代码的生态系统。
他们还发现，攻击者在入侵期间，用他们的 GitHub 账户给数百个随机仓库点了star。甚至有人发邮件给我们说：”嘿，你给我仓库加了星标，但我想是因为你的账户被黑了，也许可以取消这个星标？”
十四、总结
| 指标 | 数值 |
| — | — |
| 从入侵到首次攻击者活动的时间 | ~2小时 |
| 攻击者进行破坏性操作前的访问时长 | ~17小时 |
| 破坏性攻击持续时间 | ~10分钟 (15:27-15:37 UTC) |
| 从首次恶意推送到检测到的时间 | ~5分钟 |
| 从检测到撤销访问权限的时间 | ~4分钟 |
| 完全恢复所有分支的时间 | ~7小时 |
| 攻击者执行仓库克隆操作的次数 | 669次 |
| 被强制推送的仓库数量 | 16个 |
| 受影响的分支数量 | 199个 |
| 被关闭的拉取请求数量 | 42个 |
| 被保护分支拒绝的操作次数 | 4次 |
十五、参考资料
关于此次攻击：
- • Socket.dev: Shai-Hulud Strikes Again V2[2] – 关于该恶意软件的技术深度分析
- • PostHog 事后分析报告[3] – 另一家公司经历 Shai-Hulud 的经验
- • Wiz 博客: Shai-Hulud 2.0 供应链攻击[9]（译文详见Shai-Hulud 供应链攻击：25k+仓库沦陷，密钥大规模泄露）
- • The Hacker News 新闻报道[10]
- • Endor Labs 分析报告[11]
- • HelixGuard 安全公告[12]（AWS 告警中提及）
缓解措施资源：
- • npm 可信发布者[7] – 基于 OIDC 的发布
- • pnpm onlyBuiltDependencies[13] – 允许运行脚本的软件包白名单
- • pnpm minimumReleaseAge[14] – 延迟安装新发布的软件包
- • Granted[8] – AWS SSO 凭证管理工具
引用链接
[1] 《How we got hit by Shai-Hulud: A complete post-mortem》: https://trigger.dev/blog/shai-hulud-postmortem
[2] Shai-Hulud 2.0: https://socket.dev/blog/shai-hulud-strikes-again-v2
[3] PostHog: https://posthog.com/blog/nov-24-shai-hulud-attack-post-mortem
[4] TruffleHog: https://github.com/trufflesecurity/trufflehog
[5] Bun: https://bun.sh/
[6] 检测脚本: https://gist.github.com/ericallam/e2ae497d99a21d500fd9fbb01e1bfa02
[7] npm 可信发布者: https://docs.npmjs.com/trusted-publishers
[8] Granted: https://docs.commonfate.io/granted/introduction
[9] Wiz 博客: Shai-Hulud 2.0 供应链攻击: https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack
[10] The Hacker News 新闻报道: https://thehackernews.com/2025/11/second-sha1-hulud-wave-affects-25000.html
[11] Endor Labs 分析报告: https://www.endorlabs.com/learn/shai-hulud-2-malware-campaign-targets-github-and-cloud-credentials-using-bun-runtime
[12] HelixGuard 安全公告: https://helixguard.ai/blog/malicious-sha1hulud-2025-11-24
[13] pnpm onlyBuiltDependencies: https://pnpm.io/package_json#pnpmonlybuiltdependencies
[14] pnpm minimumReleaseAge: https://pnpm.io/settings#minimumreleaseage
交流群
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云原生安全指北 Dubito《亲身遭遇 Shai-Hulud 攻击后的完整事件复盘》