GitBook security incident 2026-11-02: SSO flaw and misconfigured GitHub App gave an attacker production secrets; rotate API tokens and integration secrets, re-authenticate the MCP server

View raw markdownEdit on GitHub ↗

TL;DR

GitBook says an attacker "gained unauthorized access to some of our infrastructure credentials" at 19:00 CET on 2026-11-02 in "a sophisticated, highly targeted attack using AI agents", and may have accessed integration tokens, Git Sync secrets, API tokens and the questions site visitors asked GitBook Assistant. GitBook revoked every personal API token, replaced its own credentials, and tells every organization to rotate its GitBook API tokens, rotate the third-party tokens and secrets it stored in GitBook, rotate the secrets of its published integrations, and re-authenticate the GitBook MCP server. The incident was declared resolved at 11:36 CET on 2026-11-04, and the post-mortem (20:30 CET the same day) gives the root cause: a flaw in GitBook's SSO login flow let the attacker create sessions acting as GitBook staff, those sessions read the authentication information of a misconfigured GitHub App installed as an integration, and from there the attacker reached internal code repositories, a Cloudflare API key and production secrets with full infrastructure access. GitBook says the activity focused on one customer but treats all customer data as exposed. No customer count has been published.

What happened

The vendor's timeline (incident page, all times CET). 2026-11-03 13:15: GitBook reports that it detected a security incident on 2026-11-02 and contained it, took some services offline as a precaution, calls the issue platform-wide, and says no customer action is required yet. 2026-11-03 16:21: the app, API and published docs are back, some services degraded. The attacker "gained unauthorized access to some of our infrastructure credentials at 19:00 CET on November 2". GitBook blocked the attacker, replaced credentials and secrets, invalidated customers' API tokens, took the app and authenticated docs offline while securing systems, and served published content from cache. 2026-11-04 11:36: the incident is resolved, functionality is restored, Git Sync is still affected by "a separate, ongoing GitHub outage", and "a full postmortem" covering timeline, details, response and prevention will follow within 24 hours. The page says the attacker "may have accessed" four categories: integrations tokens, Git Sync secrets, API tokens, and questions asked to GitBook Assistant by site visitors. It says there is "no evidence that any of your content in GitBook was modified". It does not say how the credentials were obtained, which AI agents were used, or how GitBook attributes the activity to agents.

How it reached the public. The incident page's first update is stamped 13:15 CET on 2026-11-03. The account that reached a wide audience was a Hacker News post at 16:45 UTC the same day ("Gitbook Breached", 162 points) by a customer who had opened a support ticket about availability and received the incident text in the reply, before any customer notification. GitBook's CTO Samy Pessé replied in the thread at 18:05 UTC that the team had been responding since the previous day and was bringing services back gradually, and at 13:54 UTC on 2026-11-04 that the incident was resolved and the post-mortem would follow within 24 hours. Commenters noted that gitbookstatus.com showed no incident while the detailed page sat under gitbook.com/status. Read on 2026-11-04, the status host still said "We're not aware of any issues affecting our systems" with no November incident marker. GitBook's X post of 2026-11-03 ("We're addressing a security incident affecting GitBook") was not opened. crypto.news quotes it.

What the tokens unlock. A GitBook API token reads and writes the organization's spaces and can publish content. A Git Sync secret is the credential GitBook holds for the customer's GitHub or GitLab repository, so a stolen one is a repository credential, not a docs credential. Third-party tokens stored for integrations are whatever the customer connected: analytics, support desks, Slack. The GitBook MCP server is how coding agents read and edit docs. Its re-authentication is on GitBook's own list, which is the first time a vendor incident page in this corpus has named an MCP connection as a thing to re-authenticate. Visitor questions to GitBook Assistant are whatever a reader typed into a public docs site's chat box, which for product docs can include account identifiers and snippets of the reader's own code.

What is separate. crypto.news reports that Trade.xyz announced unauthorized activity on its GitBook-hosted documentation on the morning of 2026-11-02, restored it by 09:15 ET, and told readers not to click links in the docs while it investigated. The outlet reports it as a separate event that Trade.xyz did not attribute to GitBook's platform and that predates the 19:00 CET credential access by hours. GitBook's incident page does not mention it. PancakeSwap took its GitBook docs offline after the GitBook notice, per the same outlet. Neither is confirmed as connected to the GitBook credential access. Both are recorded here because a reader whose docs link to wallets or downloads should assume a modified docs page is the attacker's easiest monetisation of a docs-platform breach, and GitBook's "no evidence of modification" statement is scoped to its investigation so far.

The pattern. This is the second documentation or developer-tooling SaaS in a week, after WorkOS (2026-10-30), to attribute an intrusion to AI agents without naming the framework, and the eighth hosted developer platform since 2026-10-09 to report theft of stored customer secrets (Fireworks AI, Lightning AI, OpenCode Console, Zeabur, Railway, Northflank, Trigger.dev, each tracked here, and not WorkOS, whose incident exposed CRM data rather than secrets). SecurityWeek's 2026-11-04 roundup counts "at least a dozen" platforms and quotes Wiz on a market for stolen inference credentials. GitBook is not in that article.

