GitLab竟成僵尸网络——共享Runner如何引发大规模DoS攻击

共享Runner被用于对GitLab企业客户发起DoS攻击

对于依赖GitLab共享Runner构建和部署代码的开发人员来说，这原本是寻常的一天。但幕后，可怕的事情正在发生。

2025年9月19日至22日期间，这些共享Runner被劫持——不是被外部僵尸网络，而是因为GitLab自身系统的漏洞——用于发起大规模拒绝服务（DoS）攻击。

事件经过

是的，您没看错。本应让软件开发更快速、更可靠的基础设施，反而成了破坏源，向更广阔的互联网发送流量。

GitLab此前将相关漏洞归类为“提示性”，认为不会造成实际滥用。但最糟糕的是？报告显示攻击利用GitLab共享Runner瞄准了自托管GitLab实例——正是企业自行管理的基础设施。

对GitLab而言，这是噩梦般的场景：其云基础设施不仅被内部滥用，更成为破坏客户自有服务器的渠道。

自托管实例本应与供应商的共享环境隔离，而可能受影响的事实动摇了GitLab与企业客户之间的信任基础。原本应被控制在云内部的事件，突然变成了触及DevOps运营核心的广泛风险。

这是多层面的重大失败。GitLab的漏洞误分类、延迟检测和隔离控制不足共同造成了这场完美风暴。

不仅共享Runner被利用，自托管客户实例也面临风险——这本应是不可能发生的。对于受全球数千开发者和企业信任的平台而言，这不仅是小故障，更是系统性崩溃，对内部流程、监控以及多租户基础设施安全运行的基本假设提出了质疑。

部分客户受到较大影响。CERN遭受的打击尤为严重，导致GitLab服务中断近一周。

损害仍在评估中。企业客户可能受到影响，调查仍在进行，GitLab承诺将提供完整的事后分析。但有一点很明确：即使是可信供应商的多租户云基础设施，也可能被武器化——有时是以意想不到的方式。

GitLab表示问题现已完全解决。漏洞已打补丁，Runner受到严格监控。企业客户获得了服务积分和必要的直接支持。

据GitLab称，对检测、异常监控和Runner隔离的持续改进意味着平台现在更具韧性，上周发生的噩梦场景应不再可能重现。

尽管遭遇如此规模的失败，GitLab的响应速度令人印象深刻。公司快速动员安全团队、聘请第三方取证专家，并在事件全程保持前所未有的透明度，展现了科技界罕见的诚信水平。

通过公开沟通调查每个步骤、承认失误并详细说明修复计划，GitLab证明其既重视正常运行时间，也珍视信任。对于全球数千开发者和企业依赖的平台而言，这种速度、责任和透明的结合，正是重建信心、巩固GitLab在DevOps领域领导地位的关键。