A group calling itself FulcrumSec has published a leak page claiming it exfiltrated 10.6 TB of data from TiDB Cloud, the managed database service operated by PingCAP. The scale of that claim is disputed, but the intrusion itself is not: PingCAP has published an incident report on its trust hub confirming an unauthorized party used stolen service account credentials to access internal systems between September 9 and October 7, 2026. The company says it learned of the breach on October 7 and began invalidating the compromised credentials the same day.
This is a messy story, and the mess matters. The vendor confirms one thing, the attacker claims much more, and the gap between those two accounts is where customers are currently living.
What PingCAP has confirmed
PingCAP’s report, dated October 19, lists the data categories it has verified as exposed so far. For TiDB Cloud accounts, that includes user names and email addresses, organization and project associations, and SQL editor text and errors, some of it carrying organization, project and cluster identifiers. Business records exposed include customer contacts, contract terms, orders, pricing and billing configuration. One exported table contained encrypted TiDB Cloud API key values; PingCAP says an outside security firm tested one of those values and could not use it directly as a key.
Two findings in the report are worth reading closely. First, the external investigators reviewed production systems and found no evidence the attacker ran commands or kept persistent access in the systems reviewed, and no evidence that data stored inside TiDB itself was touched. Second, PingCAP says the attacker’s claims about credentials in support materials have not been verified. The company also reported four vulnerabilities identified during the investigation, all fixed by October 14, and says it rotated leaked keys and reported the incident to law enforcement and regulators.
There is a geographic wrinkle: PingCAP’s Japanese notice, updated October 21, says up to about 50,000 items of personal information belonging to people in Japan were leaked, and it lists support ticket information among the exposed data. The English report did not mention that last category, so the confirmed scope appears to still be growing.
What the leak page claims
FulcrumSec’s account is far larger. The group says it exfiltrated 10.6 TB across 4.9 million files, including a replicated copy of the production control plane with 180,046 tenant organizations, roughly 115,000 console API key pairs stored in plaintext, 20.6 million raw SQL statements captured from the SQL editor and Chat2Query, four years of gateway access logs covering over 100 million connections, 413 private source repositories, Jira, CRM and finance data, and tenant-tagged AWS cost records. It claims it ran a replication feed of the control plane database using credentials committed in PingCAP’s own repositories, re-exporting every table every six hours from September 8 to September 30 with no detection event.
Treat these numbers as claims, not facts. Independent coverage has noted that the attacker’s larger totals and the plaintext key claim remain unverified. What the page does document, in screenshots and file listings, is the general shape of an attack that succeeded across multiple cloud providers at once: AWS, GCP, Azure and Atlassian. Even a partial version of that picture is bad for a company whose entire business is operating other people’s databases securely.
The 2022 ticket the attackers cite
The leak page quotes an internal security ticket, which it labels SECURITY-22 and dates to August 2022, in which PingCAP’s own security team described a multi-tenant isolation problem: any role within a customer organization, including a billing-only role, could unconditionally reset the root password of every cluster in that organization. The attackers present this as evidence the company knew about weak tenant isolation years before the breach. The ticket’s authenticity is unverified, and PingCAP has not addressed it publicly in the notices published so far. If it is genuine, it describes a design decision that has since been fixed or not; the incident report does not say.
Why this matters beyond PingCAP
Most managed database incidents you hear about involve the database. This one appears to be about everything around the database: support tooling, billing systems, source control, CRM. The alleged capture of 20 million customer SQL statements is the part that should make any SaaS operator uncomfortable, because people paste secrets into SQL editors and support tickets constantly. Connection strings with passwords, API keys in configuration inserts, credentials in slow-query logs. If your vendor captures and stores those transcripts, your secrets are now in your vendor’s blast radius, and their security posture is your security posture.
There is also a detection lesson here. The attackers say they ran an automated exfiltration pipeline every six hours for weeks against a cloud infrastructure company without triggering an alert. Whether or not every number holds up, PingCAP’s own timeline, September 9 to October 7, means the intrusion went undetected for close to a month inside a company that operates a multi-tenant database platform.
What to do if you run workloads on TiDB Cloud
PingCAP’s Japanese notice gives customers a concrete checklist, and it is a good template for any vendor breach:
- Rotate your TiDB Cloud API keys now. Create the replacement, update your scripts and CI, then delete the old key.
- Review access logs for connections from IP addresses you do not recognize.
- Audit your organization’s members and roles, and remove access that is no longer needed.
- Assume anything you typed into the SQL editor or a support ticket may have been captured. If a password, token or connection string passed through either, rotate that secret too.
- Watch for phishing that impersonates PingCAP. The company says it will never ask for passwords or access keys by email.
The last item on that list applies to everyone, not just TiDB customers. The SQL editor history is the uncomfortable one. Search your own history for anything secret-shaped and treat those secrets as exposed until rotated.
PingCAP says it will notify affected customers directly once it has established customer-specific impact, and both notices promise updates as the investigation continues. Until that work finishes, the honest summary is this: the intrusion is confirmed, the vendor-confirmed exposure covers account, billing and SQL editor records, and the attacker’s 10.6 TB figure and plaintext key claims sit in the unverified column. For a managed database vendor, even the confirmed list is damaging, because the product being sold is precisely the trust that was breached.