GitBook infrastructure intrusion prompts API-token revocation and secret rotation

GitBook’s initial notice placed infrastructure-credential access on November 2 at 19:00 CET (18:00 UTC); the detailed postmortem below revises this approximate timing. The company attributes the targeted attack to AI agents, but names no framework or actor. The later postmortem below adds the attack path and three IPs; no CVE or affected-customer count is published. Confirmed platform access supports L4; access to the listed customer-data categories remains possible, not confirmed for every organization.

The November 3 16:21 CET notice supersedes the 13:15 CET “no action yet” position: rotate existing GitBook and connected third-party credentials, published-integration secrets, and re-authenticate MCP. GitBook says it blocked the attacker, closed the vulnerabilities and replaced its infrastructure credentials. It reports no evidence that customer content was modified, which does not rule out reads or future findings. The November 3 update reported app, API and published docs available with some degradation; this is superseded by the recovery notice below. No connection to WorkOS/ARTEX or other recent incidents is established.

Downstream documentation response: PancakeSwap’s November 3 original says its documentation is back online after migration off GitBook to infrastructure it controls, with existing links preserved. Its earlier original explicitly says its docs were not compromised and its app was unaffected; the takedown was precautionary. This does not establish an exchange breach, injected wallet drainer or customer losses, and does not replace GitBook’s credential-rotation instructions.

November 4 recovery: At 11:36 CET (10:36 UTC), GitBook declared the incident resolved and platform functionality restored. Git Sync was still affected by a separate GitHub outage. The company retains the token/secret rotations and MCP re-authentication above and promises a full postmortem within 24 hours. Availability recovery does not independently establish that every customer completed those actions or settle the possible data-access scope.

November 4 full postmortem (20:30 CET / 19:30 UTC): GitBook says an SSO login flaw allowed forged staff sessions, followed by querying a misconfigured internal GitHub App’s authentication information, access to code repositories, a Cloudflare API key, and production secrets granting infrastructure access through a service account. It treats all customer data as exposed, beyond the targeted customer; that does not establish every record was read. Accessible categories include API/integration/session-signing secrets, authenticated documentation and docs/spaces/change requests. GitHub/GitLab access was limited to repositories authorized by each customer; actual repository actions cannot be determined. The company says billing information, passwords and IP addresses were not compromised and reports no evidence of customer-content modification.

The detailed UTC chronology revises the initial approximate account: on November 2, a target customer account was hijacked at 12:27, staff sessions/code reached at 16:32, production reached at 17:48, an alert fired at 18:10, SSO was fixed at 19:58, and accounts were disabled/platform taken offline at 20:32. On November 3, redeployment/API-token invalidation began at 02:34, new Cloudflare Workers deployed at 03:09, release preparation began at 06:00, GitHub App keys rotated at 10:52, all secrets rotated/service returned at 11:56, and GitLab sync tokens rotated at 22:51. It separately reports about 2 hours 45 minutes of production access on November 2 and about 40 minutes early November 3, without full endpoints for the latter; downtime alone is not proof of final eviction. Earlier approximate timing is retained as historical reporting.

Complete the new custom-auth key step and repository investigation. GitBook-managed sync-key rotation does not rotate customer-owned third-party credentials. Its action list says no Git Sync/GitLab action is needed while its impact table mentions reconnection if applicable; both statements are retained with a support check. Earlier MCP re-authentication and Assistant-question exposure assessment still apply. The company’s automation/AI assessment does not independently identify a framework or establish a shared actor.