一家安全研究公司周一报告称，已发现42个第三方GitHub代码库遭到入侵，攻击者在其中部署了体积足够大的负载文件，从而“逃避了通常用于发现此类入侵的GitHub搜索和API路径”。
JFrog安全研究团队的报告指出，受害代码库中包含针对AI编程助手和集成开发环境（IDE）的执行钩子，以及体积高达13.7MB的多态封装器，这些封装器“最终都解码为同一个隐藏的CI发布者负载。该攻击活动中攻击者所控制的代码库同时还充当着活跃的加密数据汇集点，接收快照信封数据，此次攻击还采用了一种新的伪装手段：一个不包含任何自身负载的已编译原生插件，它会在运行时解密一个名为.napi_cache的文件，从而揭示出真正的负载内容。”
JFrog表示，调查还发现了账户劫持、伪造的提交时间线、短期存在的发布分支以及泄露的npm凭证。同一被劫持所有者集群中的Shellpanel相关痕迹，将此次GitHub受害基础设施与此前报告过的针对面向互联网的cPanel系统的GitHub Actions攻击活动联系在了一起。
“10月21日期间，我们的扫描系统发出警报，在npm生态系统中发现了shai-hulud相关的恶意包，”JFrog写道。“SafeDep在10月22日的分析首次记录了此次活动中涉及npm包的部分，并解码了event-bus-lite-testmetest@0.0.1这一样本。SafeDep将该负载描述为Miasma家族成员，但同时明确表示对其具体来源存在不确定性。”
SafeDep最初认为，其发现的这一名为testmetest的攻击活动中所涉及的包，仅仅是威胁行为者的一次测试，但本周进一步发现了现有代码库已遭到恶意内容入侵的情况。
JFrog的报告还重点关注了npm攻击链所带来的影响。
“npm攻击链提供了连接到更广泛攻击活动的线索。恶意的testmetest版本利用binding.gyp命令扩展功能，在安装过程中执行index.js，即便这些包并未声明传统意义上的安装脚本，”该报告写道。“该加载程序对字符代码数组应用了逐版本变化的凯撒密码变换，解密出一个AES-128-GCM阶段的内容，并查找或下载Bun 1.2.18。根据具体版本的不同，解密后的负载会被管道传输至bun run命令执行，或写入一个临时的.b-*目录中，并在执行完成后被删除。完整的npm负载会收集凭证信息，污染代码库和CI配置，并通过包注册表进行传播。”
JFrog表示，那些由攻击者控制的代码库，充当了与之匹配的npm包的掩护项目来源。
“恶意版本发布传播了这一npm蠕虫，该蠕虫会窃取GitHub和npm凭证，而这些凭证可能被用于访问第三方代码库。在被劫持的代码库中，此次攻击活动留下了测试占位文件或已激活的负载，”研究人员写道。“对已激活的ci.js文件进行解码后发现，其中的发布程序被设计用于通过GitHub Actions运行，并利用npm令牌或可信发布机制生成更多恶意的testmetest版本发布，从而将包的分发反馈回代码库入侵环节，形成循环。”
JFrog的报告中提出了多种用于检测和缓解此类攻击的防御策略建议，其中包括建议首席信息安全官“应将完整蠕虫版本的安装视为主机已被入侵”。报告还建议用户撤销并轮换所有GitHub、GitLab、npm、PyPI、RubyGems、云服务、SSH、Vault、Kubernetes以及AI服务提供商相关的凭证，同时对“受影响身份可访问的所有代码库进行审计，检查是否存在.github/init.js、.claude/settings.json、.gemini/settings.json、.cursor/mcp.json、.cursor/rules/setup.mdc、.vscode/tasks.json文件，以及异常的composer.json或Makefile执行钩子，和带有skip-checks:true标记的提交记录。”
JFrog还建议企业直接枚举代码库文件树结构，并指出由于前述封装器文件体积问题，IT部门不应依赖GitHub代码搜索功能或内容API进行检测。
JFrog建议，“删除未经授权的chore/ci-*和deps/upd-*分支，禁用恶意工作流，移除名为scan-output的伪造CodeQL相关文件。在网络控制层面封锁hxxp[:]//43[.]228[.]157[.]68:80以及相关恶意基础设施”，并“在GitHub Actions日志和运行器中排查/tmp/.svc、ipscan、CVE-2026-41940、针对特定架构的/api/dl/<arch>请求，以及来自托管或自托管运行器的异常大范围扫描行为”。当然，还需要留意.napi.cache文件的存在。
鉴于GitHub代码库的高人气，其未来很可能仍将是攻击者的重点攻击目标。
总部位于纽约市的科技咨询公司Tribeca Softech首席战略官阿曼·马哈帕特拉表示，此次攻击的具体细节，很可能预示着未来一段时间内新型AI相关攻击的发展路径。
他说：“十年来，供应链威胁模型一直假定恶意代码会在用户安装或执行某个程序时运行。而此次攻击活动植入了Claude Code的SessionStart钩子、Gemini的配置文件、Cursor的MCP配置及相关规则，以及VS Code的文件夹打开任务，这意味着只要开发者在其工具中打开相关代码库，负载就会运行。.claude/settings.json已经成为了新时代的autorun.inf文件。”
马哈帕特拉表示：“攻击者已经将触发点从‘运行代码’转移到了‘打开文件夹’，他们精心设计了能够从设计层面逃避沙箱检测的恶意软件，并将整个行业此前采取的最终修复方案，变成了下一个攻击目标。那些围绕安装时扫描构建的供应链防御体系，如今防范的早已不是正确的时机点了。”
他还表示，自己对攻击者所采用的文件体积伪装策略尤为担忧。
马哈帕特拉说：“这些13MB大小的封装器还采用了一种更为粗暴的手段。它们的体积超过了GitHub代码搜索功能所能索引的范围，也超过了内容API所能返回的内容范围，这正是早期分析能发现相关钩子，却误判负载文件为空文件的原因所在。攻击者显然研究过贵方检测工具的文档说明，并刻意将文件体积填充至超出其检测限制。”
Dickson Research首席分析师弗兰克·迪克森表示，他对攻击者使用原生插件的手法也印象深刻。
他说：“这个插件本身不携带任何负载，并且会拒绝在CI系统、容器环境、小型虚拟机，或处于调试器监控状态下运行。在Windows系统中，若检测到Wireshark或Process Monitor正在运行，它同样会停止运行。扫描工具看到的只是一个占位程序，而开发者的笔记本电脑上运行的才是真正的恶意程序。”
迪克森表示，此次攻击确实涉及AI相关风险，但这属于次要风险敞口，只有当攻击者窃取到有效凭证后才会真正显现。不过，由于智能体相关应用的普及，这一风险的严重性有所上升。
迪克森说：“此次植入的文件是针对Claude、Gemini、Cursor以及VS Code的执行钩子。在受支持的工具中打开一个项目，就可能触发负载运行。开发者的一次常规操作，就会变成攻击的引爆点。可以说，开发者的笔记本电脑掌握着‘王国的钥匙’：包括GitHub令牌、npm令牌、云服务密钥以及AI服务提供商的凭证。攻击者已经找到了一种获取这些凭证的新方式。”“客观来说，这些钩子本身属于正常功能，而非安全缺陷。此次事件的根本原因在于凭证被窃取，而非AI工具本身存在问题。但即便如此，一个‘打开文件夹就会运行代码’的功能，理应受到与构建脚本同等严格的安全审查。”
