GitBook Breach 2026: How an AI-Assisted Attack Reached API Tokens and Git Sync Secrets

On 3 November 2026, the documentation platform GitBook disclosed that an attacker had gained access to its infrastructure credentials the previous day. GitBook's postmortem of 4 November says the attacker went after one customer, abused a flaw in GitBook's single sign-on login flow to create sessions acting as GitBook staff, then queried the authentication details of a misconfigured GitHub App. That opened internal code repositories, which led to a Cloudflare API key, production secrets and, through a service account, full infrastructure access. GitBook describes it as "a sophisticated, highly targeted attack using AI agents". Because the attacker could reach data across the platform, GitBook treats all customer data as exposed. It took the service offline for about 16 hours, rotated every secret, invalidated all customer API tokens and asked customers to rotate integration secrets and signing keys. GitBook says billing information, passwords and IP addresses were not compromised.

At a glance

What happened

GitBook hosts documentation for software companies and connects to their code through Git Sync, a feature that keeps documentation in step with GitHub and GitLab repositories. That integration depends on machine credentials: GitHub App keys, GitLab tokens and API tokens that customers and their tools use to read and write content. A documentation platform therefore holds keys into many customers' source control, which is why an infrastructure compromise there matters well beyond the docs themselves.

According to GitBook's postmortem, the attacker hijacked the first account at the targeted customer at 12:27 UTC on 2 November 2026. At 16:32 UTC the attacker exploited a flaw in GitBook's SSO login flow to create sessions acting as GitBook staff. With those sessions, the attacker queried the authentication information of a misconfigured GitHub App, which gave access to GitBook's internal code repositories. From the code, the attacker obtained a Cloudflare API key, and from there production secrets and full infrastructure access through a service account. GitBook's timeline puts the attacker in production at 17:48 UTC. An earlier update gave the time of access as 19:00 CET, which is 18:00 UTC; the postmortem is the more detailed record and this page uses it.

GitBook's internal alerting fired at 18:10 UTC and the investigation began. The SSO flaw was fixed at 19:58 UTC, compromised accounts were disabled at 20:32 UTC and GitBook took the platform offline. Redeployment with new secrets began at 02:34 UTC on 3 November, when all existing API tokens were invalidated. GitHub App keys were rotated at 10:52 UTC, all secrets were rotated and the service was fully back by 11:56 UTC, around 16 hours of downtime, and GitLab tokens used for Git Sync were rotated at 22:51 UTC. In its notice GitBook said it had "invalidated every customer's API tokens", as quoted by Rescana. GitBook says the attack's speed and precision suggested heavy automation and AI. It has published three indicator IP addresses.

Several things remain undisclosed. GitBook has not named the targeted customer, said which AI tools it believes were involved or whether any exposed token has been used elsewhere. Rescana, writing on 4 November, noted that GitBook had not explained what "using AI agents" meant in practice. GitBook also says it cannot rule out actions in the GitHub and GitLab repositories its app could reach. The incident arrived in a fortnight of agent-assisted attacks on developer platforms, including the WorkOS breach and the Chainstack breach, but GitBook has not linked its attacker to any named campaign or framework.

Timeline

How it happened: the identity attack path

1. Customer account takeover. The attacker hijacked accounts at the one customer it was targeting. GitBook has not said how those accounts were taken over.
2. Staff impersonation through SSO. A flaw in GitBook's SSO login flow let the attacker create sessions acting as GitBook staff, turning a customer foothold into privileged internal access.
3. GitHub App credentials. Using staff access, the attacker queried the authentication details of a misconfigured GitHub App. That machine identity opened GitBook's internal code repositories.
4. Secrets in code. The repositories led to a Cloudflare API key, and the key led to production secrets. Each credential unlocked the next.
5. Service account to full infrastructure. A service account gave the attacker full infrastructure access, putting customer API tokens, integration secrets, signing secrets, Git Sync keys and database credentials within reach.

Impact

• Confirmed: unauthorised access to GitBook infrastructure, source code and production secrets on 2 November 2026, and about 16 hours of downtime while every secret was rotated.
• Potentially exposed: GitBook API tokens, integration tokens and secrets, session signing secrets, Git Sync secrets, database credentials, the Cloudflare API key, customer content, documentation sites using authenticated access and questions visitors asked GitBook Assistant. GitBook treats all customer data as exposed.
• Downstream: GitBook says it cannot rule out actions in the GitHub and GitLab repositories its app could reach, which makes customers' own source control part of the blast radius.
• Not affected, according to GitBook: billing information, passwords and IP addresses. GitBook reports no evidence of modification to other customers' content.
• Customer workload: API users must create new tokens, third-party tools and published integrations must rotate secrets, and customers using authenticated access with a custom backend must regenerate signing keys.

