VULNpocalypse
HighBreach / campaignMonitoring

PingCAP breach: TiDB Cloud customer records, support tickets and source code copied using stolen credentials

PingCAP confirms an intruder copied TiDB Cloud account, billing and support data plus source code in Sep-Oct 2026. Rotate API keys and support-shared secrets.

Published
Updated
Exploitation
Yes. PingCAP confirms data was copied between 9 September and 7 October 2026; FulcrumSec claims the theft

What happened

PingCAP makes the open-source TiDB database and runs the TiDB Cloud service. All dates are from PingCAP’s incident report unless stated.

  • 9 September to 7 October 2026: an unauthorized party used stolen service-account credentials to reach internal PingCAP systems, copy data and obtain source code.
  • 7 October: PingCAP became aware and began disabling credentials.
  • 10 October: deleted more compromised credentials, removed excessive cross-project permissions, and turned on more storage access logging.
  • 12 to 13 October: its outside firm reported four vulnerabilities in the stolen source code that could affect production data. All four were fixed and retested by 14 October, when every identified compromised credential had been invalidated.
  • 19 October: PingCAP published the incident report. 20 October: it published customer actions. PingCAP’s Japanese subsidiary says up to about 50,000 personal records in Japan leaked; a 21 October addendum added support-ticket information to the affected data (PingCAP Japan). 23 October: CEO Max Liu wrote to customers: “We did not protect that information as we should have” (PingCAP CEO note).

How the attacker got in. NebuSec, the incident response firm PingCAP engaged, traced it to a compromised GitHub account with access to private repositories. From there the attacker harvested service-account private keys in Git history and plaintext Terraform state, a Jira API token and an alerting bot key, and used eight compromised Google Cloud service accounts. Support tickets held customer-shared credentials, including AWS keys, which reached S3 buckets holding a customer’s TiDB diagnostic data. On 23 and 24 September the attacker ran BigQuery exports of 6,458 tables to Cloud Storage, and downloaded them with rclone between 2 and 5 October (NebuSec). NebuSec does not say whose GitHub account it was or how it was compromised.

What was taken, per PingCAP and NebuSec:

  • TiDB Cloud account data: user names, emails, organization and project membership, SQL editor text and errors, and organization, project and cluster IDs (PingCAP).
  • Business records: customer contacts (name, email, company, phone), contracts, orders, pricing, payment terms and billing configuration (PingCAP Japan).
  • Support tickets and Jira issues, internal chat history, CRM records and source code (NebuSec).
  • Encrypted TiDB Cloud API-key values. The encryption key was not exposed (NebuSec). The Japanese notice says only the public-key part leaked and cannot operate TiDB Cloud on its own (PingCAP Japan). That protection does not cover credentials pasted into support material (PingCAP CEO note).

What was not seen: no attacker commands or persistence in production, no access to live customer clusters, and no evidence that data stored in customers’ TiDB databases was touched (NebuSec). No credit card data leak was confirmed (PingCAP Japan).

Attacker claims, not confirmed by PingCAP. The group FulcrumSec claims 10.6 TB, 413 private repositories, about 180,000 tenant organizations, 115,000 console API keypairs, and about 1,800 external database endpoints from migration jobs, including root and admin accounts for customer MySQL and Aurora hosts. It also alleges PingCAP engineers pasted customers’ production credentials into Jira tickets (InfoQ). PingCAP and NebuSec do not name an attacker.

Am I affected?

PingCAP says exposure varies by customer and it will contact affected customers directly, but asks everyone to act now (PingCAP CEO note). Check these:

  1. TiDB Cloud management API keys. In each organization you own, open Organization Settings > API Keys and list every key (PingCAP customer actions). PingCAP asks owners to replace every active key as a precaution, even though it has seen no decryption or use of the stolen values.
  2. Support tickets. Search your PingCAP support history and your own email for anything you sent: AWS access keys, database users and passwords, connection strings, diagnostic bundles or logs with secrets. The encryption that protected API-key values did not cover these.
  3. AWS keys you shared. The attacker used support-shared AWS keys to reach S3 (NebuSec). For each key, check when it was last used and from where. CloudTrail event history only holds management events, such as ListBuckets; S3 object reads show up only if you had S3 data events or server access logging turned on.
bash
aws iam get-access-key-last-used --access-key-id AKIA...
aws cloudtrail lookup-events --region us-east-1 \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA... \
  --start-time 2026-09-01T00:00:00Z
  1. SQL editor history. Anything you typed in the TiDB Cloud SQL editor, including literals such as CREATE USER ... IDENTIFIED BY '...', may be in the exported data (PingCAP).
  2. Migration sources. If you configured a migration from an external MySQL or Aurora database, FulcrumSec claims those endpoints and admin accounts were taken. PingCAP has not confirmed this.

What to do now

  1. Replace management API keys, in order: create a new key, move every app and script to it, confirm it works, then delete the old key. Repeat in every organization you own. If you suspect misuse, delete the key first, before you have a replacement, then email security@pingcap.com (PingCAP customer actions).
  2. Rotate everything shared with support, including credentials, keys, connection strings and logs that contained secrets (PingCAP CEO note). For AWS keys, deactivate the old key in IAM; do not just stop using it.
  3. Change any database password that appears in SQL editor history, and the credentials of external migration sources (a cheap precaution while FulcrumSec’s claim is unconfirmed).
  4. Review organization members and roles, remove accounts you do not need, and check TiDB Cloud and related cloud access logs for unfamiliar IPs (PingCAP Japan).
  5. Treat billing and payment-change requests as suspect. The attacker holds real contract, pricing and contact data, so a fake invoice or “update your bank details” message can look genuine. PingCAP says it will never ask for passwords or access keys by email (PingCAP Japan); verify anything else through a channel you already use (PingCAP customer actions). Do not put secrets in messages to PingCAP’s security team.

Sources