GitLab沦为僵尸网络——共享Runner如何引发大规模DoS攻击
共享Runner被用于攻击GitLab企业客户
对于依赖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证明其既重视稳定运行更珍视客户信任。对于全球依赖该平台的开发者和企业而言，这种速度、责任与透明的结合，正是重建信心、巩固GitLab在DevOps领域领导地位的关键。
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）
公众号二维码
公众号二维码
