Threat intel
PingCAP breach: what TiDB Cloud users should rotate
Stolen service account credentials gave an intruder four weeks inside PingCAP. What is confirmed, what FulcrumSec claims, and what TiDB Cloud users should do.
PingCAP, the company behind the TiDB distributed SQL database and its managed service TiDB Cloud, published a security report on October 19. Between September 9 and October 7, an unauthorized party used stolen service account credentials to reach internal PingCAP systems, copy data and obtain source code. PingCAP noticed on October 7 and began disabling the credentials that day.
If your company has a TiDB Cloud organization, assume some of its metadata left the building: user names and email addresses, the text of queries typed into the console's SQL editor, and, for paying customers, contract and billing records. PingCAP says it has no evidence that data stored in TiDB databases was affected. The same day, the extortion group FulcrumSec listed PingCAP on its leak site with much larger numbers that PingCAP has not verified.
How it works
A service account is a non-human identity that software uses to call other systems: a pipeline that exports data, a job that syncs billing, a tool that reads from cloud storage. Its credentials are usually long-lived keys or tokens rather than a password plus multi-factor authentication (MFA), so whoever holds the key is the account. Nobody gets a login prompt on their phone when it is used from a new place.
PingCAP has not said how the credentials were stolen. Its remediation steps show what they could reach. On October 10 it deleted more compromised credentials, removed excess cross-project permissions and turned on extra cloud storage access logging. Cross-project permissions mean one identity could read resources in more than one cloud project, so a single stolen key opened more than the system it was made for. The missing storage logs also explain how copying could run for four weeks before anyone saw it.
On October 12 and 13 an external incident response firm reported four vulnerabilities. PingCAP fixed all four by October 14 and the firm confirmed the fixes. PingCAP has not described them and has not said they were the way in. By October 14 all identified compromised credentials were invalid and the known access paths were blocked. The firm found no evidence of command execution or persistence in the production systems it reviewed, which means no sign the intruder ran code there or left a way back.
What was taken, and what is only claimed
PingCAP lists these categories as affected so far:
- TiDB Cloud account data: user names, email addresses, organization and project associations, and some organization, project and cluster identifiers.
- SQL editor text and error messages.
- Business records: customer contacts, contract terms, orders, pricing, payment terms and billing configuration.
- An exported table of encrypted TiDB Cloud API key values. One value PingCAP tested could not be used directly as an API key, and whether other usable credentials were exposed is still under review.
PingCAP stresses that not every customer had every category exposed. A Japanese notice published on October 21 puts the count for Japan at up to about 50,000 personal records, and says there was no unauthorized access to TiDB Cloud itself and no credit card data leaked.
FulcrumSec's account is far larger. It claims about 10.6 TB across roughly 4.9 million files, published about 200 GB as a first sample, and says more than 180,000 organizations are affected. Other reports of its claims add about 115,000 API keys described as plaintext and 20.6 million customer SQL statements. PingCAP has confirmed none of these figures and has not publicly attributed the intrusion to FulcrumSec. The plaintext claim conflicts with PingCAP's statement that the exported key values were encrypted.
One company on FulcrumSec's list has responded. Bitget, a crypto exchange, confirmed it had used TiDB Cloud but said it stored only non-sensitive public trade logs there and had stopped using the service more than two months earlier. Until PingCAP finishes its customer-specific review and notifies affected organizations directly, plan around the confirmed list and treat the claims as a reason to move quickly.
What to do
- Replace your management API keys. PingCAP's customer actions page of October 20 asks organization owners to do this now as a precaution. In the TiDB Cloud console, switch to the organization, open Organization Settings, then API Keys, and click Create API Key with the role and scope the job needs. The private key is only shown once. Move every script, Terraform run and pipeline to the new key, confirm each still works, then delete the old key from the row menu. Repeat for every organization you own. If you suspect a key was misused, delete it straight away without creating the replacement first, then contact PingCAP's security team as its customer actions page describes, leaving any secret out of the message.
- Find secrets that passed through the console as text. SQL editor text is on the confirmed list, so anything typed there may be in someone else's hands. Search your team's habits and saved queries for
CREATE USER ... IDENTIFIED BY,ALTER USER,SET PASSWORD, connection strings and cloud tokens used in import or export statements. Rotate each of those in the system it belongs to. Rotating a TiDB Cloud API key does not change a database user's password or a third party token. - Review activity from September 9 onward. TiDB Cloud has Console Audit Logging in the left navigation, available to Organization Owner and Console Audit Manager roles. Filter for
CreateAPIKey,EditAPIKey,DeleteAPIKeyandInviteUserToOrganization, and download the result as JSON or CSV. It is disabled by default, records only what happens after you switch it on and keeps 90 days, so if it was off you have no console history for the incident window. Fill the gap with your own logs: the source addresses your API clients connect from, and database audit logging if you run it. - Clean up members and access. Remove dormant users and excess roles from each organization. Restrict database network access with an IP access list or private connectivity, so a leaked password is not enough on its own.
- Brief finance and engineering about phishing. Contract, order and payment terms are confirmed as exposed, which is exactly what a convincing fake invoice or "update your billing details" message needs. PingCAP asks customers to verify unexpected requests through a channel they already trust, not the contact details in the message.
The wider lesson: service accounts
This is the second cloud platform this month where an intruder got in by holding a valid machine credential instead of breaking anything. The controls that would have shortened PingCAP's four weeks apply to every team running pipelines and integrations:
- Inventory service accounts and their keys, with an owner and a last-used date for each. Delete what nobody claims.
- Prefer short-lived credentials: workload identity federation or OIDC tokens issued per job, instead of exported JSON keys or static access keys.
- Scope each identity to one project and the specific buckets or tables it needs. Cross-project read is the permission PingCAP had to cut.
- Turn on data access logs for storage before you need them, and alert on bulk reads and exports by a service account outside its normal schedule or source.
- Run secret scanning on repositories and ticket systems, where these keys tend to end up.
Our cloud and Kubernetes security work reviews service account scoping, key age and logging coverage across your cloud projects, and our security operations team can build the bulk export alerts described above. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would run the work.
Sources: PingCAP security update, October 2026, PingCAP recommended customer actions, TiDB Cloud console audit logging documentation, SOCRadar, Crypto Briefing, RuntimeWire, aiidelist, Hakky Handbook on the Japan notice, Ayi NEDJIMI Consultants, zeli.