PingCAP says an attacker copied customer-related information from its internal systems between September 9 and October 7. Its October 23 CEO statement directs customers to replace TiDB Cloud management API keys and rotate credentials shared with support.

The company’s retained investigator, NebuSec, traces the intrusion from a compromised GitHub account into private repositories. Credentials in those repositories and Terraform state, files describing deployed infrastructure, opened access to cloud and support systems.

Support material became another credential source

NebuSec says the attacker collected additional customer credentials from Jira support tickets. Those included AWS keys used to reach S3 buckets containing customer TiDB diagnostic data.

The copied information extended beyond support tickets. Investigators describe source code, SQL editor history, AI interactions, customer contacts, billing records, internal chat history and infrastructure backups. Not every customer necessarily had every category exposed.

This is why the production-database boundary matters without settling the customer’s risk. SQL text, diagnostic files and credentials can be sensitive even when copied from a support system rather than a live database.

Evidence status: company-confirmed data theft, with a technical investigation by PingCAP’s retained response firm. NebuSec says it correlated cloud logs, an incident file inventory and reviewed data samples. This is an account of an actual intrusion, not a controlled demonstration.

Encrypted management keys and support secrets are different

NebuSec found no evidence of access to data stored in customers’ live TiDB databases, or attacker command execution and persistence in production. That finding is limited to the evidence and environments reviewed.

The exported TiDB Cloud API-key values were encrypted, and investigators say the encryption key was not exposed. Those values could not directly supply usable API credentials. That protection does not extend to plaintext credentials recovered from support materials.

NebuSec also identified four vulnerabilities during its review of exposed source code. PingCAP patched them and NebuSec retested the fixes. A retrospective production-log review found no evidence of their exploitation before remediation. The sources supply no customer-installable fixed version for this credential-based incident.

PingCAP’s October 19 report left support-credential exposure unresolved. The newer investigation specifically describes AWS-key use from support tickets, making that category actionable rather than merely an attacker claim.

Rotate through the right path

Follow PingCAP’s customer-action guidance without waiting for individual impact notification:

  • Replace active TiDB Cloud management API keys as a precaution. With no suspected misuse, create replacements, update and verify dependent applications, then revoke the old keys.
  • If misuse is suspected, revoke the affected key immediately. PingCAP says to do this even if an integration is temporarily interrupted.
  • Rotate secrets shared with PingCAP support. Include credentials in connection strings, logs and attachments, not just dedicated API-key fields.
  • Review unfamiliar activity and verify unusual requests through known contacts. Exposed customer and billing details can make impersonation convincing; this is a precaution, not evidence of a confirmed phishing campaign.

PingCAP began disabling credentials on October 7. NebuSec says all identified compromised credentials were invalidated by October 14. Customer-specific impact assessment and broader hardening remain ongoing.

Caveat: NebuSec was engaged by PingCAP, and customer-level exposure is still being determined; no-evidence findings do not erase the confirmed internal-system data theft.