Stolen Credentials Copied TiDB Cloud Account and Billing Records

On October 19, 2026, PingCAP published a security incident report. Between September 9 and October 7, 2026, an unauthorized party used stolen service-account credentials to reach certain internal systems, copy data, and obtain source code. PingCAP learned of it on October 7 and started disabling those credentials the same day. By October 14, every identified compromised credential was invalidated and the identified unauthorized access paths were blocked.

An external incident-response firm found no evidence the attacker ran commands or kept persistent access in the production systems it reviewed. PingCAP says that finding does not change the data exposure below, and that there is no evidence data stored in TiDB was impacted. Customer-specific impact is still open. PingCAP will notify affected customers directly and asks questions to go to security@pingcap.com.

Snapshot

What the English report says was in the exported records — and what it does not say was true of every customer:

The credential row is still open on purpose. PingCAP says it has not verified attacker claims about credentials inside support materials, and it has not finished checking whether other usable credentials were exposed.

PingCAP Japan describes the same window and adds a Japan figure: up to about 50,000 personal-information records in Japan. An October 21, 13:05 addendum adds support-ticket information to the account data. That notice says the public-key portion of TiDB Cloud API keys was in the export and is encrypted, and that the private-key portion was not, so the public key alone cannot operate TiDB Cloud. It also says the investigation has not confirmed unauthorized access into TiDB Cloud or a credit-card leak. Billing configuration in the English report is a different fact from a card number.

We are not smoothing those two notices into one sentence. The English report still treats “other usable credentials” and “credentials in support materials” as unverified. The Japan notice is more specific about key halves and about support tickets as a data category.

Larger figures circulating with this incident — multi-terabyte totals, torrent sizes, plaintext API-key counts, and named-customer secret lists — are a claimant’s account. PingCAP has not confirmed them. This post does not repeat those totals or those names.

What customers are asked to do

On October 20, PingCAP published customer actions and said not to wait for a per-customer notice. The API-key values in the copied data were encrypted, and PingCAP says it has not found evidence they were decrypted or used. The precaution it asks for anyway: organization owners replace active TiDB Cloud management API keys (create a replacement, move apps, then revoke the old key). If a key looks misused, revoke it first and write security@pingcap.com. Do not put passwords, tokens, or private keys in that mail.

The Japan notice adds three checks: review access logs for unfamiliar addresses, review organization members and roles, and treat mail that asks for a password or an access key as fake. PingCAP says it does not ask for those by email.

The external firm reported four vulnerabilities on October 12–13. PingCAP fixed all four by October 14, and the firm retested each fix. PingCAP is still checking logs for exploitation before those fixes. On October 10 it turned on extra cloud-storage access logging in an affected project. This post does not name those four bugs.

SQL-editor text was in the export. Queries and errors typed in that console editor are part of the confirmed copy, including anything a person pasted there. That is separate from “data stored in TiDB,” which PingCAP says it has no evidence was impacted.

MFA on the accounts around this incident

TiDB Cloud password authentication applies only to email-and-password signups. MFA there is optional. It is an authenticator-app QR. Google Authenticator and Authy are named. A one-time recovery code is the backup. That section has no SMS path and no YubiKey, so the console row is Pass — and it stays off until someone turns it on.

Google, GitHub, or Microsoft SSO does not use that console MFA. The second factor is the identity provider’s. The same page says anyone who turned on TiDB Cloud MFA for an SSO login was supposed to move that MFA to the IdP before September 30, 2025. GitHub, Google, and Microsoft already grade Strong (security key plus authenticator). None of those factors unsays SQL-editor text or billing records that were already copied, and none of them rotates a management API key.

Directory: MFA support directory · Business Apps, Developer Tools, and Email & Identity.

Recommended MFA tools

We may earn a commission if you buy a YubiKey or sign up for Proton Pass through the links above.

Independent cybersecurity audits

We audited PingCAP, the TiDB project site, the TiDB Cloud host, and the three SSO providers on October 21, 2026. 100% is the ideal — none reach it. These scores are public email / transport / website posture. They do not measure whether a cluster key was in the export.

Audit links: microsoft.com · github.com · pingcap.com · google.com · tidbcloud.com · tidb.io

tidb.io is Identity 0%. tidbcloud.com is 43% overall and Identity 25%. pingcap.com, tidbcloud.com, and github.com sit at 15% transport. Type pingcap.com yourself if a mail offers a “rotate your key here” link.

Website stack

Passive homepage + Certificate Transparency probes (October 21, 2026). Versions only — not a claim these homepages were the systems the stolen credentials reached.

Blacklist and lookalikes

Email blacklist checks (public DoH, October 21, 2026): pingcap.com, tidb.io, github.com, google.com, and microsoft.com were clear on mail/domain lists we can query. github.com showed SPFBL on a web IP — shared-edge noise, not led.

tidbcloud.com showed SPFBL on a Mailgun MX (mxa.mailgun.org). That is a shared sending-service listing, not a finding we are leading with, and it is not a reason to skip the key rotation on the real console.

Registered lookalikes that matter if a “security update” or “rotate your API key” mail turns into a fake portal:

tidb.com, tidb.cloud, and tidb.ai resolve but did not show mail in this pass. tidbcloud.net has nameservers only. github.io redirects to GitHub Pages — that one points at the brand. google.com and microsoft.com had no BEC-staging row in this pass; typos such as geoogle.com and imicrosoft.com still have mail. tidb is a short label, so a tidb.* registration is not by itself a PingCAP property. Type the real hosts. Continuous monitoring: Cybersquat Domain Monitoring.

CourtListener searches on October 21, 2026 for PingCAP and TiDB Cloud returned no dockets.

Related coverage

• PHP2Shell critical RCE
• eMudhra intermediate CA keys
• MFA support directory

Sources: PingCAP incident report, Oct 19, 2026 · Customer actions, Oct 20, 2026 · PingCAP Japan notice · TiDB Cloud password authentication · Runtime Wire, Oct 21, 2026. Independent EmailMeNow audits, website-tech, blacklist, cybersquat, and CourtListener searches October 21, 2026. Domain scores: audit.emailmenow.com only.