GitBook's Post-Mortem: An SSO Flaw Gave an Attacker Staff Sessions and a Path to Production

An attacker exploited a flaw in GitBook's single sign-on login flow on November 2, 2026, to create sessions that acted as GitBook staff, and reached production 76 minutes after the first staff session, according to the company's post-mortem. GitBook says it treated all customer data as exposed, and that API tokens, integration secrets and session signing secrets were among what the attacker could reach. Customers who use the GitBook API or published integrations need to replace tokens now.

How the attacker moved

The post-mortem describes a chain of four steps. The SSO flaw produced staff sessions. Those sessions were used to query authentication information for a misconfigured GitHub App installed in GitBook's own organization. That gave access to internal code repositories and, eventually, a Cloudflare API key. The key led to production secrets, and a service account then gave full infrastructure access.

GitBook says the activity focused on a single customer. All times below are UTC.

• 12:27, November 2: first hijacked account at the targeted customer.
• 16:32: attacker gains staff sessions, then source code access.
• 17:48: attacker reaches production.
• 18:10: internal alert fires and the investigation starts.
• 19:58: the SSO flaw is fixed.
• 20:32: compromised accounts are disabled and the GitBook app is taken offline.

1. Production reached (17:48)76 min
2. Internal alert (18:10)98 min
3. SSO flaw fixed (19:58)206 min
4. Accounts disabled, app offline (20:32)240 min

Source: GitBook security incident post-mortem, accessed 2026-11-11

The alert came 22 minutes after production access, and the flaw stayed open for another 108 minutes after that.

Impact and downtime

GitBook counts about 16 hours of downtime, from 20:32 UTC on November 2 to 11:56 UTC on November 3, with cached published sites staying up for part of that window. The attacker had access for about 2 hours 45 minutes on the evening of November 2 and about 40 minutes early on November 3. A mirror of GitBook's status page shows the incident opening at 5:16 AM on November 3 and closing at 11:24 AM on November 4, rated Critical.

Cloudflare is shown only because the stolen key was for its API; GitBook's account says nothing about a flaw at Cloudflare.

The post-mortem lists what was accessible: GitBook API tokens, integration tokens and secrets, session signing secrets, questions that visitors asked the GitBook Assistant, documentation sites using authenticated access, and customer content. The attacker could also act as the GitBook GitHub App in repositories that customers had granted access to, and similarly in GitLab projects. Whether any action was taken in customer repositories is undetermined. GitBook found no evidence that customer content was modified, and says billing information, passwords and IP addresses were not compromised.

What customers should do

If you use	Do this
The GitBook API	Create a new API token and update existing apps
Published integrations with secrets	Rotate those secrets
Authenticated access with a custom backend	Regenerate the signing key in the GitBook app and update your backend
Git Sync (GitHub or GitLab)	Nothing; GitBook rotated those keys
GitBook's MCP server	Re-authenticate

The post-mortem also lists three indicator IP addresses: 94.183.188.91, 45.139.84.195 and 198.251.83.217. Customers are told to search their logs for them.

The AI claim is an inference

The post-mortem says the speed and precision of the attack "pointed to" an attack driven largely by automation and AI. That is GitBook's inference, not a confirmed finding, and the post-mortem does not name a tool. An earlier customer update said more directly that the attack used AI agents. The two statements differ in strength, and the company's account of scope also changed: the November 3 update called the incident platform wide, while the post-mortem says the activity focused on one customer.

Readers following incidents at AI and developer-tool vendors can compare this with the site's earlier reports on Fireworks AI's second intrusion and a three-CVE chain in LiteLLM's proxy admin.

GitBook has committed to hardening its networking, changing how changes are managed across its stack, and improving detection, and says it will publish further writeups on the incident in the coming weeks.