GitBook Breach Forces API Token Rotations

GitBook spent two days partially offline after an attacker reached infrastructure credentials. The company describes the intrusion as a “sophisticated, highly targeted attack using AI agents,” says it invalidated customer API tokens, and told users to rotate integration secrets and re-authenticate the GitBook MCP server. The platform was marked resolved on November 4, but the detailed postmortem is still pending, and the AI-agent attribution has not been independently verified.

The practical story is simpler than the label. A documentation platform that sits between code repositories, third-party integrations, and an AI assistant lost control of credentials that connect those systems. GitBook says it found no evidence that hosted content was modified. It has not confirmed that data was exfiltrated, and it has not published a customer or record count.

Key Takeaways:

• An attacker accessed some infrastructure credentials at 19:00 CET on November 2, 2026, according to the company; the intrusion was detected immediately and the app and authenticated docs were taken offline.
• Potentially exposed data includes integration tokens, Git Sync secrets, API tokens, and questions visitors asked GitBook Assistant.
• GitBook invalidated customer API tokens and revoked all personal API tokens; customers still need to rotate third-party secrets, published integration secrets, and re-authenticate the MCP server.
• “AI agents” is GitBook’s characterization, not an independently confirmed root cause. The disclosure does not say which AI systems were used or how the credentials were obtained.
• Git Sync remains affected by an unrelated GitHub outage even after the GitBook platform was marked resolved.

The incident timeline

The dates matter because the first customer-facing notice did not arrive with the first status update. GitBook’s status page initially described downtime affecting published documentation sites and the editor. The credential exposure and token-rotation instructions came later, after the investigation had identified what the attacker may have reached.

What the disclosure says happened

The account is direct about the sequence and vague about the mechanism. The attacker gained unauthorized access to “some of our infrastructure credentials” at 19:00 CET on November 2, according to the company. The company blocked the attacker, closed the vulnerabilities involved, replaced every credential and secret across its infrastructure, and brought services back only after confirming they were secure.

The company also invalidated customer API tokens. That is the right default when a credential store is in scope: revoking first removes the attacker’s ability to reuse stolen tokens, even though it forces every customer to re-authenticate. The company revoked all personal API tokens during the incident and told customers to rotate any existing API tokens, third-party tokens or secrets connected to the platform, and secrets used by published integrations.

The disclosure does not identify the initial access vector. It does not say whether the credentials came from a compromised employee account, a vulnerable service, a leaked secret, or a supply-chain dependency. Those details are what a postmortem is for, and until they are published, the “AI agents” phrase describes the attacker’s tooling at a high level rather than the path into the infrastructure.

What may have been exposed

GitBook lists four categories that the attacker may have accessed. Each has a different blast radius.

• API tokens. These are the credentials applications use to call the platform. The company invalidated customer API tokens and revoked all personal API tokens. Old tokens should be treated as unusable, and new ones should be scoped to the minimum permissions a workflow needs.
• Integration tokens. These connect the platform to external tools. A leaked integration token can give an attacker the same access the integration had, which may include reading or writing data outside the platform.
• Git Sync secrets. These are the credentials behind the connection between hosted content and a Git repository. Depending on scope, a Git Sync secret can expose repository contents or allow changes. Rotate the secret and review the repository’s recent commits and access logs.
• Questions asked to GitBook Assistant. Visitors’ prompts are potentially sensitive. A question can contain a customer name, an internal URL, a piece of code, or a credential pasted into a support query. The attacker may have accessed these questions, according to the company; it has not said how many or which customers.

The company says it has found no evidence that hosted content was modified. That is a statement about integrity, not confidentiality. It does not rule out that credentials were read, and it does not tell customers whether a token was used before revocation. Customers should verify their own content against Git or backups rather than relying only on the platform’s statement.

What customers need to do

The company’s instructions cover the first phase of an incident-response plan. It says it emailed all customers with the required actions. The minimum work is:

• Create new GitBook API tokens. The old personal tokens were revoked, so automation that depended on them will fail until it is updated. Scope the replacement tokens narrowly and set an expiry where the API supports it.
• Rotate third-party tokens and secrets. Any token used to connect GitBook to another service should be replaced. That includes tokens stored in CI, internal dashboards, and published integrations.
• Re-authenticate the GitBook MCP server. The disclosure explicitly calls this out. Treat the old MCP session as untrusted.
• Review Git Sync activity. Check recent commits, force-pushes, branch changes, and repository access logs. Rotate the Git Sync secret even if the logs look clean.
• Review Assistant queries. If visitors may have pasted secrets or personal data into GitBook Assistant, decide whether notification, credential rotation, or privacy review is required. The platform’s logs may not be sufficient to reconstruct every query.
• Check integration scopes. Remove integrations that are no longer used and reduce the permissions of the ones that remain. A token that can write is more dangerous than a token that can read.
• Watch for phishing. A breach that exposes documentation and support context gives attackers material for convincing messages. Verify unexpected links and requests through a separate channel.

The order matters. Rotate the credentials that can change data first, then the read-only ones. Review logs before deleting them, because the logs are the only evidence of whether a stolen token was used. If your organization has a security team, hand them the timeline and the affected token inventory rather than handling it as a routine password reset.

The AI-agent claim needs evidence

The most quoted sentence in the disclosure is also the least substantiated: “GitBook has been the target of a sophisticated, highly targeted attack using AI agents.” The company has not said which AI systems were involved, what the agents did, or which logs distinguish agent-driven activity from a human operator using automation.

That gap has already attracted scrutiny. On Hacker News, a commenter asked what logs distinguish an AI agent from a human; the CTO, Samy Pesse, replied that the company would provide details in a long postmortem. That is a reasonable answer during containment, but it means readers should treat “AI agents” as the company’s characterization for now, not as an independently verified fact.

There is a defensible version of the claim. Attackers increasingly use AI tools for reconnaissance, credential stuffing, code generation, and repetitive exploitation. An “AI agent” can mean a model-driven tool that automates a step in the intrusion, not necessarily an autonomous system that planned the whole operation. The distinction matters because it changes the defensive lesson: the problem is still stolen credentials, excessive permissions, and weak segmentation, not a new kind of magic that bypasses controls.

The postmortem should establish how the credentials were obtained, what the attacker accessed and when, whether any customer token was used before revocation, and what evidence supports the AI-agent description. Until those answers exist, the useful response is the same regardless of whether the attacker was human, automated, or both.

Why documentation platforms are a target

Documentation is not just public text. A modern docs platform holds the connections that keep the text current: Git Sync to a repository, integrations to analytics and support tools, API tokens for automation, and an AI assistant that answers visitor questions. Those connections make the docs platform a credential hub, and a credential hub is more valuable than a static website.

The crypto industry noticed quickly because docs are part of its trust surface. PancakeSwap temporarily took its documentation offline as a precaution and later moved it off the platform to infrastructure it controls, according to Decrypt’s reporting. The exchange described its docs as uncompromised and its app as unaffected. The precaution is still instructive: a trusted docs link is a useful place to send users, and an attacker who can influence that surface can turn a technical incident into a phishing problem.

For teams running a public docs platform, the lesson is to treat it as a production system. Inventory the integrations, scope the tokens, log the sync activity, and have a plan for taking the docs read-only or offline without breaking every existing link. The cost of that preparation is small compared with discovering after an incident that nobody knows which token had write access to which repository.

What the postmortem should answer

The company says it will publish a full postmortem within 24 hours of marking the incident resolved. The useful parts will be the initial access vector, the dwell time, the credentials and customer data involved, whether any token was used, how many customers were affected, and which controls failed. A timeline built on “AI agents” without those details leaves the central questions unanswered.

Customers should also ask for the token inventory and the revocation timestamps. If a token was valid for hours after the intrusion, the window matters. If Git Sync secrets were exposed, the repository audit logs are the clearest way to know whether they were used. If Assistant questions were exposed, the privacy team needs enough information to decide whether notification is required.

The incident is resolved in the sense that the platform’s core services are back. The security work for customers is not. Rotate the credentials, review the logs, and wait for the postmortem before accepting the AI-agent framing as the whole story.

Related Reading

More in-depth coverage from this blog on closely related topics:

• Risks of sharing AI conversations
• Polymarket supply-chain drain

Sources and References

Sources cited while researching and writing this article:

• GitBook security incident status page
• GitBook status incident timeline
• Decrypt: Crypto Docs Host GitBook Hit by AI Agent Security Breach
• Hacker News: GitBook breached (including CTO response)
• TokenPost: GitBook Tells Customers to Replace Credentials