On 19 October 2026, PingCAP, the company behind the TiDB database and the TiDB Cloud service, disclosed that an unauthorised party had used stolen service account credentials to access some of its internal systems between 9 September and 7 October 2026. PingCAP says the intruder copied data and obtained source code. Exported records included TiDB Cloud user names, email addresses, organisation and project details, SQL editor text, billing and contract information, and a table of encrypted TiDB Cloud API-key values. PingCAP says "there is no evidence that data stored in TiDB was impacted", and that an external firm found no sign the attacker ran commands or kept access in the production systems it reviewed. A group calling itself FulcrumSec claims to have taken far more, including 10.6 TB of data and live customer credentials; PingCAP has not verified those claims. PingCAP had invalidated all identified compromised credentials by 14 October and its investigation continues.
Key takeaways
- PingCAP confirmed on 19 October 2026 that stolen service account credentials gave an attacker access to internal systems for about four weeks, from 9 September to 7 October 2026.
- Confirmed exports include TiDB Cloud account and SQL editor records, customer business and billing data, source code and a table of encrypted API-key values, according to PingCAP's report.
- FulcrumSec claims 10.6 TB, 413 repositories and about 115,000 console API keypairs, according to InfoQ. These claims are unverified, and PingCAP says it has no evidence that data stored in TiDB was impacted.
- TechInformed reports that some support tickets held AWS access keys customers had shared, which the attacker used; chief executive Max Liu told customers "We did not protect that information as we should have".
- The identity lesson: one service account with reach across internal systems was enough for weeks of quiet data export, and credentials pasted into support tickets turned a vendor breach into a customer credential problem.
At a glance
| Organisation | PingCAP, provider of the TiDB database and TiDB Cloud, and its TiDB Cloud customers (customer-specific impact still being determined) |
|---|---|
| When | Unauthorised access 9 September to 7 October 2026; discovered 7 October 2026; disclosed 19 October 2026 |
| Attacker | Not named by PingCAP. A group calling itself FulcrumSec has claimed the attack and published samples, according to InfoQ |
| Entry point | Stolen service account credentials; PingCAP has not said how they were stolen |
| Identities abused | A PingCAP service account; exported encrypted TiDB Cloud API-key values; customer AWS access keys shared in support tickets, according to TechInformed |
| Impact | Customer account, SQL editor, business and billing records and source code copied; no evidence that data stored in TiDB was impacted; larger attacker claims unverified |
| Category | NHI. Incident class: confirmed NHI breach (stolen service account credentials used for data and source code theft) |
What happened
TiDB is an open source distributed SQL database, and TiDB Cloud is PingCAP's managed service for it. In a security incident report published on 19 October 2026, PingCAP said "an unauthorized party used stolen service account credentials to access certain PingCAP internal systems", copied data and obtained source code. The activity ran from 9 September to 7 October 2026, the day PingCAP learned of it and began disabling affected credentials. PingCAP has not said how the service account credentials were stolen.
The report lists what was exported. For TiDB Cloud accounts and product use, records included user names, email addresses, organisation and project associations, and SQL editor text and errors, some with cluster identifiers. Business and billing records included customer contacts, contract terms, orders, pricing, payment terms and billing configuration. On credentials, the report states: "An exported table contained encrypted TiDB Cloud API-key values." PingCAP says one investigator-owned value from that table could not be used directly as an API key, but whether other usable credentials were exposed is still undetermined. It adds that the attacker's claims about credentials in support materials have not been verified.
The attacker's account is much larger. InfoQ reports that FulcrumSec claims to have stolen 10.6 TB, including control-plane records, customer SQL statements, 413 private repositories, about 115,000 console API keypairs with more than 40,000 active, and about 1,800 external database endpoints. It also claims PingCAP engineers pasted customers' production credentials into Jira tickets. RuntimeWire noted on 21 October that "a separate attacker claim of 10.6 TB stolen and plaintext API keys remains unverified". TechInformed later reported that some support tickets did contain AWS access keys customers had shared while asking for help, and that the attacker used those keys to reach cloud storage holding TiDB diagnostic files. It quotes chief executive Max Liu, in a message to customers on 23 October: "We did not protect that information as we should have".
On containment, PingCAP says it disabled or revoked most affected accounts from 7 October, deleted more compromised credentials and removed excessive permissions between cloud projects by 10 October, and turned on extra storage access logging. An external firm reported four vulnerabilities on 12 and 13 October, which PingCAP fixed by 14 October; TechInformed says NebuSec found no evidence they were exploited. By 14 October all identified compromised credentials were invalidated and all identified unauthorised access paths blocked. PingCAP says it will notify affected customers directly, and InfoQ reports it recommends replacing active TiDB Cloud management API keys and watching for targeted phishing.
Timeline
| Date | Event |
|---|---|
| 9 September 2026 | Unauthorised access using stolen service account credentials begins, according to PingCAP. |
| 7 October 2026 | PingCAP learns of the incident and starts disabling affected credentials. |
| 10 October 2026 | More compromised credentials deleted, excessive cross-project permissions removed and extra storage access logging enabled. |
| 14 October 2026 | All identified compromised credentials invalidated and access paths blocked; four reported vulnerabilities fixed. |
| 19 October 2026 | PingCAP publishes its security incident report. |
| 23 October 2026 | Chief executive Max Liu writes to customers, according to TechInformed. |
How it happened: the identity attack path
- Service account credentials stolen. The attacker obtained credentials for a PingCAP service account. PingCAP has not disclosed where or how they were stolen.
- Internal systems accessed. Using that machine identity, the attacker reached internal systems over about four weeks without being detected, a sign of broad reach and limited monitoring of the account.
- Data, code and key tables exported. Customer account, SQL editor and billing records were copied, along with source code and a table of encrypted TiDB Cloud API-key values.
- Customer credentials found in support data. According to TechInformed, some support tickets held AWS access keys shared by customers, and the attacker used them to reach storage with TiDB diagnostic files.
- Containment by revocation. PingCAP disabled and deleted compromised credentials, removed excessive permissions between cloud projects and blocked identified access paths by 14 October.
Impact
- Confirmed by PingCAP: export of TiDB Cloud user, organisation, project and SQL editor records; business and billing records; source code; and a table of encrypted API-key values.
- Not found so far: PingCAP says there is no evidence that data stored in TiDB was impacted, and no evidence the attacker ran commands or kept persistent access in the production systems reviewed.
- Reported by TechInformed: customer AWS access keys from support tickets were used by the attacker; PingCAP's Japanese subsidiary reported up to about 50,000 personal information records in Japan.
- Claimed, unverified: FulcrumSec's claims of 10.6 TB, 413 repositories, about 115,000 console API keypairs and about 1,800 database endpoints.
- Wider: exported contacts, pricing and contract details could support targeted phishing of customers, a risk PingCAP itself flags, according to InfoQ.
What this means for NHI governance
This breach began with a non-human identity. A single service account, with stolen credentials, gave an attacker about four weeks inside PingCAP's internal systems, enough to export customer records, billing data, source code and a table of API keys. PingCAP's own remediation, removing excessive permissions between cloud projects, suggests the account could reach more than its job needed. That is the core service account problem covered in our Service Account Security Guide: broad, long-lived access that nobody watches until it is misused.
The second lesson is about secrets that end up where they should not. PingCAP encrypted stored TiDB Cloud API-key values, but TechInformed reports that credentials customers shared in support tickets were not protected the same way, and that the attacker used them. Support systems, chat logs and ticket attachments are secret stores in practice, whether or not anyone designed them to be. Customers should treat any credential ever shared with a vendor as exposed when that vendor is breached, and vendors should block or scrub secrets at the point of submission.
For customers, this is a third-party NHI risk. Questions about how a provider protects its own service accounts and support data belong in due diligence, as set out in our guide to Third-party NHI due diligence questions drawn from real breaches. It also fits a busy month for platform breaches, including Railway and Northflank, although nothing published links them to this incident.
Recommendations
- Replace TiDB Cloud management API keys. Rotate active TiDB Cloud API keys, as PingCAP recommends according to InfoQ, and remove any that are no longer used. See our Secrets Rotation Runbook Template.
- Rotate anything you ever shared with support. Revoke and reissue any AWS keys, database passwords or other secrets that were pasted into support tickets or diagnostic bundles, then check cloud logs for their use from September 2026. See our Leaked Credential Response Playbook.
- Scope and monitor every service account. Limit each service account to the systems it needs, remove cross-project permissions it does not use and alert on large exports or unusual access. See our Service Account Security Guide.
- Keep secrets out of support channels. Give customers a secure way to share temporary credentials, scan tickets and attachments for secrets and purge them automatically.
- Review database credentials exposed to the vendor. Rotate database users and connection strings that the provider could see, and prefer short-lived credentials. See our Database Credential and Access Security Guide.
- Prepare staff for targeted phishing. Exported contacts, contract terms and pricing make convincing lures, so warn finance and engineering teams to verify any unexpected request that appears to come from PingCAP.
Frequently asked questions
What happened in the TiDB Cloud breach?
Between 9 September and 7 October 2026, an unauthorised party used stolen service account credentials to access PingCAP internal systems, copy TiDB Cloud customer and billing records, obtain source code and export a table of encrypted API-key values. PingCAP disclosed the incident on 19 October 2026 and says there is no evidence that data stored in TiDB was impacted.
Did FulcrumSec really steal 10.6 TB from PingCAP?
That is FulcrumSec's claim, and it has not been verified. PingCAP has confirmed the categories of data listed in its report, but not the 10.6 TB figure, the count of API keypairs or the claim of plaintext credentials. RuntimeWire and InfoQ both describe the larger claims as unverified.
What should TiDB Cloud customers do now?
Replace active TiDB Cloud management API keys, rotate any credentials ever shared with PingCAP support, review cloud and database logs for unexpected use since September 2026 and be alert to targeted phishing. PingCAP says it will contact affected customers directly once customer-specific impact is established.
Related NHI Mgmt Group resources
Railway breach 2026 · Northflank breach 2026 · Zeabur second breach 2026 · Service Account Security Guide · Third-party NHI due diligence questions drawn from real breaches
How NHI Mgmt Group can help
A breach at a database provider leaves customers asking which of their credentials the vendor ever held. We help organisations map secrets shared with third parties, govern their own service accounts so one stolen credential cannot reach everything, and build rotation playbooks that work under pressure. See our NHI and AI agent security training.
References
- PingCAP: Security Incident Report: Unauthorized Access to PingCAP Cloud Resources (19 October 2026)
- RuntimeWire: PingCAP confirms TiDB Cloud data exposure after stolen credentials accessed internal systems (21 October 2026)
- InfoQ: PingCAP Breach Exposes Customer Records and Source Code (25 October 2026)
- TechInformed: PingCAP breach exposes data and keys shared with support (26 October 2026)