2025年8月26日,JavaScript开发社区经历了一次震惊整个生态系统的安全事件。广受欢迎的Nx构建系统因GitHub Actions工作流中的漏洞而遭受攻击,导致数千条敏感凭证被盗,攻击者利用这次入侵成功窃取了NPM发布令牌,并借助这些令牌发布了带有恶意代码的版本包。这场事件不仅暴露了开源项目在供应链安全中的薄弱环节,也推动了Nx团队将包发布机制彻底迁移到NPM刚刚推出的Trusted Publishers平台,标志着整个npm发布生态的一场变革。此次安全事件是一次警醒,揭示了在CI/CD流程中长寿命令牌面临的巨大风险,同时突显了利用现代AI助手加速攻击的手法新趋势。 这场攻击的核心原因是GitHub Actions工作流中的两个关键漏洞。首先,在Nx项目的CI管道中用于验证拉取请求标题的bash脚本存在注入风险。
由于工作流的pull_request_target触发器会在目标仓库权限环境中运行,该漏洞允许攻击者通过特制的PR标题执行任意bash代码,直接调用恶意命令。更复杂的是,pull_request_target触发器默认授予GITHUB_TOKEN对仓库的读写权限,这意味着恶意代码一旦被注入便能获取包括读写代码库和CI资源的全面权限。 其二,攻击者利用了GitHub分支管理上的一个逻辑缺陷。虽然Nx核心团队于8月22日迅速在主分支修复了这一漏洞,但旧的过时分支因未及时同步仍保留了风险代码。攻击者主动向这些过时分支提交恶意拉取请求,导致漏洞再次被利用,逃过了主分支的补丁限制。这种基于分支版本差异的攻击展现出开源项目维护中的深层隐患:修补主分支风险远远不够,还必须确保所有活跃分支同步安全策略,否则修复工作形同虚设。
攻击链最终导致被盗GITHUB_TOKEN被用来触发负责发布的publish.yml工作流,后者携带着敏感的NPM令牌。攻击者利用该令牌发布了具有破坏性的恶意Nx包,影响范围广泛,波及数千个依赖Nx系统的开源及企业项目。事件暴露出CI/CD流程中凭证管理和权限分配方面的重大不足,尤其是依赖长期有效的NPM令牌极易引发集中风险,持续暴露在外的令牌犹如悬顶利剑,一旦落入歹手,所能造成的破坏不可估量。 为遏制事件造成的进一步恶化,Nx团队于8月27日迅速采取了断然措施,将所有Nx相关的NPM包发布机制转移至NPM最新推出的Trusted Publishers机制。该机制基于OpenID Connect(OIDC)协议,通过建立加密信任链条,取代传统长期令牌,改用短暂且针对单次发布流程生成的临时凭证。这意味着发布权限被严格限定在授权的GitHub Actions工作流内,每次发布都自动附带溯源证明,使令牌盗用风险大幅降低。
与此同时,Nx团队对所有旧分支进行了彻底的版本更新,确保脆弱工作流不会在任何分支中残留。此外,新增了外部贡献者提交的管道执行审批流程,以阻挡未授权代码的自动执行。引入了CodeQL静态分析工具,聚焦捕获类似的代码注入及权限误用漏洞,力图从根本上提前识别潜在安全隐患。所有关联的GitHub密钥均完成了全方位旋转,哪怕未被证实受损也一律更新,体现了防患未然的安全思维。 此次安全事件还影响到了Nx Console VS Code扩展版本,部分旧版本扩展会自动安装被恶意篡改的Nx版本,加剧影响范围。Nx团队迅速发布新版18.66.0修复了该安全漏洞,防止感染进一步蔓延。
整个事件过程,Nx团队保持了高度的透明和沟通,及时更新调查进展,通过社交平台与社区合作,体现了开源项目在危机应对中的最佳操作典范。 Nx事件暴露的最大教训在于,供应链安全不能只依赖单一层面的补丁和令牌保护。CI/CD流水线的设计需全盘审视权限边界,尤其要警惕默认触发器权限的隐蔽提升。长期令牌的使用应被替换为更加安全的基于身份认证和即时凭证的架构。所有分支的同步安全和持续监控同样不可忽视。来自安全研究者的公开披露既带来压力,更创造了被攻击利用的窗口,如何快速响应及补丁全面落地成为关键。
此次事件的爆发与解决过程还体现了现代攻击者如何借助AI及自动化开发工具加速侦察与漏洞利用,令传统安全防护面临巨大挑战。开源社区及企业需进一步加固安全态势感知能力,结合AI辅助的防御手段,构筑更加灵活与智能的防御体系。Nx团队迅速引入Trusted Publishers以及CodeQL等工具,正是朝向自动化安全保障迈出的重要一步。 总结来看,Nx的GitHub Actions工作流漏洞事件是一场惊心动魄的供应链安全危机,影响波及海量软件项目。它揭示了CI/CD工作流中权限过度暴露与旧版本管理疏漏的致命风险,也促使业界转向更加安全的发布认证模式及全方位、主动的安全防护体系。面对日益复杂且自动化的攻击手法,只有持续强化身份认证,提升自动检测与响应能力,才能在下一次攻击浪潮中保持主动,守护好开源软件及整个生态的安全。
。
