Glonce

Group claims it breached PingCAP's TiDB Cloud and took 10.6 TB

securityThe Glonce editorsHacker News🔥67Glonce rating67Impact60Novelty60Relevance90Surprise65Players45Credibility35

An unnamed group publishing on the site fulcrumsec.vg says it breached PingCAP Inc., the company behind TiDB Cloud, the managed version of the open-source TiDB database. The post says the attackers hold 10.6 TB in total and are now making the breach public with a first "stage one" release of about 200 GB. Everything below is what the attackers say. The post carries no confirmation or denial from PingCAP, and no independent check of any figure.

According to the post, the group holds the complete TiDB Cloud control plane, its billing and finance estate, its GCP storage estate and its AWS cost and billing estate, plus Jira, the CRM, analytics, source code and a four-year log of every connection customers made to the product. The authors say they kept exfiltrating for nearly two months, topping up regularly after an initial exfiltration of about 8 terabytes, and that PingCAP never noticed across AWS, GCP, Atlassian/Jira and Azure. Their wording is that PingCAP "seem to have zero visibility into their own cloud services".

The most detailed technical claim concerns the control-plane database. The authors say they stood up a replication feed of it using credentials committed in PingCAP's own repositories: GCP service-account keys and an Azure service principal. Every six hours for the last 22 days of the campaign, from 8 September to 30 September, the feed re-exported every table covering tenants, users, API keys, cluster credentials, changefeeds and migrations. They count 88 consecutive exports with no detection event; the last ran at 06:02 UTC on 30 September. That data is said to be in the stage-one release. The post dates the breach to September 2026.

The post says tenant IDs can be tied to named customers through PingCAP's own ops audit trail, a 42-organisation table, and a 94-entry billing dictionary in the eda_service repository. Names listed include Mercari, PayPay, Fujitsu, SoftBank, DMM, AEON, Square Enix, Konami, BANDAI NAMCO, Flipkart, Airbnb, Pinterest, Databricks, Baidu, Atlassian, Cygames, LINE and PatSnap, among others. The authors say VPC CIDRs, cluster versions and endpoint hostnames are included, and for some customers, credentials too.

The authors also quote an internal PingCAP security tracker ticket, SECURITY-22, dated 2022-08. As quoted, it says all roles of a customer organisation, including owner, audit admin, billing admin and member, could unconditionally reset the root password of all clusters in that organisation. The authors read this as meaning any member, even a billing-only role, could take over every cluster in the organisation as root, and note that the breach ran four years after the ticket.

A large part of the post is about credentials that, it says, PingCAP engineers paste into Jira tickets. Examples cited: a 2023 comment in ticket GTOC-5812 with AWS keys said to be live at the time of exfiltration; ticket APID-11182, with an AWS IAM user named DEVOPS holding AdministratorAccess and AmazonS3FullAccess over 258 buckets, none of which the authors say belonged to PingCAP; ticket APID-11887, with 1,825 distinct production connection strings carrying usernames and passwords; and 38 presigned S3 URLs into one customer's bucket, posted by the same support engineer between 2024-01-25 and 2026-02-02. The biggest item is APID-12036, a 314 MB customer production slow-query log. The authors say it holds 8,027 distinct credential values: 7,485 AWS STS session key sets, 345 GitHub user-to-server tokens, 192 AI-platform API keys (OpenAI, Anthropic, Gemini, ElevenLabs, xAI and OpenRouter), one AWS root key pair, and one GitHub personal access token with 24 administrative scopes over 1,701 repositories, 843 of them private. They say this counts only other companies' credentials that are still live. They add that the companies whose GitHub admin and root AWS credentials leaked are unnamed and "will be hearing from us soon". The three worst credential logs are said to be included whole in the release.

