返回资讯中心
外部精选
软件工程
#开发者实时流

GitBook 因 SSO 登录漏洞遭入侵,服务中断约16小时

来源标题:Security Incident Post Mortem

GitBook 披露 2026 年 11 月 2 日遭攻击者利用其 SSO 登录流程漏洞入侵,攻击者借机获取 Cloudflare API key 并取得完整基础设施访问权限。GitBook 在数小时内禁用所有受影响的内部服务账号并轮换全部密钥,服务于 11 月 3 日 11:56 UTC 恢复,停机约 16 小时。官方称攻击针对单一客户,未发现其他客户内容被修改,但因攻击者可接触客户数据,已将全部客户数据视为可能泄露。

Hacker News 最新themgt2026/11/4 · 今天6 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

2026年11月2日,攻击者未经授权访问了GitBook的系统。他们利用GitBook SSO登录流程中的一个漏洞,创建了冒充GitBook员工的登录会话。这使他们能够查询一个配置错误的GitHub App的认证信息——该App作为集成安装在我们组织中——从而获取了我们内部代码仓库的访问权限,并最终获得了一个Cloudflare API密钥。利用这个密钥,他们获取了生产环境密钥,进而通过一个服务账号获得了完整的基础设施访问权限。

我们在数小时内禁用了所有受影响的内部基础设施服务账号。这阻止了攻击,同时也导致GitBook应用下线。随后,我们轮换了基础设施中的所有密钥和API密钥,以及GitBook管理的所有客户密钥。GitBook于11月3日UTC时间11:56全面恢复上线,停机约16小时。

我们观察到的所有迹象都表明,这是一次针对某个GitBook客户的攻击,而非针对GitBook整体。我们没有发现任何证据表明其他客户的内容被修改。

在攻击者拥有访问权限期间,他们可以触达存储在GitBook中的客户数据。因此,我们将所有客户数据都视为已暴露,而不仅仅是目标客户的数据。

让GitBook下线是一个 deliberate 的决定。一旦攻击者进入我们的云基础设施,保持平台运行就意味着他们可以在我们处理问题的同时继续寻找访问途径。我们选择承受更长的停机时间,而不是冒这个风险。

在离线期间,我们轮换了生产基础设施中的每一个密钥以及GitBook管理的每一个客户密钥,使最终截止时间之前签发的所有API token失效,回收了预发布和生产环境中的所有节点,并撤销了被入侵服务账号所做的一切操作。我们还禁用了后台管理系统,同时加强了其防护措施。

这次事件是我们的责任。对于服务中断以及未能更早地与您沟通,我们深表歉意。

下一节将详细说明哪些数据可被访问、我们发现了什么,以及我们采取了哪些措施。

攻击者在11月2日晚间拥有约2小时45分钟的生产环境访问权限,并在11月3日凌晨拥有约40分钟的访问权限。

在此期间,以下客户数据可被他们访问:

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →