说明书平台被攻破，GitBook客户授权的代码仓库也进入风险范围

一个用来写产品说明书的平台失守，风险却越过说明书，延伸到客户授权连接的代码仓库。GitBook在11月4日公布的复盘说，攻击者利用登录流程漏洞进入内部系统；公司随后主动停机约16小时，重置凭证。这起事故发生于11月2日，值得重新看的是：连接工具时交出的权限，会跟着工具一起承担风险。

GitBook的同步功能原本解决的是一件很日常的麻烦。开发者习惯在代码编辑器里写文档，写作者更喜欢网页编辑器；如果两边各存一份，改完还得手工搬运。官方产品介绍说，Git Sync能在GitBook与GitHub或GitLab之间双向同步，让不同岗位继续使用熟悉的工具，也能通过分支、审阅和合并控制发布。

这样的便利需要一张能进出文件库的“工作证”。GitBook的接入指南允许用户选择只开放指定仓库，也可以开放全部仓库。仓库就是集中保存代码、文档及修改历史的地方。两种选项看起来只是配置页面上的一个选择，实际决定了这张工作证能开几扇门。

GitBook称，此次活动似乎针对单一客户，但按全部客户数据可能暴露处理。攻击者能够以GitBook应用身份访问获授权的仓库；是否实际在那里操作，公司无法确定。能进门与已经搬走东西，是不同程度的事实，不能混写。

权限管理也并非安装时选过一次就结束。GitHub的官方说明允许账号持有人检查应用权限、调整可访问的仓库，并在不再需要时暂停或卸载应用。对只要同步一本说明书的团队来说，定期检查是否仍开放着整间资料室，比笼统地相信“这是文档工具”更有意义。

出了问题以后，调查同样不能停在网页恢复正常。GitHub的事故调查指南建议检查异常账号操作、权限变化、新增应用和代码提交记录。可以把这些记录理解成门禁与搬运清单：一份告诉你谁进来，另一份告诉你东西有没有被改动，需要放在一起看。

这个案例给普通网站维护者的提醒很具体：自动同步省下的是复制粘贴，授出的却是真实访问权。选择连接哪些仓库，应当围绕工具实际要做的工作；恢复服务时，也要把连接另一端纳入检查。否则，眼前只是说明书打不开，背后可能牵着更重要的文件。

原始复盘发布时间：北京时间2026年11月5日03:30／美国东部时间2026年11月4日14:30（EST）。