What this means for NHI and AI agent security

This is an NHI breach because almost every step after the first was a machine identity. The SSO flaw provided privileged sessions, but the damage came from a GitHub App whose authentication details could be read by staff sessions, a Cloudflare API key reachable from code, production secrets and a service account with full infrastructure rights. Platforms that integrate with source control hold a concentrated store of other organisations' credentials, so their internal secret hygiene is part of every customer's supply chain. Rescana's point that a GitLab Sync token must be revoked in GitLab itself, not just replaced in GitBook, shows how far one platform's keys reach.

The AI angle matters for defenders even though the details are thin. GitBook says the attack moved from a customer account to production in a little over five hours, and attributes that pace to automation and AI. Other disclosures in the same weeks, such as Microsoft's report on ARTEX agentic secret harvesting, describe agents that chain credentials far faster than a human team. When each hop takes minutes, detection based on a person reviewing alerts the next morning will be too late. Credential chains need to be broken in design, using the controls in our Secrets Management Guide and How to audit GitHub Apps and OAuth apps in an organisation, and watched with machine identity detection from our ITDR Guide.

Recommendations

• Rotate everything GitBook asked you to rotate. Create new GitBook API tokens, rotate tokens and secrets in connected third-party tools and published integrations, regenerate signing keys for authenticated access backends, and re-authenticate MCP server connections. See our Secrets Management Guide.
• Revoke at the source, not only at the platform. Where a platform held a token into your GitHub or GitLab estate, revoke and reissue it in the source system and review repository audit logs from 2 November 2026 onwards.
• Audit GitHub Apps for reachable credentials. Check who and what can read each app's private keys and installation tokens, scope installations to the repositories they need, and remove unused apps. See How to audit GitHub Apps and OAuth apps in an organisation.
• Keep long-lived keys out of code. Scan repositories for cloud provider and CDN API keys, move them to a secrets manager, and prefer short-lived, federated credentials. See our Git Secret Scanning Guide.
• Limit service account blast radius. No single service account should grant full infrastructure access. Split duties, apply least privilege and require separate approval for the most powerful roles. See our Cloud Workload Identity Guide.
• Detect machine-speed credential chaining. Alert on staff or support sessions reading integration credentials, on new use of infrastructure keys, and on rapid sequences of secret access. Hunt for GitBook's published indicator IP addresses. See our ITDR Guide.

Frequently asked questions

What was exposed in the GitBook breach?

GitBook says the attacker could reach data across the platform, so it treats all customer data as exposed. The list includes GitBook API tokens, integration tokens and secrets, session signing secrets, Git Sync secrets such as GitHub App keys and GitLab tokens, database credentials, a Cloudflare API key, source code, customer content and questions asked to GitBook Assistant. GitBook says billing information, passwords and IP addresses were not compromised.

Did AI agents carry out the GitBook attack?

GitBook describes "a sophisticated, highly targeted attack using AI agents" and says the speed and precision suggested heavy automation and AI. It has not said which tools were involved or published evidence for that view, and it has not linked the attack to ARTEX or any named group. Treat the AI element as GitBook's assessment rather than an independently confirmed finding.

What should GitBook customers do now?

Create new API tokens and update applications, rotate tokens or secrets in connected third-party tools and published integrations, regenerate the signing key for authenticated access with a custom backend, and re-authenticate MCP connections. GitBook says Git Sync keys for GitHub and GitLab were rotated on its side, but customers should still review repository activity from 2 November 2026 and check logs for the three indicator IP addresses GitBook published.

Related NHI Mgmt Group resources

ARTEX agentic secret harvesting 2026 · WorkOS breach 2026 · Railway breach 2026 · How to audit GitHub Apps and OAuth apps in an organisation · Secrets Management Guide

How NHI Mgmt Group can help

The GitBook breach shows how integration platforms concentrate machine credentials, and how fast an automated attacker can walk from one key to the next. NHI Mgmt Group helps security and platform teams map the GitHub Apps, API tokens, cloud keys and service accounts their products depend on, find the chains that link them, and build the rotation and detection routines needed when a supplier is breached. Our training covers secrets management, workload identity and the new pace of AI-assisted attacks. See our NHI and AI agent security training.

References

• GitBook: Security incident notice and postmortem (3 November 2026)
• Rescana: GitBook infrastructure breach, API tokens and Git Sync secrets (4 November 2026)
• Microsoft Security Blog: Threat actors use agentic AI tooling to find and abuse exposed secrets (5 November 2026)