文章总结： 2026年9月13日GitHub再次发生重大故障，官方标记为部分系统中断，PullRequests遭遇重大中断，API、Actions、Issues等核心服务性能下降。根因是collab数据库复制延迟导致授权端点错误率上升，引发全系统连锁雪崩。这是GitHub年内第4次重大故障，暴露全球研发对单一平台的单点依赖风险。建议企业关键仓库多地镜像或自建Git服务兜底，将安全扫描等关键环节设计为可离线可重放，并将平台不可用写入应急预案定期演练。 综合评分： 72 文章分类： 网络安全,供应链安全,安全运营,安全大事件

【安全圈】GitHub又崩了！PR重大中断全球研发停摆

安全圈

2026年9月13日 17:56 江苏

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

关键词

Github崩了

一、60秒看完全部要点

• 🔴 9月13日，GitHub 再次发生故障，官方标记为”部分系统中断”（critical）
• 🚨 Pull Requests 遭”重大中断”，API、Actions、Issues、Pages 全线性能下降
• 🔍 官方已定位线索：collab 数据库复制延迟 → 授权端点报错 → 全系统连锁雪崩
• ⏱️ 09:16 UTC 开始调查，09:36 定位到数据库复制延迟，仍在抢修
• 📉 这是 GitHub 年内第 4 次重大故障，8月刚为长时间中断公开致歉
• ⚠️ 再次暴露：全球研发的”单点依赖”已成软件供应链关键风险

二、事件经过

9月13日，全球最大代码托管平台 GitHub 再次出现服务中断。GitHub 官方状态页显示，平台整体状态被标记为 “Partial System Outage”（部分系统中断），事件影响级别为 critical（严重）。

根据官方披露的组件状态，本次故障中 Pull Requests（拉取请求）遭遇”重大中断”（major outage），而 API Requests、Actions、Issues、Pages 等核心服务则出现不同程度的性能下降（degraded performance）。

官方时间线如下：

• 09:16 UTC

  ：开始调查 API Requests、Issues、Pages 和 Pull Requests 的可用性下降报告

• 09:25 UTC

  ：确认 Actions 正在经历性能下降，继续调查

• 09:36 UTC

  ：定位到 collab 上数据库复制延迟增加，导致授权端点错误率上升，进而造成整个系统错误率上升，仍在调查

三、根因分析：一次典型的”数据库雪崩”

官方在最新更新中已给出明确线索：问题起源于 collab 组件上的数据库复制延迟（database replication delays）。这条故障链条非常典型——

数据库复制延迟 → 授权端点错误率上升 → 各组件依赖授权服务 → 全系统错误率连锁上升

换句话说，故障的真正传导路径不是”某个服务挂了”，而是”所有服务都要经过的那道关卡堵了”。当主从复制出现延迟时，读取从库的请求可能拿到过期数据，授权校验判断异常，错误迅速从边缘服务蔓延到整个平台。这也解释了为什么本次故障同时波及 PR、API、Actions、Issues 等多个看起来并不相关的模块。

四、年内第 4 次：GitHub 的 2026 可用性危机

把本次故障放进时间线看，GitHub 在 2026 年的表现难言乐观：

• 5月26日

  ：认证故障，开发者无法访问 GitHub Actions、GitHub Pages 等关键自动化服务，CI/CD 流水线大面积阻塞

• 7月

  ：一次针对 PR 数据的 Vitess keyspace 回填工作流出错，被取消时触发了未被正确理解的代码路径，导致备份表被删除、PR 创建持续报错

• 8月6日

  ：Actions 长时间中断，GitHub 官方罕见发布致歉公告，承认”在影响和持续时间上都不可接受”，承认辜负了对客户的承诺

• 8月17日

  ：全球性故障，网站、API、Actions、Webhooks、Issues、Pull Requests 全线报错，微软方面亦确认 GitHub 全球宕机

• 9月13日（本次）

  ：数据库复制延迟引发多服务连锁故障，Pull Requests 重大中断

警示：不到五个月内四次重大故障，且故障模式各不相同（认证、数据库、配置变更、复制延迟）——这说明问题并非单一隐患，而是平台在高负载增长下的系统性工程挑战。

五、安全圈点评

在安全圈看来，这起事件的看点不在”GitHub 又崩了”这个笑话，而在于可用性本身就是安全属性的一部分。当全球数百万开发者、数十万条 CI/CD 流水线、无数企业的依赖拉取与镜像构建都挂在同一个平台上时，一次数据库复制延迟就足以让全球研发按下暂停键。

更值得警惕的是供应链的连锁效应：GitHub 的短暂中断不仅影响写代码，还会影响安全扫描、制品构建、依赖更新、密钥轮换——很多企业的安全流水线，恰恰是运行在 GitHub Actions 上的。平台一停，安全防线上的自动化环节集体失能。

安全圈建议企业与研发团队做三件事：一是关键仓库做多地镜像或自建 Git 服务兜底，避免单一平台成为研发命门；二是将安全扫描、制品签名等关键环节设计为可离线、可重放，不把安全能力完全托管给第三方 SaaS；三是把”平台不可用”写进应急预案并定期演练——不是如果，而是下一次何时。

对我们这些把代码、密钥、制品都托付给同一个平台的人来说，GitHub 的每一次抖动都是一次提醒：便利与风险，从来是同一枚硬币的两面。

END

阅读推荐

【安全圈】黑客操纵数百个AI Agent：26秒破11家企业，夜袭440台服务器

【安全圈】黑客把Claude玩疯了：全自动扒光180万安卓App密钥机密

【安全圈】GitLab曝CVSS 10满分漏洞：免密盗源码，数小时遭在野狂扫

【安全圈】思科防火墙FMC曝满分漏洞：免密直取Root遭勒索攻陷

【安全圈】JFrog制品库曝组合漏洞：免密换取Admin凭据篡改依赖

安全圈

←扫码关注我们

网罗圈内热点 专注网络安全

实时资讯一手掌握！

好看你就分享 有用就点个赞

支持「安全圈」就点个三连吧！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全圈 《【安全圈】GitHub又崩了！PR重大中断全球研发停摆》