TiDB Cloud Breach (October 2026): What Happened and What to Do

PingCAP says an unauthorized party used stolen service account credentials to reach internal systems behind TiDB Cloud between 9 September and 7 October 2026, copying account, billing and source code data. It found no evidence that data stored in TiDB was affected. If you use TiDB Cloud, replace your management API keys and review access now.

This post covers what PingCAP confirmed, what an extortion group claims, what to do this week, and the lessons for anyone running production data on a managed database. Facts come from PingCAP's notices; everything else is labelled as reported or claimed.

What happened

PingCAP published a security update on its Trust Hub on 19 October 2026 and a customer action page on 20 October. The table follows those notices, with outside reporting marked as such.

PingCAP has not named the firms helping it, does not mention law enforcement, and does not describe the four vulnerabilities. It says it is still checking whether any were exploited before the fix.

What PingCAP confirmed, and what it did not

PingCAP's update is unusually specific about data categories. According to the 19 October notice, the exposed material included:

On the other side of the ledger, PingCAP says there is no evidence that data stored in TiDB databases was impacted. Its incident response firm found no evidence that the attacker ran commands or kept persistent access in the production systems it reviewed. PingCAP adds that this finding does not undo the data exposure, and that not every customer had every category exposed. Individual impact is still being worked out, and PingCAP says it will contact affected customers directly.

The customer actions page adds one more detail: PingCAP has found no evidence so far that any encrypted API key was decrypted or used. LavX News, summarising the notice, reports that external testing found one investigator-owned encrypted value could not be used directly as an API key.

What the attacker claims

An extortion group calling itself FulcrumSec says it took far more. Crypto Briefing reports the group's claims as about 10.6 TB of data across roughly 4.9 million files, including customer records and API keys, a possible impact on more than 180,000 organizations, and a sample of about 200 GB already released. ChainCatcher repeats the 10.6 TB and 200 GB figures.

None of those numbers is confirmed by PingCAP. Two points of conflict stand out:

• API keys. Some reporting describes the attacker's claim as plaintext keys. PingCAP says the exported key values were encrypted and it has no evidence any were decrypted or used.
• Scope. The attacker frames this as a breach of customer data at scale. PingCAP says customer databases were not shown to be affected, and that what was accessed was account, business and billing data plus source code.

Treat the attacker's figures as unverified and plan from PingCAP's notices. If PingCAP revises its findings, plan again.

Who is affected

PingCAP has not published a list of affected customers. Until it does, its own advice is that every TiDB Cloud customer should take precautions.

That last row matters. This was not a flaw in the TiDB database engine. If you run open source TiDB yourself and never used TiDB Cloud, PingCAP's notices do not ask you to do anything.

How it works

PingCAP has not explained how the service account credentials were stolen, so this section stays with what the public record supports.

A managed database service has two halves. The data plane is the database itself: your tables, your rows, the SQL your application runs. The control plane is everything around it: the console, user accounts, organizations and projects, billing, the management API, and the provider's own internal tools. Your application talks to the data plane. Your engineers and your automation talk to the control plane.

PingCAP's account of this incident sits almost entirely in the control plane. A service account is a non-human identity the provider's own systems use to talk to each other. With working credentials for one, an intruder can read whatever that account was allowed to read. PingCAP's 10 October step, removing excessive permissions between cloud projects, suggests the reach of those accounts was part of what it tightened, though the notice does not spell out the path.

Why does control plane data matter if your tables were untouched?

• Contact and billing records give a phisher everything needed for a convincing message: your real contract terms, your billing contact's name, your project names. PingCAP's customer page warns about exactly this.
• SQL editor text and errors are whatever people typed into the console's SQL editor. Most of that is harmless. Some of it might not be: a CREATE USER ... IDENTIFIED BY statement, a connection string pasted into a comment, a query that names a customer.
• Management API keys can create, change and delete clusters, backups and network settings. PingCAP says the exported values were encrypted. Replacing them removes the question entirely.
• Source code may help an attacker study the service. PingCAP lists stronger secret scanning among its follow-up work.