Am I affected?

  1. Every GitBook organization is affected by the token revocation. Any CI job, script, agent or integration that used a personal GitBook API token stopped working on 2026-11-03 and needs a new token.
  2. List what GitBook held for you. In the organization settings: Git Sync configurations (which repositories, which GitHub App installation or GitLab token), integrations and their stored third-party credentials, published integrations and their secrets, and MCP server connections.
  3. Check the GitHub or GitLab side. For each synced repository, review the installation or deploy token GitBook used and the repository's recent commits and pushes since 2026-11-02 18:00 UTC for anything not made by your team.
  4. Check your docs. Diff published content against the repository for changed links, addresses or download URLs, especially on pages that point readers at wallets, installers or support channels.
  5. GitBook Assistant on a public site: assume the questions readers asked since the site enabled the assistant may have been read. GitBook has not given a date range.

If you are affected

  • Rotate GitBook API tokens (the old ones are already revoked), the third-party tokens stored for integrations, and the secrets of published integrations, in that order, as GitBook's page instructs.
  • Git Sync: the post-mortem says GitBook rotated the GitHub App keys and GitLab tokens itself and no customer action is needed; still audit each synced repository for commits, pushes or app actions since 2026-11-02 16:32 UTC, because GitBook says it cannot determine whether any were taken. See if your GitHub PAT leaked.
  • Authenticated access with a custom backend: regenerate the signing key in the GitBook app and update the backend (the one customer action the post-mortem adds).
  • Re-authenticate the GitBook MCP server in every agent that had it configured, and remove stale entries from .mcp.json, Cursor and Claude Code MCP settings. See MCP hygiene.
  • If a docs page was altered, publish a notice to readers before restoring it, because the altered page is what readers already acted on.
  • The post-mortem is published (2026-11-04 20:30 CET, summarised in the Update below); GitBook promises further write-ups in the coming weeks.

Prevention

  • Give docs platforms least privilege on the repository: a GitHub App installation scoped to the docs repository, not an organization-wide token. See credential hygiene.
  • Keep an inventory of which SaaS platforms hold which tokens. This month's platform breaches are being disclosed days apart and rotation has to start the same day.
  • Treat an MCP server connection as a credential: it carries the user's authorization to a third-party service and belongs in the rotation list after a vendor incident.

Update 2026-11-05: the post-mortem (2026-11-04 20:30 CET) names an SSO flaw and a misconfigured GitHub App; status moves to contained

GitBook's fourth update is the post-mortem. Root cause: "Using a flaw in GitBook's SSO login flow, they were able to create login sessions acting as GitBook staff." Those sessions could query the authentication information of a misconfigured GitHub App installed as an integration, which gave access to internal code repositories and then a Cloudflare API key; production secrets followed, granting full infrastructure access through a service account. GitBook says the activity "focused on a single customer" whose account was hijacked at 12:27 UTC on 2026-11-02, but because the attacker could reach shared customer data it treats all customer data as exposed. The post-mortem attributes the intrusion to automation and AI without naming an agent or framework, and cites Anthropic's late-2025 report of an AI-driven campaign as context, not as a link to this incident.

Timeline, UTC: 2026-11-02 12:27 first hijacked account at the targeted customer; 16:32 staff sessions, then source code access; 17:48 production reached; 18:10 internal alert; 19:58 SSO flaw fixed; 20:32 compromised accounts disabled, attacker cut off, app taken offline. 2026-11-03 02:34 redeployment with new secrets begins and all API tokens are invalidated; 03:09 new Cloudflare Workers deployed; 10:52 GitHub App keys rotated; 11:56 all secrets rotated and GitBook fully online; 22:51 GitLab tokens for Git Sync rotated. The app was offline from 20:32 UTC on 11-02 to 11:56 UTC on 11-03.

Affected data, per the post-mortem: GitBook API tokens, integration tokens and secrets, session signing secrets, visitor questions to GitBook Assistant, documentation sites using authenticated access, and customer content (docs, spaces, change requests) with no evidence of modification. On GitHub, the attacker could act as the GitBook app in repositories customers had authorized, and GitBook "cannot determine whether any action was taken" there; the same holds for GitLab projects. Billing information, passwords and IP addresses were not compromised. Customer actions are unchanged except two clarifications: Git Sync keys for GitHub and GitLab were rotated by GitBook and need no customer action, and sites using authenticated access with a custom backend must regenerate the signing key in the GitBook app and update the backend. GitBook lists three attacker IP addresses as indicators; they are not reproduced here. The 2026-11-04 11:36 update also attributed a lingering Git Sync problem to "an unrelated ongoing GitHub outage".

Status moves from ongoing to contained: the vendor says the attack paths are closed, every secret is rotated, and further write-ups will follow. The repository-side uncertainty stands: audit GitBook-authorized repositories for actions since 2026-11-02 16:32 UTC, because the vendor cannot.

Sources