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

共享Runner被用于攻击GitLab企业客户

对于依赖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领域领导地位的关键。