Brief · Both
GitBook's SSO Flaw Became Staff Sessions, Then a Cloudflare Key, Then Your Tokens
GitBook published a post-mortem on Nov 4 about an attack that started Nov 2, and the customer-facing line is blunt: it is treating all customer data as exposed, it revoked every personal API token, and you have to rotate the secrets it doesn't manage for you. The calm-down half is that GitBook says the attack looked aimed at one customer, it found no evidence that any other customer's content was modified, and it has already rotated the secrets it owns. If you use GitBook for docs, API tokens, Git Sync or integrations, the rotate list is still your job this week.
What GitBook says happened
Per GitBook's own timeline (all times UTC; ET is UTC−5), the first hijacked account at the targeted customer showed up Nov 2 at 12:27 UTC (7:27 AM ET). By 16:32 UTC (11:32 AM ET) the attacker had staff sessions and access to GitBook's source code, and by 17:48 UTC (12:48 PM ET) they were in production. An internal alert fired at 18:10 UTC, the SSO flaw was fixed at 19:58 UTC, and at 20:32 UTC (3:32 PM ET) GitBook cut the attacker off and took the app offline. All existing API tokens were invalidated Nov 3 at 02:34 UTC, GitHub app keys rotated at 10:52 UTC, and GitBook says it was fully back online at 11:56 UTC (6:56 AM ET) after rotating all secrets. GitLab tokens followed at 22:51 UTC.
GitBook describes the chain in three steps. First, "Using a flaw in GitBook's SSO login flow, they were able to create login sessions acting as GitBook staff." Second, that let them "query the authentication information of a misconfigured GitHub App installed as an integration in our organization, gaining access to our internal code repositories and, eventually, a Cloudflare API key." Third, "Using this key, they gained access to production secrets which granted full infrastructure access through a service account."
How long they were in: "about 2:45 hours on the evening of 2 November, and about 40 minutes early on 3 November." Downtime ran "from 20:32 UTC on 2 Nov to 11:56 UTC on 3 Nov, about 16 hours," and GitBook says cached published sites stayed up for part of that window. Pulling the app offline was "a deliberate decision," and it wrote, "We chose a longer outage over that risk."
What was reached, and what wasn't
GitBook says the attacker reached "Our internal code repositories, parts of our compute infrastructure, and the deployed code and secrets of our edge network," and that the data accessed was "Our source code, infrastructure secrets, database credentials, integration tokens and Git Sync secrets." On customer data it is clear: "While they had access, the attacker could reach customer data stored in GitBook. So we've treated all customer data as exposed, not only the targeted customer." And: "Everything we've seen points to an attack aimed at one GitBook customer rather than at GitBook as a whole. We have found no evidence that any other customer's content was modified."
On the customer-data list GitBook names GitBook API tokens, integration tokens and secrets, session signing secrets, questions asked to GitBook Assistant by site visitors, documentation sites using authenticated access, and the ability to act as the GitBook app in GitHub and GitLab repos each customer had granted. For both GitHub and GitLab it adds the same caveat: it "cannot determine whether they took any action in customer repositories."
What wasn't compromised, per GitBook: "Billing information, passwords or IP addresses have not been compromised."
What GitBook says it did: disabled every affected service account, rotated "every secret and API key in our infrastructure, and every customer secret managed by GitBook," invalidated all API tokens, recycled all nodes, reversed everything the compromised service account had done, and disabled its back office. The post is signed by CEO Sara Tandowsky and CTO Samy Pessé, and it says, "This incident is on us."
The "AI agents" line is GitBook's claim only
GitBook's Nov 3 update called it "a sophisticated, highly targeted attack using AI agents," and the post-mortem says the attacker "moved with a speed and precision that pointed to an attack driven largely by automation and AI." That is GitBook's inference from speed. It publishes no technical evidence, names no tool and makes no attribution, so I am not tying this to any named agent toolkit. GitBook also cites Anthropic's late-2025 report of AI doing "80–90% of the tactical work" as context it added, not as evidence about this attack.
GitBook published attacker IP addresses in an Indicators of compromise section of the same post. I am not reproducing them here; check that section if you need them for log searches.
Who has to act
Every GitBook customer, since GitBook treats all customer data as exposed. The groups that need to move are API users (tokens were revoked), teams with third-party tools connected to GitBook, publishers of integrations that use secrets, authenticated-access sites with a custom backend, and GitBook MCP users (that last one is from the Nov 3 update). Git Sync and GitLab users need no rotation of those keys; GitBook did that for them. But GitBook still says it cannot determine whether the attacker acted in connected repos.
I'd call it a 4, act this week. Every GitBook API user has to make a new token, and customers have to rotate their own third-party secrets. It isn't a 5, because GitBook says the attack was aimed at one customer, it found no evidence that other customers' content was modified, and it has already rotated the secrets it manages.
What to do:
-
Make a new GitBook API token and update every app that uses one.
- Why: GitBook says "We revoked all personal API tokens, but customers' existing apps need to be updated."
- How: create a new token in GitBook, then swap it into your CI, scripts and apps. The old ones won't work anymore.
-
Rotate any secret that connects other tools to GitBook, and any secrets your published integrations use.
- Why: GitBook lists "Integration tokens and secrets" as accessible and tells customers to "Rotate any third-party API tokens or secrets you use to connect other tools to GitBook" and, for "published integrations that use secrets, rotate those secrets."
- How: rotate on the other tool's side, not only in GitBook, since the attacker may have the old value.
-
If you use authenticated access with your own backend, regenerate the signing key.
- Why: "Session signing secrets" and "Documentation sites using authenticated access" are on GitBook's exposed list.
- How: per GitBook, "regenerate your authenticated access signing key in the GitBook app and update it in your backend implementation."
-
Re-authenticate the GitBook MCP server if you use it.
- Why: GitBook's Nov 3 update says "If you use the GitBook MCP server, re-authenticate it." Note: the post-mortem's action list leaves this out, so it's from the earlier update only.
- How: reconnect it in your AI client, with your org admin's help if needed.
-
Look at what the GitBook app did in your GitHub and GitLab repos since Nov 2.
- Why: the attacker "could act as the GitBook app" in repos you granted, and GitBook "cannot determine whether they took any action in customer repositories." GitBook says no action is needed for Git Sync (it rotated those keys), so this review is my suggestion, not GitBook's.
- How: check commits, branches and webhooks by the GitBook app or bot from Nov 2–3 in the repos it can reach. Also check your logs against the IPs in GitBook's Indicators of compromise section.
-
For everyone, not just GitBook customers: audit your installed GitHub Apps and long-lived cloud keys.
- Why: the chain ran through "a misconfigured GitHub App" and a forgotten Cloudflare key. GitBook's own lesson is "Every forgotten credential is a liability: Least privilege, short-lived credentials and secret scanning have to be the default." This framing is mine, drawn from GitBook's lessons.
- How: list your org's GitHub Apps and trim their permissions and repo access. Find Cloudflare and other cloud API keys sitting in repos and move them to short-lived, scoped tokens.
Want the next one?
One email, weekly-ish. The week's briefs, how worried to be, and what to do about it. No doom.
Subscribe on Beehiiv ↗Free. Opens Beehiiv in a new tab. Unsubscribe whenever, I won't be offended.