What changed
Between September 9 and October 7, 2026, an intruder used a compromised GitHub identity and credentials exposed in private repositories and Terraform state to reach PingCAP's internal cloud, analytics and support systems. The October 19 incident report and October 21 commissioned NebuSec forensic analysis confirm copied source code, customer control-plane metadata, SQL editor history and errors, CRM/billing records, support tickets and diagnostic files. Encrypted TiDB Cloud management API-key values were among exported tables; the encryption key was not exposed, but separate plaintext credentials had been shared in support materials and some were accessed. PingCAP says it found no evidence the attacker accessed data inside live customer TiDB databases, ran commands or persisted in reviewed production systems. By October 14, identified compromised access paths were closed and four vulnerabilities found during the response were patched and retested. October 20 customer guidance recommends precautionary rotation of all active TiDB Cloud management API keys, and the October 23 CEO statement additionally urges rotating any secrets previously supplied to support.
Why it matters
Cloud service customers can be exposed through a provider's control plane, internal analytics or support systems without their live database contents being directly accessed. SQL editor text, connection details, support attachments and billing contacts can reveal operational information or secrets, while compromised keys stored in support workflows may enable downstream access. TiDB Cloud organisation owners should create replacement management keys, test integrations, then revoke old keys; immediately revoke suspected compromised credentials, review access logs and rotate passwords, connection strings or cloud keys supplied through support. Self-managed TiDB deployments are not automatically affected by this incident. Customer-specific impact remains under investigation, so absence of a notice is not proof a particular organisation's metadata was untouched.
The path from a compromised developer identity to cloud exports
NebuSec says the attacker gained access to private repositories through a compromised GitHub account and recovered service-account keys and tokens from repository contents and Terraform state. Those credentials enabled access to Google Cloud, Jira and internal messaging. Credentials stored in support tickets enabled further access to S3 diagnostic buckets. BigQuery export jobs on September 23–24 and later Cloud Storage downloads copied internal records. This is a documented internal-system compromise, not a demonstrated exploit of the open-source TiDB database engine.
What was copied — and what investigators did not find
Confirmed exposed categories include customer account names/emails, organisation and cluster metadata, SQL editor text/errors, support tickets and attachments, billing/contracts and some encrypted management API-key values. The external firm reports no evidence of live production database row access, attacker command execution or persistence in the production environments reviewed. These findings do not mean no customer data was exposed: customer-specific scope is still being established, and support materials could include usable credentials.
Containment and four separately discovered flaws
PingCAP began revoking compromised credentials October 7 and says identified access paths were blocked by October 14. During a source-code review, NebuSec reported four vulnerabilities with potential production impact; the vendor fixed all four and the firm retested the fixes. Retrospective log review found no evidence of those flaws being exploited. Those findings should not be conflated with the original stolen-credential intrusion.
Practical customer response
PingCAP's October 20 action page recommends that every TiDB Cloud organisation owner replace active management API keys without waiting for a customer-specific notification. Create a new key with appropriate role/scope, update and verify dependent scripts and services, then revoke the old key. If misuse is suspected, revoke immediately. The October 23 CEO note adds rotating secrets shared with support and treating unexpected payment, password or verification requests as potential phishing. Assess whether SQL editor text or support files included other secrets.