GitBook says SSO flaw led to full infrastructure access

GitBook says a flaw in its single sign-on login flow let an attacker create sessions impersonating its staff, then work through an internal GitHub integration to obtain a Cloudflare API key and production secrets. Its postmortem, published November 4 at 20:30 CET (opens in new tab), says the attacker appeared to target one customer, but could reach other customers’ stored data. GitBook is treating all customer data as exposed.

The first November 3 notice said the data investigation was ongoing and no customer action was required yet. A later update warned about potentially accessed tokens and GitBook Assistant questions. The new account explicitly includes documentation content, authenticated sites and session-signing secrets. It also says GitBook cannot determine whether the attacker acted in connected customer repositories. Restoring the documentation service does not settle those questions.

How a staff session became infrastructure access

The report, signed by CEO Sara Tandowsky and co-founder and CTO Samy Pessé (opens in new tab), describes an access-control failure followed by credential escalation. The SSO flaw allowed creation of staff-impersonating login sessions. It does not describe stolen staff passwords, name an affected identity provider or explain the validation defect behind that behavior.

Those sessions exposed authentication information for a misconfigured GitHub App installed inside GitBook’s own organization. The attacker gained access to internal code repositories and, eventually, a Cloudflare API key. GitBook does not specify the app’s misconfiguration or exactly where the Cloudflare key was obtained.

The Cloudflare key opened access to production secrets, which granted full infrastructure access through a service account. Cloudflare is the provider named in this chain; the timeline also records replacement Cloudflare Workers. The report does not establish a vulnerability in Cloudflare or GitHub itself.

The customer-side GitBook app is a separate exposure surface. GitBook says the attacker could act as that app only within repositories customers had authorized. Connected GitLab projects had a similar boundary. This was not unrestricted access to every customer repository, but an installation covering all repositories would offer a larger potential reach than one limited to a documentation repository. GitHub’s app controls (opens in new tab) let owners inspect permissions and change that selection.

The timeline leaves a second access window unexplained

GitBook’s complete published timeline (opens in new tab) uses UTC:

The prose describes about two hours and 45 minutes of production access on November 2, plus about 40 minutes early on November 3. The timeline does not identify that second window’s start, end or access path. Its November 2 cutoff therefore cannot be read as the end of all reported attacker access.

There is another distinction in the recovery record: the final GitLab rotation is listed after the “all secrets rotated” restoration milestone. Service availability and completion of every named credential rotation were not the same timestamp.

GitBook says it deliberately disabled compromised infrastructure accounts, accepting an outage rather than letting the attacker retain access during recovery. It reports recycling staging and production nodes, reversing the compromised service account’s actions, rotating infrastructure and GitBook-managed customer secrets, and disabling its back office while strengthening safeguards. Cached public sites remained available for part of the roughly 16-hour outage. Its November 4 resolution notice distinguished a continuing Git Sync problem caused by an unrelated GitHub outage.

Exposure is broader than proven theft

The postmortem’s accessible-data list (opens in new tab) includes GitBook API tokens, integration secrets, session-signing secrets, visitors’ questions to GitBook Assistant, authenticated documentation sites, connected repository access, and content such as docs, spaces and change requests. Its impact section separately lists source code, infrastructure secrets, database credentials, integration tokens and Git Sync secrets as accessed.

This supports treating credentials and stored content as exposed. It does not establish that every customer’s documents were downloaded or every secret was stolen. GitBook gives no affected-customer count or quantified exfiltration finding.

GitBook’s content-integrity assurances differ within the report. The summary and detailed content section say GitBook found no evidence that any other customer’s content was modified; the impact summary says no evidence of any customer content modification. That wording does not resolve what happened at the targeted customer, and neither formulation establishes that confidential content was unread.

GitBook says billing information, passwords and IP addresses were not compromised. The current postmortem explicitly includes visitors’ GitBook Assistant questions in its accessible-data list, carrying forward the earlier warning. Session-signing secrets remain in the latest scope, so unchanged passwords are not a sufficient basis for treating authentication material as safe. The report specifies API-token invalidation but does not separately document blanket invalidation of customer browser sessions.

What customers still need to replace

The current customer instructions (opens in new tab) divide responsibility between GitBook and its customers:

• Create new GitBook API tokens and update applications that used the revoked tokens. Revocation blocks an old credential; it does not install its replacement in a customer’s automation.
• Rotate third-party API tokens and secrets connecting other tools to GitBook, plus secrets used by published integrations. Perform revocation or rotation at the issuing service, then update the integration. Merely replacing a stored value does not invalidate a copied credential. GitHub documents token deletion (opens in new tab); GitLab documents rotation and revocation (opens in new tab), including the interruption to clients until updated.
• For authenticated access using a custom backend, regenerate the signing key in GitBook and update the backend. GitBook’s custom-backend documentation (opens in new tab) explains that this key signs visitor authentication tokens. Changing it only on one side leaves the implementation incomplete.

GitBook explicitly says no customer action is needed to rotate its managed GitHub Git Sync or GitLab keys: it rotated them. The same report’s shorter impact summary mentions reconnecting Git Sync and GitLab “if applicable.” Customers should verify their connection works and seek support if it does not, rather than assume they must manually replace GitBook-owned keys. The earlier November 3 instruction to re-authenticate GitBook MCP connections also remains in the notice’s previous updates.

Repository owners still have an investigation to perform because GitBook cannot determine whether customer repository actions occurred. Review available repository history and organization audit events (opens in new tab), and inspect the app’s authorized repositories. GitBook publishes three implicated IP addresses for environment checks. A clean search for those addresses alone cannot establish that no data was accessed.

The AI attribution remains GitBook’s assessment

GitBook’s earlier notice (opens in new tab) called this an attack “using AI agents.” The postmortem says the attacker’s speed and precision pointed to an attack driven largely by automation and AI. It does not identify a model, publish agent traces or describe evidence distinguishing AI assistance from other automation. That assessment should not be mistaken for independently demonstrated AI use.

The failure chain needs no AI attribution to explain its consequence: staff-session impersonation exposed an internal integration, then a cloud credential and production secrets. GitBook says it has closed those paths and promises further security engineering reports. Customers still lack answers about activity in their connected repositories, what data was actually taken, and how the second production-access window occurred.