中II 网络战与关键基础设施2026年10月26日, 星期一
蠕虫借超大文件藏身，侵占42个GitHub仓库
JFrog在10月26日报告称，一个通过npm传播的蠕虫已侵入11个不同所有者名下的42个真实GitHub仓库。恶意封装体的体积被控制在12.9至13.7MB，以躲开GitHub的代码搜索。
JFrog研究人员在10月26日发布的报告中写道，一个通过npm软件包仓库传播的蠕虫已侵入11个不同所有者名下的42个真实GitHub仓库。运营者自己的账号另外还托管着17个活动仓库。仓库被劫持似乎是从9月开始的。
这场活动的特点在于体积。恶意封装体被保持在12.9到13.7MB之间，全部解出同一段隐藏的发布载荷。JFrog认为，正是这种刻意的膨胀，让此前能发现同类感染的GitHub代码搜索和API路径失去作用。
仓库里被植入了面向人工智能编码助手和开发环境的运行钩子，也就是工具一打开就自动执行代码的配置文件。加载器运行前会先寻找虚拟机、容器和调试器，一旦发现就静默退出。蠕虫会收集凭据，还带有一个组件，一旦被窃的GitHub令牌被吊销，它就删除受害者的主目录。
Talay 研判
结论
这场活动没有利用新漏洞，利用的是扫描基础设施的体积上限。把载荷膨胀到13MB，削弱防守的不是签名质量，而是规模限制；这是结构性缺口，补丁补不上。目标是开发者机器和持续集成流水线，意味着一次感染可能顺着下游软件包扩散。那个以删除来惩罚令牌吊销的组件，则是为了让受害者不敢动手清理。
可能影响
- 软件包仓库审查负面1至6个月
代码搜索和API路径跳过大文件，说明基于扫描的检测仍受体积阈值束缚，而这个阈值很容易越过。
- 开发者工具链负面数周内
在人工智能编码助手的配置文件里留下钩子，把每个克隆仓库的开发者都变成直接执行目标。
- 事件响应负面数周内
吊销被窃令牌会触发删除主目录的组件，机构若把清理顺序弄错就会丢数据。
可能情形（按概率排序）
- 1仓库出台体积规则40%
GitHub和npm把扫描范围扩大到大文件，或者在发布前加入体积检查。
观察指标: GitHub或npm关于代码搜索范围的公告
- 2活动继续扩散40%
同一运营者换用新包名继续作业，被劫持的仓库数量在11月增加。
观察指标: JFrog或SafeDep更新的仓库数量
- 3下游出现受害者20%
被劫持仓库之一供养了一个常用软件包，继而披露二次供应链事件。
观察指标: 某个流行npm软件包的投毒版本通告
概率是基于来源的校准判断，并非测量结果，会随新信息更新。不构成投资建议。
市场反应
受影响的指标
- 被武装的仓库▼ 42个
- 受影响的仓库所有者▼ 11个
- 封装体体积▼ 12.9–13.7MB
- 运营者自有仓库▼ 17个