The post also lists business data it says it holds: Salesforce ARR write logs; finance fixtures showing the Cygames contract (net fees $2,400,000, accumulated revenue $2,633,694.97), PatSnap (UK) Ltd's monthly net fees of $136,093.25, and an FY25 company cloud quota of $29,438,510.37; China CRM notes; a cloud_users crosswalk joining pseudonymous analytics IDs to named people; and a Mixpanel user table whose top countries are Japan 774, China 702, India 499, Hong Kong 416 and United States 342. It also cites a purchased reo.dev graph ranking developers at target accounts, with Tencent 3,327 active developers, Huawei 2,726, ByteDance 2,475 and AIG 2,140, and 712 named high-intent buyers at Mastercard, Flipkart, bKash, Quark, Actian and eSewa.

Of the 10.6 TB, the stage-one release is five tar.gz archives: 128.3 GB compressed, just over 200 GB uncompressed. The post ends with "More coming soon" and a redacted contact address.

Key facts

  • A group publishing on fulcrumsec.vg claims it breached PingCAP, maker of TiDB Cloud, and holds 10.6 TB; it has released a first tranche of five tar.gz archives (128.3 GB compressed, just over 200 GB uncompressed).
  • The authors say they exfiltrated for nearly two months, starting with about 8 TB, and that 88 consecutive six-hourly exports of the control-plane database, from 8 September to 30 September, triggered no detection.
  • They say the data maps tenants to named customers such as Mercari, PayPay, Fujitsu, SoftBank, Airbnb, Pinterest and Databricks, and includes credentials engineers pasted into Jira tickets, including 1,825 production connection strings in one ticket and 8,027 credential values in one 314 MB slow-query log.
  • They quote an internal 2022 ticket, SECURITY-22, which says any role in a customer organisation could reset the root password of all its clusters.
  • None of this is confirmed: the post includes no response from PingCAP and no independent verification.

Why it matters

TiDB Cloud runs customers' production databases on a shared, multi-tenant platform, so a compromise of its control plane would be a supply-chain problem rather than a single-company one. The post claims exactly that: control-plane tables covering tenants, API keys and cluster credentials, plus customer credentials sitting in support tickets. It also says an internal 2022 ticket described a weakness in tenant isolation, which the authors say was documented four years before they got in. Whether any of this is true is still open.

Who it affects

First, PingCAP. Second, the customers the post names or describes: banks, game studios and e-commerce platforms, in the authors' words, with listed names including Mercari, PayPay, Fujitsu, SoftBank, Airbnb, Pinterest, Databricks and Cygames. Third, companies whose own credentials ended up in PingCAP tickets and logs; the post says two of them, holding GitHub admin and root AWS credentials, will be contacted by the group. The post also lists named individuals in analytics and CRM data, and developers at target accounts in a purchased sales graph. It does not say whether any named customer confirmed being affected or was notified.

How to use it

There is nothing to install or adopt here. The practical angle is for TiDB Cloud customers and anyone who has shared credentials with PingCAP support: the post says tickets, attachments and logs contained live production credentials, connection strings and cloud keys, so those are the items to look at first. The post does not say where or how the stage-one archives are hosted or downloaded.

How solid is it

Weak so far. The whole account is self-published by the attackers; the post names no group in its text, only the domain fulcrumsec.vg appears as publisher. It contains detailed, specific artefacts (ticket IDs, repository names, counts, timestamps), but no independent party has confirmed them, and PingCAP's response is not given. The post's chronology puts the breach in September 2026. The 8,027-credential figure and the claim that PingCAP has no visibility into its cloud services are the authors' own, the latter an inference from nothing being detected.

Risks and caveats

Treat every number as a claim. The post does not describe how the attackers first got in, only the later use of credentials found in PingCAP repositories, and it states no ransom demand or deadline. The authors have a stake in presenting PingCAP as negligent, and the tone is combative. Customer names appear because the authors say they do; that is not evidence the customers were affected. The release is said to contain live third-party credentials and personal data, and the authors promise more, so the story is likely to develop.

“Because the root account of the cluster has extremely high privileges, this will lead to a great security risk.”

— PingCAP internal security tracker, ticket SECURITY-22, as quoted by the attackers' post