What to do now

PingCAP's customer action page is the authority here. The steps below follow it, then add checks that come from the TiDB Cloud documentation. Do them in this order.

1. List every API key in every organization you own. In the TiDB Cloud console, switch to each organization, open Organization Settings, then API Keys. Write down each key's description, role and scope. Revoke anything you no longer need. PingCAP asks for this review explicitly.

2. Find where each key is used before you touch it. The official API samples read keys from TIDBCLOUD_PUBLIC_KEY and TIDBCLOUD_PRIVATE_KEY, and many teams copy that naming. Search your code, infrastructure definitions and CI configuration:

   # In each repository
   git grep -n -i -E "tidbcloud|tidb_cloud|api\.tidbcloud\.com"
   
   # Terraform state and variable files often hold provider keys
   grep -rn -i "tidbcloud" --include="*.tf" --include="*.tfvars" .
   
   # Running containers and hosts
   env | grep -i tidbcloud
   

   Also check your CI secret store, your secrets manager, and any scheduled jobs that call the TiDB Cloud API.

3. Create a replacement key. In API Keys, click Create API Key, set the same role and scope, and generate it. Save both halves straight into your secrets manager. PingCAP notes the private key is shown only once.

4. Update every consumer and test it. The TiDB Cloud API uses HTTP digest authentication with the public key as user name and the private key as password. A quick check that the new key works:

   curl --digest \
     --user "$TIDBCLOUD_PUBLIC_KEY:$TIDBCLOUD_PRIVATE_KEY" \
     --request GET \
     --url "https://api.tidbcloud.com/api/v1beta/projects?page=1&page_size=10"
   

   A JSON list of projects means the key works. Run the job, pipeline or Terraform plan that depends on it before moving on.

5. Delete the old key. On the API Keys page, open the row menu, choose Delete and confirm. Then run the same curl with the old values; you should get a 401. Repeat for each organization.

6. If you suspect misuse, reverse the order. PingCAP says to revoke the key immediately, without creating a replacement first, and then email security@pingcap.com. Do not put passwords, tokens or keys in that email.

7. Turn on console audit logging if it is off. According to the TiDB Cloud docs, console audit logging is disabled by default, only an Organization Owner or Organization Console Audit Manager can enable it, logs are kept for 90 days, and only events after it is enabled are recorded. If it was off during September, you have no console history for that period. Turn it on now so you have one going forward.

8. Review the logs you do have. Download them as JSON or CSV from Console Audit Logging. Each record carries type, operator_type (user or api_key), operator_name, operator_ip, result and a timestamp. A first pass with jq, assuming the export is an array of records:

   # Every action taken by an API key, oldest first
   jq -r '.[] | select(.operator_type=="api_key")
          | [.ends_at, .type, .operator_name, .operator_ip, .result] | @tsv' audit.json | sort
   
   # Key and membership changes worth a second look
   jq -r '.[] | select(.type | test("APIKey|InviteUser|UpdateUserRole|UpdateAuthenticationMethod|IPAccessList"))
          | [.ends_at, .type, .operator_name, .operator_ip] | @tsv' audit.json | sort
   

   Look for unknown IP addresses, keys acting outside your automation's schedule, and changes to IP access lists, private endpoints, backups or members nobody remembers. If your export wraps records in an object, adjust the .[] path.

9. Treat SQL editor text as possibly exposed. This step is our suggestion, not PingCAP's. Ask your team whether anyone ran statements in the console SQL editor that contained passwords, tokens or personal data. If so, change those database passwords and note the exposure in your incident log.

10. Brief finance and support on phishing. PingCAP warns about requests to share passwords or one-time codes, to change payment or billing details, or to take urgent account action, even when the message contains accurate details about your organization. Verify any such request through a contact you already had, never through details in the message.

11. Tighten what you can. TiDB Cloud's security guidance recommends a current IP access list, private endpoints for production, organization SSO with MFA for stricter control, and sending console logs to a SIEM. PingCAP did not tie these to this incident, but each reduces what a stolen credential is worth.

