PingCAP confirms unauthorized access

PingCAP builds TiDB, the open-source distributed database, and runs TiDB Cloud for customers who would rather not operate clusters themselves; that service keeps their accounts, billing records and support tickets on PingCAP’s side. On October 19, 2026, the company published an incident report on its Trust Hub confirming that between September 9 and October 7 someone used stolen service-account credentials to reach internal systems, copy data and take source code. PingCAP says it learned of the intrusion on October 7 and began disabling the affected credentials that day.

Key points

PingCAP’s own timeline runs from discovery to containment in a week: credentials disabled from October 7, extra compromised credentials deleted and excess cross-project permissions removed by October 10, plus cloud storage access logging switched on in an affected project the same day. An outside firm reported four vulnerabilities on October 12–13; all four were fixed and retested by October 14, when PingCAP says the identified access paths were blocked.
Three categories of exported records are confirmed: TiDB Cloud account and product-use data (usernames, email addresses, organization and project associations, SQL editor text and errors, some organization, project and cluster identifiers), business and billing data (customer contacts, contract terms, orders, pricing, payment terms, billing configuration), and one table holding encrypted TiDB Cloud API key values.
The attacker’s scale figures remain one-sided. FulcrumSec claims 10.6TB across 4,901,203 files, 180,046 tenant organizations and 115,308 “plaintext” API keys, 42,612 of them allegedly still active. PingCAP has not confirmed any of those numbers; it says only that one investigator-owned key tested by its outside firm could not be used directly as an API key.

Background

TiDB Cloud concentrates a lot of other people’s operational detail in one place. To run it, PingCAP holds account and organization-project associations, query history, ticket content, contracts and invoices, and the API keys customers mint to automate their clusters. Separately, none of that is a database dump. Together, it is a map that points back to specific customers.

The disclosure arrived in waves. The English Trust Hub report went up on October 19. Bitget responded on October 20. On October 21, PingCAP’s Japanese subsidiary published a notice aimed at customers in Japan, and Dark Reading ran the first independent analysis. That Japanese notice carries a 13:05 addendum adding support-ticket information to the affected categories. The English report we read on October 22 does not list that category, and the word “ticket” does not appear in it.

The facts

What PingCAP confirms and what FulcrumSec claims are different orders of magnitude, and mixing them misstates the story.

Item	PingCAP’s account	FulcrumSec’s claim (not independently verified)
Window	September 9 to October 7, 2026 (US time); discovered October 7	Exports every six hours from September 8 to September 30, 88 in total, the last at 06:02 UTC on September 30
Volume	Not disclosed	10.6TB, 4,901,203 files; first release is five archives, 128.3GB compressed and just over 200GB unpacked
API keys	Exported table held encrypted values; one investigator-owned sample could not be used directly; whether other usable keys leaked is open	115,308 plaintext keys, 42,612 still active
Customer data	Joint review with outside counsel and a forensic firm found no evidence that data stored in TiDB was impacted	About 20.6 million SQL statements, 102,003,766 gateway connections, 5,036,738 customer server IPs, 413 private repos

The two windows are worth reading side by side. FulcrumSec says its export pipeline stopped on September 30; PingCAP says unauthorized access ran to October 7. Both can be true — the stolen credentials may have opened more than one door — but neither party has published anything that reconciles the dates.

PingCAP also states that the outside incident-response firm found no evidence the attacker ran commands or kept persistent access in the production systems it reviewed, and adds the caveat that this finding does not change the data exposure. The two sentences do different jobs: one covers what the attacker left running inside the systems, the other covers what had already been exported. Reading the first as a denial of the second would misstate both.

The keys are contested too. The attacker calls them plaintext. PingCAP says the exported table held encrypted values and backs that with a test: its outside firm took a key the investigators owned and could not use it as an API key. That covers one sample, and PingCAP concedes it is still investigating whether other usable credentials were exposed. The Japanese notice draws the line more precisely: only the public-key portion of TiDB Cloud API keys was in scope, the private keys were not, the public part is itself encrypted, and the public half alone cannot operate TiDB Cloud.

Japan is also where a number finally appears. The subsidiary says up to about 50,000 pieces of personal information relating to people in Japan leaked — the Japanese notice counts records, not people, and does not say how many individuals that maps to — across account data, transaction data (name, email, company, phone number, order details, payment terms, billing settings) and the credential category above. It says no unauthorized access to TiDB Cloud itself and no credit card exposure have been confirmed, and that it has filed with law enforcement and reported to supervisory authorities in the relevant countries. The English report says PingCAP will notify affected customers directly once it has established customer-specific impact, without saying how many customers that is or naming any.

What others say

Dark Reading’s October 21 analysis, by Nate Nelson, states plainly that the outlet did not independently confirm FulcrumSec’s figures and that PingCAP did not respond to its request for comment before publication. The two practitioners it quotes put the risk in the same place: metadata sitting in a vendor’s environment.

Crystal Morin of Sysdig said vendors rarely set out to store secrets; convenience features push sensitive data into unexpected places. The SQL editor is the example she gives — query history and error output are where secrets accumulate when people paste connection strings while debugging. Her questions for anyone vetting a provider are concrete: what customer-supplied data does the vendor retain, for how long, does it scan for secrets at ingest and redact them, how are service-account credentials scoped and rotated, and what triggers a breach notification.

