An attack GitBook calls largely AI-driven went from staff logins to production in 76 minutes

What the agent did

• 12:27 UTC: first hijacked account at the targeted customer; 16:32: sessions acting as GitBook staff via an SSO flaw, then source code
• From there: the credentials of a misconfigured GitHub App integration, internal repos, a Cloudflare API key, then production secrets with full infrastructure access through a service account
• 17:48: production reached, 76 minutes after the staff sessions by our calculation; an internal alert fired 22 minutes later, at 18:10
• The attacker had production access for about 2:45 hours that evening and about 40 minutes early on 3 November
• GitBook cut the attacker off at 20:32 by taking itself offline for about 16 hours, then rotated every secret and invalidated all earlier API tokens

What it means for you

• Inventory the credentials your integrations and agents can read: GitHub Apps, cloud API keys, service accounts. One misconfigured app plus one long-lived key was the whole path here; prefer short-lived, least-privilege tokens.
• Rehearse a kill switch. GitBook chose a 16-hour outage over letting the attacker keep looking around; decide in advance who can take production offline and how secrets get rotated.
• If you connect docs, MCP servers or Git sync to a SaaS vendor, its breach is yours: GitBook told customers to rotate integration secrets and re-authenticate its MCP server.

Why it matters

Each step was an ordinary weakness: an SSO bug, an over-privileged integration, a key that opened production. What GitBook says changed is the tempo, about five hours from the first customer account to production, which it puts down largely to automation and AI. Defences that rely on someone noticing within a working day are now too slow.

The AI attribution and the impact are as reported by GitBook; it has not said which tools the attacker used, and its fuller write-up is still to come.