GitBook breach (Nov 2–3): what to rotate

What GitBook has said (Nov 3–4)

• Nov 2, UTC: the first account at the targeted customer was hijacked at 12:27. Through a flaw in GitBook's SSO login flow the attacker created sessions acting as GitBook staff (16:32), read the credentials of a misconfigured GitHub App in GitBook's own organization, got into its internal repositories and a Cloudflare API key, and reached production at 17:48. GitBook fixed the SSO flaw at 19:58 and cut the attacker off at 20:32, taking the app offline.
• Nov 3, UTC: all existing API tokens invalidated from 02:34; GitHub app keys rotated at 10:52; all secrets rotated and GitBook back online at 11:56, about 16 hours after it went down; GitLab tokens used for Git Sync rotated at 22:51.
• GitBook says the attack was aimed at one customer and that it found no evidence any other customer's content was modified. On repositories it is less certain: the attacker "could act as the GitBook app, but only in the repositories each customer had given the app access to. We cannot determine whether they took any action in customer repositories." The same goes for connected GitLab projects.
• Customer emails with these steps went out on Nov 3. If you run a GitBook organization, check that inbox first.

Rotate what GitBook lists

These five come from GitBook's "What you need to do" list; the MCP line is from its Nov 3 update. For any secret issued by another service: revoke it there, create a replacement, and update both ends.

1. GitBook API tokens. "We revoked all personal API tokens, but customers' existing apps need to be updated." Create a new token in the Developer settings of your GitBook user account and put it wherever the old one lived: CI jobs, scripts, docs pipelines, internal tools.

2. Third-party tokens that connect other tools to GitBook. "Rotate any third-party API tokens or secrets you use to connect other tools to GitBook." Revoke each at the service that issued it, not just in GitBook. Our note: if one of them was a payment key, a Stripe secret key can create charges, issue refunds and read customer data; roll it as in rotating a leaked Stripe key without breaking webhooks, and afterwards a read-only scan such as Stripe Leak Check flags card-testing bursts, fraud warnings you can still refund and disabled webhook endpoints, using only a read-only restricted key.

3. Secrets in integrations you published. "If you have published integrations that use secrets, rotate those secrets."

4. Authenticated access with a custom backend. "Regenerate your authenticated access signing key in the GitBook app and update it in your backend implementation." Session signing secrets were on GitBook's list of reachable data, so do this even if nothing looks wrong.

5. GitBook MCP server. The Nov 3 update: "If you use the GitBook MCP server, re-authenticate it."

Want us to run it for you? The Ship Check Audit lists every key that ever left your server and confirms each old value now gets a 401 or 403: $149, within 48 hours.

What GitBook already rotated

• Git Sync (GitHub app): "No action needed. We rotated these keys for you."
• GitLab: "No action needed. We rotated these keys for you."
• The same post-mortem's impact summary lists "reconnecting Git Sync and GitLab, if applicable" under customer action. Our note: if a space stopped syncing after Nov 3, reconnect it; otherwise there is nothing to do. GitBook's Nov 4 morning update said Git Sync was also affected by an unrelated GitHub outage.

Review the repositories the app could reach

GitBook can't say whether the attacker did anything in customer repositories, and suggests no specific check. Our note: it takes a few minutes per repository, so look.

1. In each repository the GitBook app had access to, list commits since Nov 2 on every branch and look for any you or GitBook's normal sync didn't make:

   git fetch --all --prune
   git log --all --since="2026-11-02" \
     --format="%h %ad %an <%ae> %s" --date=iso

2. Check new branches, tags, pull requests and changed workflow files (.github/workflows/, .gitlab-ci.yml) in the same window. A workflow change can run code with your CI secrets.

3. On GitHub, read the organization's audit log for activity by the GitBook app; on GitLab, the project audit events.

Then check that the old values are dead

1. An old GitBook token should now be refused. GitBook says it invalidated all tokens issued before its cutoff; confirm it with the endpoint from its API docs (401 means revoked):

   curl -s -o /dev/null -w "%{http_code}\n" \
     https://api.gitbook.com/v1/user \
     -H "Authorization: Bearer $OLD_GITBOOK_TOKEN"

2. GitBook published three IP addresses implicated in the attack and recommends reviewing your environments for any mention of them. Search API, proxy and cloud logs from Nov 2 onward:

   grep -rE "94\.183\.188\.91|45\.139\.84\.195|198\.251\.83\.217" /var/log/

Not on Wiz's list

GitBook isn't one of the twelve AI developer platforms in Wiz's "Black October" post (latest edit Nov 3, 15:40 UTC), but the pattern is close: GitBook calls the attack one "driven largely by automation and AI." If you also used one of those twelve, see Black October: every AI dev platform breach in one list. A key you rotated after one of them and then gave GitBook needs rotating again.