PingCAP's notices do not ask customers to change database user passwords. Changing them is a reasonable extra step if you want certainty, but it is a separate decision from the API key rotation PingCAP requested.

Lessons for database-as-a-service users

Four lessons apply well beyond TiDB Cloud.

The control plane is part of your attack surface. Reviews of a managed database usually focus on encryption, TLS and who can connect. Account metadata, billing data and management credentials held by the provider deserve the same attention. Ask each provider what control plane data they hold about you.

Management keys are the most powerful secret you own there. A database password reaches one cluster. A management API key can often create, delete and reconfigure all of them. Keep few of them, scope them tightly, store them in a secrets manager, and rotate them on a schedule so that an emergency rotation is a routine you have already practised.

Logs you never enabled cannot help you. TiDB Cloud's console audit log is off by default, as many managed service logs are. Without it you cannot answer whether anyone used your keys in September. Decide which provider logs you need on day one and ship them somewhere you control.

Plan for the provider's notice, not just your own breach. When your provider is breached, the clock starts at their disclosure and the first facts are incomplete. Know who owns the relationship, which systems hold that provider's credentials, and who can rotate them, before the email arrives. For the same theme from a different angle, see our post on IDCF Cloud ransomware and concentration risk.

What would have helped

Practices any team can use

• A credential inventory per provider. One list per vendor: every API key, service account and token, where it lives, what it can do, who owns it. Step 2 above becomes a lookup instead of a search.
• Rotation that is automated and tested. A pipeline that writes the new key to the secrets manager and redeploys consumers turns a breach notice into a routine change.
• Provider audit logs on and exported. Enable console logging on day one and forward it to your SIEM, as TiDB Cloud's own guidance recommends.
• A rule about consoles. Keep secrets out of web SQL editors and support tickets. Use them for queries, not for setting passwords.
• A vendor record of what data each provider holds, so a notice's categories can be matched in minutes.
• A phishing playbook for finance. Verify every billing change request out of band.

Where Safeguard fits

Safeguard would not have prevented or detected this incident. It does not watch a provider's internal systems or hold your TiDB Cloud keys. Here is what it does touch.

Vendor records with an owner. Safeguard's Third-Party Risk Manager is generally available. You onboard vendors, request SBOMs, projects or products from them, score supplier risk and apply policies and gates. The compliance suite also has Vendors and Risks views, so "management keys for our database provider are not rotated on a schedule" can be recorded as a risk with an owner and a treatment, and your rotation evidence can be attached. That scoring is driven by what vendors share with you. It would not have warned anyone about this intrusion.

Knowing which services depend on the provider. Safeguard generates SBOMs from repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with JSON results under ./output). The platform shows which projects contain a given component and version, so you can find every service that ships a TiDB or MySQL client library. That is a quick way to build the list of applications to check in step 2. Our post on SBOM incident response covers the method.

Doing the rotation work with approval at each step. The Safeguard CLI's assistant can edit code and run commands on your machine, and it asks before each one in the default permission flow (/permissions offers Ask, Accept edits, Plan, Auto and Strict). You can ask it to find every place a repository reads TIDBCLOUD_PUBLIC_KEY, move hard coded values to environment variables, and run your tests, approving each change. The desktop and phone apps can send that work to a computer running the CLI and approve each command. In CI, safeguard exec runs the checks.

Zero-Day Discovery and Gold

These capabilities address a different problem. This breach involved stolen credentials at a provider, not a vulnerable package in your software.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, across seven package ecosystems. Findings are issued as SGZ advisories before they reach public CVE databases. It did not find anything related to this incident, and PingCAP has not published details of the four vulnerabilities it fixed.
• Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API, and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is paid. It offers hardened drop in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3+, signed with Sigstore, with evidence pages. An artifact loses its badge if it regresses.

The link is habit: teams that recover fastest from any supply chain event, whether a provider breach or a compromised npm package, already know what they run and can rebuild quickly from patched, signed components from a curated source. For a wider view of this month's incidents, see October 2026 security incidents and what would have helped.

