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

依赖GitLab共享Runner构建和部署代码的开发人员像往常一样开始工作，但幕后却出现了严重问题。

2025年9月19日至22日期间，这些共享Runner遭到劫持——并非被外部僵尸网络控制，而是由于GitLab自身系统缺陷——被用于发动大规模拒绝服务（DoS）攻击。

事件经过

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

GitLab此前将相关漏洞归类为“提示性”风险，认为不会造成实际危害。但最严重的是，攻击利用共享Runner针对自托管GitLab实例——即企业自行管理的基础设施。

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

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

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

不仅共享Runner被利用，本应不可能受影响的自托管客户实例也面临风险。

对于受全球数千开发者和企业信任的平台，这不仅是小故障，更是对内部流程、监控和多租户基础设施安全运行基本假设的系统性崩溃。

部分客户受影响尤为严重。CERN遭受重创，导致GitLab服务中断近一周。

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

GitLab表示问题已彻底解决。漏洞已修补，Runner受到严格监控。企业客户获得了服务抵扣和直接支持。

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

尽管发生重大故障，GitLab的响应速度令人印象深刻。公司快速动员安全团队、聘请第三方取证专家并在事件全程保持空前透明，展现了科技界罕见的诚信水平。

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