官网：http://securitytech.cc/
GitLab 变成僵尸网络 —— GitLab 的共享 Runner 如何引发一次大规模 DoS 攻击
共享 Runner 被用来对 GitLab 企业客户发起 DoS 攻击
对依赖 GitLab 共享 Runner 来构建和部署代码的开发者来说，一天的开始看似与往常无异。但在幕后，却发生了一件可怕的事。
在 2025 年 9 月 19 日到 22 日 之间，这些共享 Runner 被滥用——不是外部僵尸网络，而是 GitLab 自身系统中的一个漏洞——发动了一次大规模的拒绝服务（DoS）攻击。
事件经过
没错，你没看错。本该让软件开发更快、更可靠的基础设施，竟成了制造混乱的源头，把流量抛向整个互联网。
根本原因？
一个曾经被 GitLab 归类为“信息型（informative）”的漏洞，原本不应该造成任何实际危害。
但最糟糕的是？报告显示，这次攻击利用了 GitLab 的共享 Runner 来 攻击自建 GitLab 实例 —— 也就是公司在自有基础设施上管理的安装版本。
对 GitLab 来说，这是个噩梦场景：他们的云基础设施不仅在内部被滥用，还成为破坏客户自建服务器的渠道。
自建实例本该与服务商的共享环境隔离，结果却可能受到影响，这动摇了 GitLab 与企业客户之间最基本的信任。
原本应该局限在云端的事故，瞬间升级为一个触及 DevOps 根基的广泛风险。
没有单点失效
综合来看，这是一次多方面的重大失败。漏洞误分类、延迟检测、隔离控制不足，叠加起来制造了完美风暴。
不仅共享 Runner 被利用，连客户自建实例也被置于风险之中 —— 这本应是不可能发生的。
对于一个被全球数千开发者与企业信任的平台来说，这不仅仅是一个小故障；它是系统性的崩塌，质疑了内部流程、监控机制，以及关于多租户基础设施如何安全运行的根本假设。
影响
部分客户受影响尤为严重。CERN 遭受重创，导致 GitLab 出现了 近一周的宕机。
损害还在评估中。企业客户可能受到影响，调查仍在进行。GitLab 承诺会发布完整的事后分析报告。
但有一点是明确的：即使是受信任的多租户云基础设施，也可能被武器化 —— 方式有时超乎你的想象。
修复
GitLab 表示问题现已完全解决。漏洞已被修补，Runner 正在被严格监控。企业客户得到了服务补偿和必要的直接支持。
GitLab 称，他们正在持续改进检测、异常监控和 Runner 隔离，这意味着平台如今更具韧性，类似的噩梦场景不应再次发生。
为什么 GitLab 依然是第一
尽管这次失败规模巨大，GitLab 的响应却极为迅速。公司迅速调动安全团队、邀请第三方取证专家，并在整个事件中展现了前所未有的透明度，这在科技行业实属罕见。
通过公开沟通调查的每一步，承认错误，并详细说明补救计划，GitLab 展示了它对信任的重视不亚于对服务可用性的重视。
对全球数千开发者和企业而言，速度、责任感与透明真诚的结合，正是重建信心的关键，也是 GitLab 依然在 DevOps 领域保持领导地位的原因。
