The GitBook breach has moved from an outage story to a credential-cleanup task. In its November 4 postmortem, the documentation platform described how an attacker reached its production infrastructure—and set out which API tokens and integration secrets customers still need to replace.
For crypto teams using GitBook to publish documentation or connect repositories, the important distinction is between restoring the service and completing their own remediation. GitBook says the platform was fully back online on November 3. That does not automatically update credentials inside a customer’s applications or third-party tools.
Which GitBook credentials need replacing?
The company’s official incident guidance separates the work by how a customer uses the platform:
- GitBook API users: create a new API token and update the applications that use it. GitBook says it revoked all personal API tokens.
- Connected third-party tools: rotate the API tokens or secrets used to connect those tools to GitBook.
- Published integrations: replace their secrets where those integrations use them.
- Authenticated documentation with a custom backend: regenerate the authenticated-access signing key in GitBook and update the backend implementation.
GitBook says it rotated GitHub Git Sync keys and GitLab tokens on customers’ behalf. That is separate from the customer-managed credentials above; it should not be read as confirmation that every connected application has already been updated. Teams should follow the official incident page rather than share secrets with third-party checking services.
What the new postmortem says happened
GitBook dates the initial unauthorized access to November 2. It says a flaw in its single sign-on login flow allowed the attacker to create sessions impersonating staff. A misconfigured GitHub App then provided a route into internal repositories, where the attacker obtained a Cloudflare API key. Access to production secrets ultimately enabled broader infrastructure access through a service account.
The company took the application offline while containing the incident and replacing credentials. Its timeline records an outage from 20:32 UTC on November 2 until 11:56 UTC on November 3, approximately 16 hours. Cached published sites remained available for part of that period.
Accessible data is not the same as confirmed misuse
According to GitBook, accessible customer material included API and integration credentials, authenticated documentation, session-signing secrets and content. GitHub and GitLab access was limited to repositories or projects customers had authorized the integrations to reach. The company says it cannot determine whether the attacker took action in those customer repositories.
GitBook says the activity appeared focused on one customer, but it treated all stored customer data as exposed because the attacker could reach it. It reports no evidence that other customers’ content was modified and says billing information, passwords and IP addresses were not compromised. Those are the company’s findings, not proof that every accessible item was copied—or a guarantee about every connected system.
Was this an AI attack or a cryptocurrency theft?
GitBook says the attack’s speed and precision pointed to automation and AI. That remains its assessment: the postmortem does not identify a particular AI tool or establish exactly how it was used. Decrypt’s November 3 coverage reported the initial disclosure and precautions taken by crypto projects; it predates the detailed November 4 account.
The disclosed incident is a compromise of a documentation provider and its connected credentials, not established evidence of drained cryptocurrency wallets or a blockchain-protocol exploit. For affected teams, the next useful check is concrete: identify their GitBook connections, complete the applicable credential replacements and review relevant repository activity without assuming that service restoration settled every customer-side risk.
