On November 3, 2026, a thread titled “Gitbook Breached” climbed Hacker News (the discussion thread). If your team keeps API docs, runbooks or architecture notes on GitBook, the GitBook breach is worth an hour of your week, even though the vendor says no customer content was changed. The real exposure is the credentials that documentation platforms hold.
What GitBook has confirmed
According to GitBook’s incident notice, an attacker gained unauthorized access to some GitBook infrastructure credentials on November 2 at 19:00 CET. GitBook says it detected the attack immediately and described it as a sophisticated, highly targeted attack using AI agents.
GitBook lists four things that may have been accessed: integration tokens, Git Sync secrets, API tokens, and questions visitors asked GitBook Assistant. It says it has found no evidence that customer content was modified.
The response was drastic. GitBook blocked the attacker, replaced credentials across its infrastructure, invalidated customer API tokens and revoked all personal API tokens. It took the app and authenticated docs sites offline, while public docs stayed up from cache. By 16:21 CET on November 3 the app, API and published docs were back, with some services still degraded, and a full post-mortem was promised.
What is still unknown
GitBook has not said how the credentials were obtained, how many customers were affected, or which AI systems the attacker used. Decrypt points out that the disclosure does not establish that GitBook’s own AI products were involved, and commenters in the discussion thread asked what evidence supports the AI-agent claim. Until the post-mortem lands, treat that label as the vendor’s description, not a verified finding.
The lesson does not depend on it. Whether the attacker was a script, a person or an agent, the damage comes from what the stolen credentials can reach.
Why a docs platform is a credential broker
Teams file documentation under low-risk SaaS. This incident shows why that classification is shaky. A docs platform that syncs with your repositories, runs integrations and exposes an MCP server holds standing access to other systems.
Rescana makes the same point in its analysis: a stolen Git Sync token could reach source code, so this is more than a docs-vendor problem. That is the firm’s inference, not GitBook’s statement, but it matches how Git Sync works. Read access to a repository is read access to everything committed there, including whatever slipped into a config file two years ago.
GitBook Assistant adds a second angle. Visitors type questions into it, and on authenticated or internal sites those questions can contain customer names, error messages or pasted snippets. That data now sits in a vendor’s logs.
Vendor-risk checklist for engineering leaders
Here is what I would run this week, for GitBook or any comparable platform.
- Inventory every token that touches the platform: API tokens, Git Sync credentials, integration secrets and MCP connections. Name an owner for each.
- Rotate at the source. GitBook told customers to rotate their GitBook API tokens, third-party secrets and published-integration secrets, and to re-authenticate the MCP server. Revoking a key only inside the vendor’s UI leaves it alive at the provider.
- Review repositories connected through Git Sync for unexpected commits, branches, deploy keys and webhooks since November 2. This step comes from Rescana’s guidance, not from GitBook.
- Scope what you grant. Give each integration the narrowest repository and permission set it needs, and delete tokens nobody uses.
- Classify what lives in the docs. Check authenticated sites and Assistant history for secrets, customer data and internal architecture notes.
- Ask the vendor how fast it notifies customers, and whether it appears on your subprocessor list.
Incident communication is part of the risk
the discussion thread also shows how the first hours looked from the outside. Commenters said the early status message told customers they did not need to do anything, without mentioning the possibly exposed data or token rotation. GitBook’s CTO said in the thread that a post-mortem would follow within 24 hours, and some commenters credited the company for rotating tokens itself.
Watch the same signals when you evaluate any vendor. How early did customers get actionable instructions? Did the company act on their behalf? PancakeSwap, which uses GitBook for its docs, took them offline as a precaution, said they were not compromised, and later moved them to infrastructure it controls, according to Decrypt.
What to do now
Rotate the credentials, read the post-mortem when it ships, and put documentation platforms on the same vendor-risk tier as your CI system. They hold the same kind of keys.
If you want a second pair of eyes on your third-party integrations or your secrets hygiene, the engineering team at Luby can help.