Shane Barney of Keeper Security frames it as a path rather than a single failure: attackers do not need to compromise a customer’s primary database directly if they can systematically harvest upstream credentials. Customer metadata, API keys and diagnostic query logs seep into vendor environments through ordinary operations, and once stolen, provider credentials become a road map for exploitation. He recommends rotating vendor-facing API keys, removing hardcoded and long-lived secrets, and making third-party risk assessments such as SOC 2 Type II and ISO 27001 part of procurement.

On the customer side, exactly one company has spoken publicly. Crypto Briefing reported on October 20 that Bitget’s head of Greater China operations, Xie Jiayin, confirmed the exchange had used TiDB Cloud but stored only public trade logs, which are already visible on its order book, and had stopped using the service more than two months earlier. Bitget says an internal review found no exposure of user data or passwords and no confirmed exfiltration involving customer assets. It frames the episode as a supplier-side problem and told users to watch for phishing. That is the named party’s own account, with no independent verification.

In Chinese, InfoQ’s October 21 report lists the attacker’s numbers in full and labels them as not independently verified. When it turns to Pingkai Xingchen’s October 20 statement, it links the words “China-region status note” to a pingkai.cn page and then continues with a colon: “so far we have found no impact on China-region customers’ production databases or business data, and this incident was not caused by a TiDB kernel vulnerability.” We opened the page that link points to and could not find that sentence. It is titled “平凯星辰网络安全事件情况说明公告” and dated October 20, 2026; it contains no mention of a China region, a kernel vulnerability or production databases. What it says instead is that “some sales-lead and order records” and “some requirement-document information” were affected, and that “this incident does not involve security vulnerabilities or defects in products such as 平凯数据库企业版 and 平凯数据库云服务, and will not affect the security of customer database systems and business data.”

Those Chinese, Japanese and English accounts do not line up. The pingkai.cn notice limits the affected data to sales leads, order records and requirement documents — narrower than the Japanese notice’s list of account data, inquiry data, contacts, contract terms and the public half of API keys. Its product-level conclusion is also more absolute than the English report’s: “will not affect” versus “no evidence that data stored in TiDB was impacted.” One company, three versions over three days; a cross-border customer sees whichever entity’s notice reaches them.

Japanese business IT outlet Business+IT ran a story on the notice the same evening, distributed through Yahoo News at 20:55 on October 21. It repeats the 50,000-record figure and the three data categories, and repeats the notice’s line that the company had filed with law enforcement and reported to supervisory authorities in the relevant countries. The story adds no numbers of its own, but it does show the Japanese notice reached a general business readership, not just customers who went looking for it.

Our take

If you run TiDB Cloud, treat this as a credential incident rather than a database breach. There is no evidence so far that business data inside customer clusters was taken. What PingCAP confirms was exported is organization and project associations, SQL editor text and errors, customer contacts and contract and billing configuration, plus a table of encrypted API keys. Leaked business data and a hijacked account are two different risks with two different responses.

Why control-plane metadata matters is not mysterious, and Morin and Barney describe the mechanism well. A connection string pasted into a ticket with the password still in it, a backup config carrying a bucket key, a cloud access key nobody rotated — each is an ordinary operational trace until it lands in someone else’s hands, at which point it is an entry point. Those three are their general description of the risk, not an inventory of this breach. Mapping it onto what PingCAP actually confirmed: SQL editor text and errors match, which is the case Morin makes, and so does the “inquiry information (support-ticket information)” the Japanese notice added in its addendum — but that notice does not say what the tickets contain, or whether any of it includes attachments or credentials. The confirmed claim is that query history and ticket content were exported. It is not that every secret pasted into a ticket was taken. A team that has never pasted real credentials into a SQL editor or a support ticket carries much less direct risk, but proving that means reading the records, not trusting memory.

Two judgments seem safe. First, detection is the real failure here: the attacker claims 88 consecutive exports with no detection event, and PingCAP says it only added cloud storage access logging to an affected project on October 10. Second, the headline number should not be repeated as fact until independent forensics exist. 10.6TB has traveled widely, and it comes from the party asking for money.

Several questions remain open. There is no public forensic report, no count or list of affected customers, and PingCAP says it is still working through customer-specific impact before notifying. The Japanese notice and the English report cover different ground: one quantifies personal information in Japan, the other acknowledges exported usernames and email addresses without a number, and the two figures cannot stand in for each other. The tenant names the attacker published come from markers inside its sample; apart from Bitget, none has publicly confirmed, so they belong in a sentence qualified as alleged.

What to do now

The Japanese notice gives four instructions that apply regardless of where you are: check access logs for TiDB Cloud and related cloud accounts for unfamiliar IPs and operations you cannot account for; review organization members and roles, deleting unused accounts and tightening permissions; treat unexpected mail claiming to be from PingCAP with suspicion, since the company says it will not ask for passwords or access keys by email; and rotate API keys if you have issued any.

One more step follows from what actually leaked. Go through SQL editor history and the support tickets you have filed, and look for connection strings, database passwords or cloud keys pasted in. If you find any, assume they are compromised: change that password, rotate the key, and check that host’s login records — do not wait for a notification that may never name you. The pattern repeats across vendor-side credential theft; the LiteLLM 1.107.0 release-chain compromise runs on the same logic of credentials first, reach second. And the question of how much of your material a vendor keeps is the same one raised by this month’s agent overreach incidents, where permissions, logging and egress decide how large the loss gets.