GitBook Breach: AI Agents Steal Infrastructure Credentials, Customer Tokens Exposed

What happened

GitBook is the documentation platform used by a long tail of SaaS vendors, open-source projects, and internal engineering teams. On 2 November 2026 at 19:00 CET, an attacker gained unauthorised access to GitBook's internal infrastructure credentials. GitBook's advisory describes the method as "a sophisticated, highly targeted attack using AI agents," without going further on operational detail. The company detected the intrusion, blocked the attacker, replaced its infrastructure credentials, invalidated every customer's GitBook API tokens, took the service offline, and brought it back when its internal investigation reached a confident containment state — all inside a 21-hour window.

What was exposed

The attacker reached credentials that sit at the base of GitBook's multi-tenant infrastructure, which means the plausibly-accessed set spans every customer rather than a specific subset. GitBook's advisory lists the following as potentially accessed:

• Integration tokens — any OAuth or API tokens your GitBook workspace stored for third-party connectors (Slack, Linear, Jira, Zapier, Intercom, Figma, and others).
• Git Sync secrets — the credentials GitBook uses to read and write to your GitHub, GitLab, or Azure DevOps repository mirrors.
• API tokens — GitBook-issued API tokens used by scripts, CI pipelines, and bots.
• Secrets of published integrations — if your team developed and published a GitBook integration, its signing secrets and configuration were in scope.
• GitBook MCP server configuration — if you connected an MCP (Model Context Protocol) server to GitBook, its auth material is in scope.
• GitBook Assistant questions — natural-language questions your site visitors typed into GitBook Assistant, which may contain customer-identifiable context.

GitBook has not disclosed a customer count. The advisory frames it as "a platform-wide issue affecting a number of customers," and because the attacker reached infrastructure-level secrets, the safe assumption is that every GitBook workspace must be treated as having had its stored credentials exposed.

Why this is a SaaS supply-chain hit

The content in your GitBook spaces is not the thing to worry about. The credentials you handed GitBook to connect to your infrastructure are. A typical GitBook workspace holds the keys to:

• A GitHub or GitLab repository with a Personal Access Token or GitHub App installation.
• A Slack workspace with a bot token and webhook.
• A Linear, Jira, or Notion account with an API key.
• A CI pipeline that pushes docs with a GitBook API token stored as a repo secret.

Every one of those is a foothold into your systems that the attacker may now hold. The incident is small for GitBook and potentially large for the long tail of customers who treated GitBook as a passive doc viewer rather than as a credential vault.

Timeline

What to rotate today

GitBook has already invalidated your GitBook-issued API tokens. The things GitBook cannot rotate for you are the third-party credentials you stored inside your workspace. Work through the list in this order:

1. Regenerate GitBook API tokens. Issue fresh tokens under Settings → Developer → API tokens and update every CI pipeline, infra-as-code module, and bot that uses them. Rotate any copies stored as GitHub Actions secrets, GitLab CI variables, or Vault entries.
2. Rotate Git Sync credentials. If GitBook writes back to a GitHub, GitLab, or Azure DevOps repository, revoke the PAT or re-install the GitHub App. Re-connect Git Sync with a fresh credential.
3. Rotate third-party integration tokens. For every connector in Settings → Integrations, go to the third-party system (Slack, Linear, Jira, Intercom, Figma, Zapier, Notion, etc.), revoke the existing token, issue a new one, and reconnect.
4. Rotate secrets for published integrations. If your team published a GitBook integration, regenerate its signing secret in the GitBook developer portal and push a fresh build to any downstream consumers.
5. Re-authenticate any GitBook MCP server. If your AI tooling consumes GitBook through an MCP server, re-auth the server and rotate its auth material.
6. Rotate any webhook signing secrets you configured for GitBook events, and update the corresponding receivers.

Hunt for reuse

Rotation closes the forward door. The backward question is whether the attacker used any of the stolen credentials between 19:00 CET on 2 November and when you rotated. Look back 48–72 hours in these places:

• GitHub / GitLab audit logs: unexpected clones, new deploy keys, new SSH keys on bot accounts, or pushes to default branches via the Git Sync integration outside normal working hours.
• Slack admin audit log: new app installs, posts from the GitBook bot token to channels the bot does not normally post in, token-scope expansions.
• Linear / Jira / Notion: unusual read activity on sensitive issues or pages via the GitBook integration user, exports or bulk reads.
• Your own CI: pipeline runs triggered by GitBook-issued API tokens that did not line up with a human doc change, especially runs that touched other secrets.
• Egress logs from GitBook webhook receivers: unusual source IPs delivering webhooks, replayed deliveries, or signed payloads with timestamps that do not match the original event.

The AI-agent angle

GitBook's choice of language — "a sophisticated, highly targeted attack using AI agents" — is doing some work. The advisory does not describe how the agents were used, whether they were used for reconnaissance, prompt-injection against an internal AI assistant, automated exploitation, or some combination. What it does tell the rest of the industry is that AI-driven intrusion tooling is now part of the real threat model for SaaS vendors, not a slide at a conference. If your platform exposes an AI assistant, a public-facing MCP server, or an LLM-backed support bot, assume the attack surface it adds is going to be probed the same way.

Broader lessons for SaaS buyers

• Treat every SaaS integration token as a secret to inventory, not a connector to forget. If the SaaS vendor is compromised, that token is compromised.
• Prefer short-lived, scoped credentials. OAuth with scope-minimised grants, GitHub Apps over PATs, workload identity federation over long-lived service-account keys.
• Log and alert on uses of SaaS-issued tokens inside your systems — not just outbound traffic to the SaaS vendor.
• Rehearse the rotate-everything drill. The time to find out your Terraform module has the GitBook API token hard-coded in six places is not the day of a vendor breach.

How TigerGate helps

• Secrets scanning finds GitBook API tokens, Git Sync tokens, Slack bot tokens, Jira/Linear/Notion API keys and GitHub PATs committed to source, embedded in IaC, or sitting in CI logs — the first place you look when a SaaS vendor tells you to rotate.
• Code security flags every repository that references a GitBook API token in .github/workflows, .gitlab-ci.yml, Terraform, Helm values, or Kubernetes manifests, so you can build the rotation checklist in minutes.
• CSPM and CIEM surface long-lived, broad-scoped human-issued tokens across GitHub, GitLab, Slack, AWS, Azure, and GCP — the credentials you probably handed to GitBook once and forgot.
• eBPF runtime detection watches for anomalous outbound connections from CI runners and bot accounts that could indicate a stolen GitBook-issued token being used from a new source.
• Compliance evidence maps the secret-rotation drill to SOC 2 CC6.1 and CC7.3, ISO 27001 A.5.17 (authentication information) and A.8.24 (use of cryptography), and the vendor-incident reporting your auditor will ask about at the next cycle.

Sources

• GitBook: Security incident — 3 November 2026
• GitBook customer email notifications and in-product banners, 3 November 2026