GitBook Infrastructure Breach: What Teams With GitBook Tokens and Git Sync Should Do Now

Status: Contained and restored, according to GitBook. In its update of 3 November 2026 at 16:21 CET (17:21 Asia/Nicosia), GitBook said the GitBook app, the GitBook API and published docs were available again. GitBook says a few services may still be degraded and that a full post-mortem will follow. Attribution: none published. No CVE assigned.

Executive Summary

GitBook is a hosted documentation and knowledge-base platform. Software companies use it for public product docs, API references, help centres and internal knowledge bases. On 3 November 2026 GitBook published a security incident notice. It says:

GitBook was the target of what it calls "a sophisticated, highly targeted attack using AI agents."
At 19:00 CET on 2 November 2026 (20:00 Asia/Nicosia), the attacker gained unauthorized access to some of GitBook's infrastructure credentials.
GitBook says it detected the attack immediately, blocked the attacker and "closed the vulnerabilities involved."
The attacker may have accessed integration tokens, Git Sync secrets, API tokens, and questions that site visitors asked GitBook Assistant.
GitBook says that "at this stage" it has found no evidence that any customer content in GitBook was modified.
GitBook replaced every credential and secret across its infrastructure and "invalidated every customer's API tokens". It also says it "revoked all personal API tokens" during the incident.

GitBook has not published a root cause, the number of affected customers or any indicators of compromise. It has not said that any exposed token was used. This advisory does not fill those gaps.

The practical risk sits in the systems GitBook connects to. A Git Sync secret or an integration token can open a code repository or a third-party tool, not just a docs site. GitBook asks customers to rotate GitBook API tokens, rotate third-party tokens and secrets connected to GitBook, rotate secrets used by published integrations, and re-authenticate the GitBook MCP server.

For third-party risk teams, the questions are simple. Which of your suppliers host their docs or knowledge base on GitBook? Did they connect it to their source code or other tools? Have they rotated those connections?

What Happened

GitBook's incident page has two dated updates.

3 November 2026, 13:15 CET (14:15 Asia/Nicosia). GitBook said it had detected a security incident affecting its infrastructure on 2 November, contained it quickly, and taken some services offline as a precaution. It called this "a platform wide issue affecting a number of customers." At that point the investigation was ongoing, and GitBook said no customer action was required yet.

3 November 2026, 16:21 CET (17:21 Asia/Nicosia). GitBook said the app, the API and published docs were available again, with a few services possibly still degraded. This update added the details:

At 19:00 CET on 2 November, the attacker gained unauthorized access to some infrastructure credentials. GitBook says it detected the attack immediately and acted to block further impact.
To make sure its infrastructure was secure, GitBook took the GitBook app and authenticated docs sites offline. Publicly published content stayed live, from cached data, for as long as possible.
GitBook says it blocked the attacker and "closed the vulnerabilities involved," replaced every credential and secret across its infrastructure, "invalidated every customer's API tokens," and brought services back only once it was confident they were secure.
The investigation shows the attacker may have accessed integration tokens, Git Sync secrets, API tokens, and questions asked to GitBook Assistant by customers' site visitors.

GitBook's public status page still listed the incident as "Monitoring" when we checked again on 4 November at 09:18 Cyprus/Nicosia time (UTC+2). It mentioned "specific issues affecting some customers related to published sites."

What has not been disclosed:

How the attacker obtained the infrastructure credentials, or which vulnerabilities were closed.
What "using AI agents" means in practice, and which AI tools were involved. GitBook has not said that its own AI products played a part.
How many customers' tokens, secrets or Assistant questions were in reach.
Whether any exposed token or secret has been used against a connected system.
Who was behind the attack.

GitBook says it will publish a full post-mortem. We will update this advisory when it does.

Technical Information

Each data type GitBook names connects to something different, so it helps to look at them one at a time.

GitBook API tokens. GitBook's API authentication docs say the API uses personal access tokens tied to a user account. A token has the same access and privileges as that user. GitBook revoked all personal API tokens during the incident. Any script, CI job or tool that used one will fail until it gets a new token. The old tokens no longer work, but anything they could reach before revocation is in scope for review.

Git Sync secrets. Git Sync keeps a GitBook site in sync with a GitHub or GitLab repository in both directions. The connection works differently for each:

GitLab Sync uses a GitLab personal access token that the customer creates and pastes into GitBook. GitBook's GitLab Sync guide tells users to enable the api, read_repository and write_repository scopes, with a Maintainer or Admin role if the token has one. A token like that is a GitLab credential with write access, so you have to revoke it in GitLab. Changing something in GitBook is not enough.
GitHub Sync connects through the GitBook GitHub app, installed on a personal account or GitHub organization with selected repository access, according to GitBook's GitHub Sync guide. GitBook has not said exactly which GitHub-side secrets count as "Git Sync secrets."

At this stage, GitBook says it has found no evidence that content in GitBook was modified. It has not commented on connected repositories either way. That is why the repository side is worth checking.

Integration tokens and published integrations. GitBook integrations connect a site or organization to other tools. Some store a third-party API key or secret inside GitBook. GitBook asks customers to rotate third-party tokens and secrets used to connect other tools, and to rotate the secrets of any integration they have published.

GitBook Assistant questions. GitBook Assistant is the AI chat on published docs sites. Questions typed by visitors may have been accessed. For public product docs, these are usually how-to questions. For authenticated or internal knowledge bases, visitors may have pasted account details, error logs, configuration snippets or other sensitive context.

GitBook MCP server. GitBook offers an MCP server so AI assistants and developer tools can work with GitBook content. GitBook asks MCP users to re-authenticate.

