PingCAP builds the open-source distributed database TiDB and runs the managed TiDB Cloud service. The company has confirmed that someone used stolen service-account credentials to get into its internal systems between September 9 and October 7, 2026. The intruder copied customer data and took source code. PingCAP's English incident report on its Trust Hub, dated October 19, says the company found the intrusion on October 7 and had closed every access path it identified by October 14. Frontier Now reports that PingCAP's Japan unit puts the leak there at up to 50,000 personal records. The extortion group FulcrumSec has listed PingCAP on its leak site and claims much more: 10.6TB of data and more than 180,000 tenant organizations. PingCAP has not confirmed any of the attacker's figures.
What Happened
PingCAP's timeline, taken from its Trust Hub report and repeated by Frontier Now and Safeguard:
- Sept 9 to Oct 7: An unauthorized party used stolen service-account credentials to reach "certain PingCAP internal systems, copy data, and obtain source code."
- Oct 7: PingCAP found the intrusion and started disabling the affected credentials that day.
- Oct 10: More compromised credentials were deleted, and excessive permissions between cloud projects were removed. PingCAP also turned on cloud storage access logging in an affected project.
- Oct 12 to 13: An outside incident response firm reported four vulnerabilities.
- Oct 14: All four were fixed and retested. PingCAP says every compromised credential it identified had been invalidated and every known access path blocked.
- Oct 19: FulcrumSec added pingcap[.]com to its leak site, according to SOCRadar and Safeguard. The same day, PingCAP published its English incident report.
- Oct 20: PingCAP published a customer actions page.
- Oct 21: PingCAP updated its Japanese customer notice, adding exposed categories that the English report does not list (see below).
The outside firm found no evidence that the attacker ran commands or kept persistent access in the production systems it reviewed. PingCAP says it has no evidence that customer data stored in TiDB databases was affected. The company also notes that these findings "do not change the data exposure." PingCAP is still working out which data belonged to which customer.
What Was Taken
Confirmed by PingCAP:
- TiDB Cloud account and product-use data: usernames, email addresses, organization and project associations, and SQL editor text and errors. Some records also included organization, project and cluster identifiers.
- Business and billing data: customer contacts, contract terms, orders, pricing, payment terms and billing configuration.
- API keys: one table of encrypted TiDB Cloud API key values.
- Source code: PingCAP has not said what the source code covers.
- Support tickets: OneSignalDesk reports that PingCAP's Japanese notice added "inquiry and support ticket information" on October 21. The English report does not list this category.
Record counts disagree:
- PingCAP's Japan unit says up to 50,000 personal records leaked, according to Frontier Now. That figure appears to cover the Japanese customer base only.
- FulcrumSec claims about 10.6TB in 4,901,203 files, covering 180,046 tenant organizations (Frontier Now, Crypto Briefing).
- FulcrumSec also claims 115,308 "plaintext" API keys, 42,612 of them allegedly still active (Frontier Now).
The API key claims contradict PingCAP directly. PingCAP says the key values were encrypted and that it has found no evidence any were decrypted or used. The company says its outside firm tested one investigator-owned key and could not use it, which is narrow evidence either way. Crypto Briefing reports that FulcrumSec published a sample of about 200GB, which had not been independently verified as of October 20. Treat every FulcrumSec figure as an unverified claim.
Named customer response: FulcrumSec's list of affected clients names the crypto exchange Bitget. Xie Jiayin, Bitget's head of Greater China, confirmed the exchange had used TiDB Cloud. Xie said it stored only non-sensitive public trade logs there and that Bitget stopped using the service more than two months ago (Crypto Briefing).
Why It Matters
- Upstream provider risk: PingCAP is an infrastructure provider, so a breach there carries downstream risk for its customers. SOCRadar makes this point too. Even if customer databases were not touched, the stolen data is useful to an attacker. Contacts, contract terms, billing configuration and SQL editor text are exactly what someone needs to write convincing phishing or invoice fraud aimed at engineering and finance teams.
- SQL editor text: Queries and error messages typed into the editor can reveal schema names, table structures and sometimes literal values.
- Stolen source code: Attackers can study it to find vulnerabilities in TiDB Cloud.
- Audits don't cover operations: Hacker News commenters pointed out that PingCAP had recently announced an NCC Group source-code security assessment. The incident shows that a code review does not protect service-account credentials or cloud IAM. In one commenter's words, "your system can still leak if you don't secure your operations."
The Attack Technique
PingCAP says only that the intruder used stolen service-account credentials. It has not said how they were stolen. Its fixes point to some contributing factors:
- Excessive permissions between cloud projects let the intruder move across projects. PingCAP removed them on October 10.
- Cloud storage access logging was off in at least one affected project. That gap probably explains why the intrusion went undetected for about four weeks.
- Four vulnerabilities were reported by the outside firm. PingCAP has not described them.
SOCRadar searched stealer logs for pingcap[.]com and found 25 records dated April to September 2026. All of them belonged to external users of customer, education and support portals, not to internal corporate accounts. Nothing published connects those logs to the stolen service-account credentials, and the initial access vector is still unknown.
What Organizations Should Do
- Rotate TiDB Cloud management API keys now. Create new keys, move your applications to them and confirm they work, then revoke the old keys. Only organization owners can do this. If you suspect a key has been misused, revoke it immediately even if that breaks an integration, and contact [email protected].
- Review access logs, members and roles in your TiDB Cloud organizations, as PingCAP's Japanese notice advises. Remove stale users and keys you no longer need.
- Check SQL editor history and support tickets for secrets. Credentials, connection strings or sensitive values that appear in queries or tickets should be treated as exposed and rotated.
- Warn finance and engineering staff about targeted phishing. Leaked contract, pricing and billing data makes fake PingCAP invoices and "security update" emails believable. Confirm any unexpected request through a channel you already trust.
- Audit your own service accounts. Scope permissions to individual projects, remove trust between projects, and turn on storage access logging everywhere. Missing controls of exactly this kind gave PingCAP's intruder a month of access.
- Add database vendors to third-party risk tracking. Watch for further PingCAP updates on per-customer scope, and assume your organization is affected until PingCAP tells you otherwise.
Sources: PingCAP confirms unauthorized access — Frontier Now | Security Update – October 2026 Security Incident Report: Unauthoriz... | TiDB Cloud Security Incident: What Customers Should Do OneSignalDesk | Bitget says no user data exposed in alleged TiDB Cloud breach | PingCap TiDB Leaks Better HN | Customer Actions October 2026 Security Incident Report | PingCAP / TiDB Cloud Data Breach | TiDB Cloud Breach (October 2026): What Happened and What to Do Saf...