PingCAP Security Incident: Stolen Service Account Credentials

PingCAP, the company behind TiDB and TiDB Cloud, reported that an unauthorized party used stolen service account credentials to access certain internal systems between September 9 and October 7, 2026. In its October 2026 security incident report, PingCAP says the attacker copied data and obtained source code. The copied data includes TiDB Cloud account and usage records, business and billing information, and a table of encrypted TiDB Cloud API-key values. PingCAP says there is "no evidence that data stored in TiDB was impacted."

For engineering and security teams, the takeaway is broader than one vendor: a service account credential can be used for weeks without anyone noticing, and its permissions set the blast radius. PingCAP's remediation steps include removing excessive permissions between cloud projects, adding storage access logging, and planning alerts for large data exports. Those steps line up with the controls that limit machine-identity risk.

Adaptive can help teams give workloads scoped identities, rotate and expire their secrets, find excessive access paths, and alert on large exports with query-level evidence. These controls apply to the paths Adaptive governs and complement cloud IAM and secret scanning.

Published November 1, 2026. Incident details are attributed to PingCAP's report. The access design and validation steps below are Adaptive's analysis.

What happened in the PingCAP security incident?

According to PingCAP, an unauthorized party used stolen service account credentials to access certain internal systems, copy data and obtain source code. The report does not say how the credentials were stolen. An external incident response firm "found no evidence that the attacker ran commands or maintained persistent access" in the production systems it reviewed. PingCAP adds: "This finding does not resolve the data exposure above."

PingCAP did not describe the type of the four vulnerabilities. It says it is checking production logs for any exploitation before they were fixed.

What data was exposed in the PingCAP breach?

PingCAP is still determining whether other usable credentials were exposed. It states that "The attacker's claims about credentials in support materials have not been verified." It also notes that "These findings do not mean that every customer had every category of information exposed." The company says it will notify affected customers directly once customer-specific impact is established.

Why are service account credentials such a common breach path?

Service accounts are built to run without a person present, and that makes them attractive to attackers. They usually authenticate without MFA, often use long-lived keys, and may be shared across jobs. Their permissions also tend to grow over time. Automated traffic can look routine, so a bulk export by a service account may not stand out the way an engineer downloading millions of rows would.

PingCAP's own planned improvements follow the same pattern: broader credential rotation, access controls, code and secret scanning, audit logging, and "alerts for unusual access and large data exports."

What should TiDB Cloud customers do now?

PingCAP has not asked customers to take specific actions and says it will contact affected customers directly. Questions go to security@pingcap.com.

The following precautions are Adaptive's suggestions, not PingCAP's instructions:

• Rotate TiDB Cloud API keys and review where each key is stored and which automation uses it. Rotation is low cost compared with waiting for a final determination.
• Review organization and project membership for unexpected users, and confirm that billing and technical contacts are current.
• Treat SQL editor content as potentially exposed. If anyone pasted secrets, tokens or sensitive values into SQL editor queries, rotate those secrets.
• Watch for invoice and contract fraud. Exposed contract terms, pricing and payment details can make fake invoices or payment-change requests look legitimate. Verify payment changes through a known contact.

What should engineering teams learn for their own service accounts?

Inventory every service account and key, with an owner, a purpose and a list of the systems it can reach. Remove permissions that cross project boundaries without a documented need. Enable access logging on storage buckets and data stores before an incident, not during one. PingCAP's October 10 change shows how important this visibility becomes during an investigation.

Then test detection. Run a large export with a test service account and measure how long it takes for someone to be alerted. A four-week access window is a detection problem as much as a credential problem.

How can Adaptive help limit service account and machine access risk?

Issue scoped machine identities

Adaptive's workload access issues scoped machine tokens to service accounts, pipelines, BI tools and AI agents, and registers trusted clusters. Each workload authenticates as itself instead of borrowing a shared credential, so one key does not quietly cover several systems.

Store, rotate and expire workload secrets

Adaptive stores workload credentials centrally and manages issuance, rotation, renewal and offboarding, so long-lived keys stop living in config files and CI variables. Adaptive's credential rotation can rotate supported database and server credentials on a schedule or on demand, with a history of each change.

Confirm coverage for each credential type. Cloud provider keys, third-party API tokens and application secrets may each need their own rotation process.

Find excessive and cross-project access

Adaptive's audit capabilities include an access matrix and access graph that show which identity can reach which resource, and by which path. Use them in access reviews to find service accounts whose reach has grown beyond their job.

Broker database access and alert on large exports

Adaptive's database activity monitoring records queries against the identity that issued them, including machine identities brokered through Adaptive. Detective policies raise alerts on unusual activity, and preventive policies can block or restrict statements in real time. Anomaly detection helps flag volume or access patterns that do not match an identity's baseline.

Integrations such as MySQL and Google Cloud provide authenticated, auditable access without sharing downstream credentials. Validate support for your specific engine, service and version before relying on it.

Keep query-level evidence for impact analysis

PingCAP is determining impact customer by customer. That work goes faster with records showing exactly which tables and rows each identity read. Adaptive keeps identity-linked query logs, and SIEM integration streams them to Splunk, Datadog, Coralogix or syslog for correlation with cloud audit logs.

Coverage matters. Access that bypasses the broker, such as a direct cloud storage read with a cloud key, needs its own logging.

How can teams validate these controls?

Use a non-production project and a test workload:

1. Inventory the workload's current credentials and every resource each one can reach. Compare the result with what the job actually needs.
2. Move the workload to a scoped machine identity and confirm that it still works while access outside its scope is denied.
3. Rotate the workload's credential and confirm that the old value fails and the job recovers.
4. Run an oversized export with the test identity. Confirm that an alert reaches the right team, or that a preventive policy blocks the export, within your target time.
5. Reconstruct the test from audit records, including which identity read which data and from where.

Frequently asked questions

Q: What happened in the PingCAP security incident?

PingCAP reported that between September 9 and October 7, 2026, an unauthorized party used stolen service account credentials to access certain internal systems, copy data and obtain source code. PingCAP found out on October 7. By October 14, it had invalidated all identified compromised credentials, blocked the identified access paths, and fixed four vulnerabilities reported by an external firm.

Q: Was customer data stored in TiDB affected?

PingCAP says there is no evidence that data stored in TiDB was impacted. Investigators found no evidence that the attacker ran commands or maintained persistent access in the production systems reviewed. However, account, usage, billing and contract records were exported.

Q: Were TiDB Cloud API keys exposed?

An exported table contained encrypted TiDB Cloud API-key values. One investigator-owned value could not be used directly as an API key. PingCAP is still determining whether other usable credentials were exposed.

Q: Should TiDB Cloud customers rotate their API keys?

PingCAP has not asked customers to take specific actions. Rotating TiDB Cloud API keys and reviewing account members is a low-cost precaution while the investigation continues.

Q: How can Adaptive help protect service account credentials?

Adaptive gives workloads scoped machine identities, stores and rotates their secrets centrally, shows excessive access paths, and records query-level activity with alerts for unusual exports. These controls apply to the access paths Adaptive governs.

Q: Does Adaptive replace cloud IAM or secret scanning?

No. Adaptive complements cloud IAM, secret scanning and code security. Cloud keys and storage access outside the broker still need least-privilege IAM policies and their own logging.

Review machine-identity access with Adaptive

Start with your most privileged service account. Map what it can reach, how long its credential lives, and how quickly a large export would be noticed. Request an Adaptive demo to see where scoped workload identities, managed rotation and data activity monitoring can shrink that blast radius.

Download this article as Markdown or plain text for LLMs. Both include publication metadata and source links.