What this is not. No CVE has been assigned or referenced, so there is no CVSS score or KEV listing. This is a supplier infrastructure incident with possible credential exposure. It is not a software flaw that customers patch.

Affected Product Versions

N/A — SaaS/infrastructure incident. There is no customer-installed GitBook version to upgrade.

In scope: the hosted GitBook platform (app, API, authenticated docs sites, Git Sync, integrations, GitBook Assistant and the GitBook MCP server), as described in GitBook's notice.
Not stated: how many organizations were affected, or whether every customer's data was in reach. GitBook called it "a platform wide issue affecting a number of customers" and revoked all personal API tokens platform-wide. Plan as if your organization is in scope.
Most exposed: organizations that use Git Sync (especially GitLab Sync with a personal access token), integrations that store third-party secrets, published integrations, the GitBook API in automation, the MCP server, or GitBook Assistant on a site where visitors might share sensitive details.
Lower exposure: organizations that only edit and publish content in GitBook, with no connected tools or tokens. Even then, GitBook's general advice applies.

Workaround and Mitigation

There is nothing to patch. GitBook says it "closed the vulnerabilities involved." Customers need to rotate credentials, and GitBook asks them to work with their GitBook organization admin.

Issue new GitBook API tokens. The old personal tokens are already revoked. Find every script, CI pipeline, static-site build and internal tool that called the GitBook API, and give each a new token with the least privilege it needs. Delete tokens nobody claims.
Revoke and reissue Git Sync credentials at the source. For GitLab Sync, revoke the personal access token in GitLab, create a new one with only the scopes Git Sync needs, and enter it in GitBook. For GitHub Sync, review the GitBook GitHub app installation and its repository access in your GitHub organization settings. Check GitBook's guidance for any reconnection step.
Rotate third-party secrets connected to GitBook. For every integration that holds a key to another tool, revoke the key at the provider that issued it, then add the new one. A key replaced only in GitBook keeps working at its source.
Rotate secrets in published integrations. If your team built and published a GitBook integration that uses secrets, rotate them and redeploy.
Re-authenticate the GitBook MCP server in every AI assistant or developer tool connected to it.
Review connected repositories for unexpected changes (Rescana guidance, not a GitBook instruction). On synced branches, look for commits, branches, merge requests or webhooks your team did not make. Check repository and organization audit logs from 2 November 2026 onward.
Assess Assistant exposure (Rescana guidance). If GitBook Assistant runs on an authenticated or internal site, consider what visitors might have typed. Decide with your privacy team whether that affects any notification obligations.
Follow GitBook's updates. Subscribe to GitBook's status page and read the post-mortem when it is published.

Indicators of Compromise

GitBook has not published any indicators of compromise: no IP addresses, user agents, request patterns or file hashes. We will not invent any.

Until the vendor publishes specifics, use your own logs and look for:

Activity in GitLab or GitHub from GitBook-linked tokens or the GitBook app that doesn't match normal Git Sync behaviour: pushes to branches outside the synced branch, new deploy keys, new webhooks, or repository access outside normal sync times.
Use of rotated third-party keys from unfamiliar IP ranges or regions.

These are general signs of credential misuse. They are not indicators GitBook has published for this incident.

What to Do With This Vendor Today (TPRM)

GitBook is often treated as a low-risk "docs vendor." This incident shows why that can be wrong. Suppliers connect GitBook to their source code through Git Sync, to their tools through integrations, and to their AI assistants through MCP. A token stored in GitBook may unlock a supplier's repository or another service that touches your data, even if the supplier itself was never breached. GitBook Assistant questions may also include details your users typed on a supplier's help centre or customer portal.

Send these questions to software and SaaS suppliers that publish product docs, API references or help centres, and to any supplier that hosts a knowledge base for you:

Do you use GitBook, directly or through a subcontractor, for docs or knowledge bases that cover our account, our integration or our data? Is any of it behind authentication?
Have you issued new GitBook API tokens and removed unused ones since GitBook revoked all personal tokens on 2–3 November 2026?
Is GitBook connected to your source code through Git Sync? If you use GitLab Sync, has the personal access token been revoked in GitLab and replaced? If you use GitHub Sync, have you reviewed the GitBook GitHub app's repository access? Have you checked synced repositories for changes since 2 November?
Which third-party tools are connected to GitBook through integrations, and have their secrets been rotated at the issuing provider? Ask specifically about any integration that can reach our tenant or API.
Do you run GitBook Assistant on a site our users can reach? Could they have shared account details there, and have you assessed whether this triggers any notification duty to us?
Will you send us GitBook's post-mortem when it is published, and tell us if it changes the scope? Check whether GitBook is on their subprocessor list and what notification timeline they commit to.

If you are the GitBook customer, ask your own team the same questions and record the answers against the supplier record.

Our platform validates vendor claims against live attack-surface signal and chases findings to closure under your approval.

Need help working through docs and knowledge-base SaaS suppliers exposed to the GitBook infrastructure breach? Our team can help you prioritize them and track their answers. Talk to an expert

Sources

GitBook, "Security incident" (updates 3 Nov 2026, 13:15 CET and 16:21 CET): https://www.gitbook.com/status/security-incident-2026-11-03
GitBook status page: https://status.gitbook.com/
GitBook status page, "Security incident impacting published sites and GitBook app": https://statuspage.incident.io/gitbook/incidents/24zzrnea
GitBook docs, GitBook API authentication: https://gitbook.com/docs/developers/gitbook-api/authentication
GitBook docs, Enabling GitLab Sync: https://gitbook.com/docs/getting-started/git-sync/enabling-gitlab-sync
GitBook docs, Enabling GitHub Sync: https://gitbook.com/docs/getting-started/git-sync/enabling-github-sync