Common mistakes

• Waiting for a direct notice. PingCAP asks every customer to act now. Its customer list is not final.
• Deleting the old key before updating consumers. Unless you suspect misuse, create, update and verify first, then delete. Otherwise you cause your own outage.
• Rotating one organization and forgetting the rest. PingCAP's steps are per organization. Many companies have a production org, a staging org and one somebody made for a hackathon.
• Forgetting Terraform and CI. Keys live in state files, pipeline variables and scheduled jobs as often as in application code.
• Reading an empty audit log as "nothing happened". If console audit logging was disabled, an empty log means no record, not no activity.
• Repeating the attacker's numbers as fact. The 10.6 TB and 180,000 organization figures come from the extortion group. Quote PingCAP and date your quote.
• Sending secrets to the security mailbox. PingCAP asks customers not to include passwords, tokens or keys in email.
• A 401 from the new key. Check you used --digest, put the public key before the colon, and created the key in the organization you are querying.

FAQ

Was my TiDB database data stolen?

PingCAP says it found no evidence that data stored in TiDB was impacted, and no evidence that the attacker ran commands or kept persistent access in the production systems reviewed. The confirmed exposure covers account, business and billing records, SQL editor text and errors, encrypted API key values and source code.

What exactly did PingCAP confirm was accessed?

User names, email addresses, organization and project associations, SQL editor text and errors, some cluster identifiers, customer contacts, contract terms, orders, pricing, payment terms, billing configuration, an exported table of encrypted API key values, and source code. PingCAP says not every customer had every category exposed.

Do I need to rotate my API keys if I was not notified?

Yes, according to PingCAP. Its 20 October page asks organization owners to replace active management API keys as a precaution, and to act now rather than wait for a direct notice.

Were API keys exposed in plaintext?

PingCAP says the exported values were encrypted and it has no evidence any were decrypted or used. The attacker's unverified claims go further. Rotating removes the question either way.

Should I change database user passwords?

PingCAP has not asked for this. If anyone typed passwords into the console SQL editor, change those, since SQL editor text is a listed category.

Does this affect self-managed open source TiDB?

PingCAP says the incident does not involve product vulnerabilities. Its notices concern TiDB Cloud accounts and PingCAP's internal systems. Self-managed users are not asked to take action.

How did the attacker get the service account credentials?

PingCAP has not said. Its notice describes stolen service account credentials and four vulnerabilities later reported by its incident response firm, without further detail.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show the TiDB Cloud incident. Each is a real Safeguard session; the text says how the same flow applies here.

The first demo is a CLI session that fixes a lodash CVE: the assistant reads the finding, asks before each command, edits package.json, runs the install and tests with approval, and pushes nothing. For TiDB Cloud, you would open the same session in the repository that calls the management API, ask it to find every reference to TIDBCLOUD_PUBLIC_KEY and replace any hard coded values with environment variables, then run your tests. It asks before each edit and command.

Click through it at your own pace, or open it full screen.

The second demo is a desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. During a provider notice, the same flow lets someone on the platform team point the assistant at the infrastructure repository holding the Terraform provider configuration and approve each change from the desktop app.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. With this flow, the on call engineer can approve the test run after a key swap, or deny an unexpected command, away from a desk.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• PingCAP: Security Update (19 October 2026)
• PingCAP: Security Incident, Recommended Customer Actions (20 October 2026)
• TiDB Cloud docs: Console Audit Logging
• TiDB Cloud docs: Security concepts
• TiDB Cloud API samples (GitHub)
• Crypto Briefing: Bitget says no user data exposed in alleged TiDB Cloud breach
• TokenPost: PingCAP intrusion exposes TiDB Cloud account and billing records
• LavX News: PingCAP discloses cloud security breach
• Runtime Wire: PingCAP confirms TiDB Cloud data exposure
• ChainCatcher: PingCAP responds to TiDB Cloud data breach
• HookPhish: FulcrumSec claim against PingCAP / TiDB Cloud

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.