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领域领导地位的原因。