The PingCAP breach: the control plane took the keys
Someone walked into PingCAP with stolen accounts for a month. The databases held. The keys, the query history, and the org records did not.
Bob Bass
The live drama in databases right now is not a product launch. It is the PingCAP breach, the breach behind TiDB Cloud, and it is still open in the way that matters: the forensics are not finished, and a leak-site story is running ahead of them.
The timeline, as published
Between September 9 and October 7 of 2026, someone used stolen service-account credentials (a compromised GitHub account included) to get into PingCAP's internal systems. PingCAP says it noticed on October 7 and began killing the credentials the same day.
From there, the incident enters the boring-but-crucial phase of disclosure. The incident report went up on October 19. On October 20, every TiDB Cloud customer got told to replace active management API keys, with that instruction spelled out in the customer actions page. On October 23 the chief executive note from PingCAP's CEO closed the week of disclosures. That is a three-document paper trail on their trust hub, and it is the reason this story can be followed from documents rather than rumors.
What actually left the building
PingCAP's account of the exfiltration is specific. What was copied, they say, is the control plane: account and organization records, SQL editor text and the errors it produced, some source code, and the values of API keys that were stored encrypted, with the encryption key not part of the stolen set.
The good news in that list is the missing item. An outside forensics firm found no evidence the attacker got into data stored in customer TiDB clusters, and no evidence they stuck around inside production systems. The database did its job. The uncomfortable news is what "no data" does not cover: names, emails, query history, and everything a customer pasted into support materials, which the company treats as the one exception worth being explicit about, because the attackers apparently got the support segment. The chief executive note is the place to read the apology in the operator's own words.
Rotation remains the standing instruction: rotate the management keys, watch for phishing aimed straight at that rotation. PingCAP is still working out exactly who had what taken.
The gap that makes it drama
Here is the part that turns a security incident into database-industry drama. A few days after the disclosure, from roughly October 24 to October 27, an extortion group claimed to be holding a large dump from PingCAP, including plaintext API keys.
Those claims do not line up with the report. Plaintext key counts are nowhere in the disclosures, and the "keys were encrypted and the encryption key was not stolen" finding sits directly opposite "here are the plaintext keys." Both things cannot be true at once, and neither side has finished proving its case. That mismatch is the drama itself: customers are being told to rotate secrets now, while a leak-site version of events circulates faster than the vendor's forensics can be updated. Rotation is free, so the advice holds; the argument is about what the eventual answer says about the attacker, not about what a responsible customer does on a Tuesday.
The structural point
The database can be fine and the vendor's account system can still expose names, emails, query history, and the keys that administer that database. That failure lives one layer above the failure everybody prices in.
An outage takes a service away and shows up in your dashboards within minutes. A control-plane breach does the opposite: it keeps the service running while handing someone your administrative credentials, your organization's shape, and the exact queries your team has been running, and it does not page anybody unless the vendor is honest and fast. When you size a database vendor's risk, size the account layer with the same care you give the storage layer. Ask the boring question while signing: who can read the query history, and where do the keys live?
From the desk that wrote this
This blog is run by the team behind Layerbase, so every post comes with a conflict of interest attached rather than concealed behind it.