PingCAP confirms TiDB Cloud data and source code breach

PingCAP, the company behind TiDB (an open-source distributed database compatible with MySQL), confirmed unauthorized access to internal systems and the theft of source code and customer-related data. The case was reported by InfoQ on October 25, 2026, based on an incident report from the company itself and claims from the cyber extortion group FulcrumSec.

The group claims to have extracted 10.6 TB of data, including TiDB Cloud control-plane records, customer SQL statements, API keys, connection logs, billing data, internal documents, and 413 private source code repositories. PingCAP did not confirm all of these figures, and InfoQ notes that FulcrumSec's claims have not been independently verified.

What PingCAP officially confirmed

In the incident report cited by InfoQ, the company says an external incident response firm reviewed production systems and found no evidence that the attacker ran commands or maintained persistent access in the systems analyzed.

An external incident response firm reviewed PingCAP's production systems and found no evidence that the attacker ran commands or maintained persistent access in the systems reviewed. That finding does not change the data exposure described below. With support from outside counsel and third-party forensic specialists, there is no evidence that data stored in TiDB was impacted.

PingCAP, incident report

The company confirmed that the exported records include usernames and emails, organization and project associations, and text and errors from the console's SQL editor. Some records also contained organization, project, and cluster identifiers.

What FulcrumSec claims to have taken

The group says it obtained a complete copy of PingCAP's metadb database, with roughly 180,000 customer organizations and nearly 300,000 user records, of which 166,000 include real names and more than 400,000 unique emails. Among the allegedly stolen data:

• 115,000 console API key pairs, of which more than 40,000 are claimed to be active (the most recent reportedly created hours before the end of the attacker's alleged access);
• about 1,800 external database endpoints used in customer migration jobs, including root and admin accounts for third-party MySQL and Aurora hosts;
• four years of connection logs for every customer's use of the product, according to the group.

FulcrumSec describes the scope of what it claims to possess in blunt terms:

We possess the complete TiDB Cloud control plane, its billing and finance estate, its GCP storage estate and its AWS cost and billing estate, its Jira, its CRM, its analytics, its source code, and a four-year log of every connection every customer ever made to its product, from the IP addresses of their application servers.

FulcrumSec, cyber extortion group

The first batch released publicly consists of five tar.gz files, totaling 128.3 GB compressed (just over 200 GB uncompressed) out of an alleged total of 10.6 TB.

The root cause: credentials pasted into Jira tickets

According to FulcrumSec, PingCAP engineers pasted customers' production credentials directly into Jira tickets. The group reproduced three full logs and the corresponding tickets in the first batch of data released. For security experts, it's this detail that makes the case more serious than a typical database incident.

Kim Barthel, director and founder of security consultancy 42Sec, sums up the problem:

The PingCAP breach isn't really a database story. It's a story about one service-account key (...) PingCAP says it has no evidence that customer data stored in TiDB itself was touched. Good. But look at what did leak. Whoever has it knows who your engineers are, what you pay, when your contract renews, and how your schema looks like. That's everything needed for a phishing email you'd actually believe.

Kim Barthel, director and founder of 42Sec

In other words: even if no data stored in TiDB itself was accessed, what did leak (query history, support tickets, diagnostic logs) is already enough for targeted social engineering attacks against specific engineering teams.

Community reaction and unanswered questions

In a popular Hacker News discussion cited by InfoQ, developers questioned PingCAP's response to the incident. FulcrumSec's claim that it maintained a continuous export of the control-plane database for more than a month without being detected drew criticism. User dherls wrote:

If true, this is next level incompetence from PingCap. Apparently the attackers set up a replication pipeline for a month?!

dherls, Hacker News user

The timing of the attack also drew attention because PingCAP had just announced an independent security audit of TiDB's source code, conducted by NCC Group. User xKingfisher commented:

Coming this close on the heels of the security audit by NCC is pretty embarrassing for all parties.

xKingfisher, Hacker News user

Who was named, and who has already denied involvement

The allegedly exposed records include data associated with companies such as Booking.com, Shopee, Airbnb, Pinterest, Databricks, Atlassian, Fujitsu, SoftBank, and Baidu. InfoQ stresses that a company's name appearing in the leak does not confirm it was compromised. Cryptocurrency exchange Bitget, one of the companies named in the report, said its own investigation found no evidence of user data exposure.

What to do if you run TiDB in production

For those using TiDB Cloud (or considering migrating to it) in Brazil, this episode calls for concrete action, not just following the news. PingCAP publicly recommends rotating any active TiDB Cloud management API keys and paying extra attention to targeted phishing attempts.

Beyond the official recommendation, it's worth considering:

1. Rotating every TiDB Cloud console API key that is active today, even without confirmation that your organization is among those affected;
2. Auditing migration endpoints configured in the past: if you ever ran a migration job to TiDB Cloud, the credentials used at that time (including MySQL or Aurora root/admin) should be treated as potentially exposed;
3. Reviewing what goes into support tickets: the leak shows that connection strings and credentials pasted into third-party systems (Jira, CRM, analytics tools) are as real a vector as a flaw in the database itself;
4. Strengthening monitoring against targeted phishing: with engineers' names, contract values, and renewal dates potentially exposed, fraudulent emails are likely to become more convincing in the coming weeks.

What remains unresolved

Neither the real extent of the alleged 10.6 TB nor the full list of affected organizations had been independently confirmed by the time InfoQ's report was published. PingCAP maintains that there is no evidence that data stored within TiDB itself was accessed, but that does not cover what leaked from the control plane, Jira, and billing systems. Until an independent forensic investigation confirms or refutes FulcrumSec's numbers, TiDB Cloud customers would do well to treat every credential issued before October 2026 as potentially compromised.