Short answer
GitBook says an attacker exploited a flaw in its SSO login flow on 2 November 2026 to create sessions as GitBook staff, then reached internal code, a Cloudflare API key and production secrets. GitBook took the app offline, rotated secrets and invalidated API tokens.
If you think your details were included, start with our checklist on what to do after a data breach.
Key facts
| Organization | GitBook |
|---|---|
| Incident type | Data breach |
| Status | Confirmed by the organization |
| Sector | Documentation and developer platform |
| Country | Not stated in the notice |
| Detected | 2026-11-02 |
| Disclosed | 2026-11-03 |
| People or records affected | Not stated. GitBook says the attack was aimed at one customer, but treated all customer data as exposed |
What data was exposed
- GitBook API tokens, integration tokens and secrets, and session signing secrets
- Questions that site visitors asked GitBook Assistant
- Content of documentation sites that use authenticated access
- Git Sync secrets, which could be used to act as GitBook in repositories customers had authorized on GitHub and GitLab
What happened
GitBook, a platform that hosts documentation for software and crypto projects, published a post-mortem on its 2 November 2026 security incident. It says an attacker exploited a flaw in its single sign-on login flow and created sessions that acted as GitBook staff. Coin Edition reported the disclosure on 3 November and dated the intrusion to 19:00 CET on 2 November.
According to GitBook, those staff sessions let the attacker query authentication details for a misconfigured GitHub App integration in GitBook’s own organization. That opened internal code repositories and, eventually, a Cloudflare API key. The key exposed production secrets and gave full infrastructure access through a service account.
Timeline
GitBook’s timeline, in UTC, starts with the first hijacked account at a targeted customer at 12:27 on 2 November. The attacker had staff sessions by 16:32 and reached production at 17:48. An internal alert fired at 18:10, the SSO flaw was fixed at 19:58, and the compromised accounts were disabled at 20:32. GitBook put the attacker’s access window at about 2 hours 45 minutes that evening and about 40 minutes early on 3 November.
What the attacker could reach
GitBook says the attacker could reach source code, infrastructure secrets, database credentials, integration tokens and Git Sync secrets. Through Git Sync, it could act as the GitBook GitHub app, or on GitBook’s behalf in GitLab, but only in repositories each customer had authorized. GitBook states that the attack was aimed at one customer, which it did not name. It treated all customer data as exposed.
Response
GitBook rotated all production infrastructure secrets and all GitBook-managed customer secrets, invalidated API tokens issued before a cutoff, revoked all personal API tokens, recycled staging and production nodes, and reversed actions taken by the compromised service account. It promised further write-ups. Coin Edition noted that the disclosure does not quantify affected customers or explain how the attacker got in beyond the SSO flaw.
Related reports
Coin Edition also reported that the trading platform Trade.xyz said it saw unauthorized activity on its GitBook documentation on 2 November and restored the pages. The article does not link that event to GitBook’s own post-mortem, and neither do we.
What to do if you use GitBook
Follow the actions above, and treat any email that asks you to rotate a token through a link with caution. Go to GitBook by typing the address yourself. Our data breach checklist covers password and token hygiene, and the phishing messages guide covers fake security notices. A similar rotate-everything notice came from Railway two weeks earlier.
Scams to watch for after this breach
Criminals use breach news as cover. Expect messages that mention the incident, quote real details, or offer help.
- Phishing emails claiming to be GitBook asking you to create a new token or reconnect GitHub through a link.
- Tampered links or fake wallet prompts on documentation pages, as seen in the wider wave of crypto project docs incidents reported that week.
- Messages that exploit leaked integration tokens to reach your repositories or third-party services, followed by extortion or fake 'security fix' offers.
What to do if you are affected
- 01Create a new GitBook API token and update every app that used the old one.
- 02Rotate API tokens or secrets for third-party tools connected to GitBook, and any secrets used by integrations you published.
- 03If you use authenticated access with a custom backend, regenerate the signing key in GitBook and update your backend.
- 04Re-authenticate if you use the GitBook MCP server, and reconnect GitHub or GitLab Git Sync if prompted.
- 05Search your logs for the three IP addresses GitBook published as indicators of compromise: 94.183.188.91, 45.139.84.195 and 198.251.83.217.
Frequently asked questions
How long was GitBook offline?
GitBook took the app offline at 20:32 UTC on 2 November and said it was fully back online at 11:56 UTC on 3 November, about 15.5 hours by those times. Cached published sites stayed up for part of the outage.
Was customer content changed?
GitBook says it found no evidence that customer content was modified. It also says it cannot determine whether the attacker acted in customer GitHub or GitLab repositories through Git Sync.
Were passwords or billing details taken?
GitBook's post-mortem lists billing information, passwords and IP addresses as not compromised.
Was the attack really done by AI?
That is GitBook's own assessment. It said the speed and precision of the attack pointed to one driven largely by automation and AI. No attacker has been named.
Sources
- Security Incident Post Mortem, GitBook, 2026-11-04
- GitBook AI Attack Exposes API Secrets, Triggers Urgent Security Response, Coin Edition, 2026-11-03
This post summarises public reporting as of 2026-11-06. Details of live incidents change; we update posts when the organization or regulators publish new facts. Spot an error? See our editorial and corrections policy.