疑 TiDB Cloud 数据泄漏：10.6TB

FulcrumSec 爆出从 PingCAP TiDB Cloud 窃取 10.6 TB 的数据。 以下为原始文章 Gemini 翻译，原始地址“查看原文”

原文地址，— FulcrumSechttps://fulcrumsec.vg/pingcap/[1]

THE PingCAP / TiDB Cloud LEAKS

PingCAP Inc. / TiDB Cloud • 分布式数据库 • 总计窃取 10.6 TB 数据 • 第一阶段发布 200 GB

数据概览与下载摘要

•10.6 TB 总窃取数据量•4,901,203 个文件•连续 88 次（每 6 小时一次）导出生产环境控制平面（Control Plane），全程未被察觉•约 50 个 GCP（谷歌云）存储桶•包含 5.338 亿行 数据的 BigQuery 数据仓库•180,046 个租户组织•403,262 个独立电子邮箱•115,308 个明文客户 API 密钥（其中 42,612 个处于激活状态）•20,645,574 条客户 SQL 语句•102,003,766 次网关连接记录•5,036,738 个客户服务器 IP 地址•377,446 个 Jira 工单（Issues）•433,928 个 CRM 联系人•92 GB 带有租户标签的 AWS 成本数据•413 个私有源代码仓库

正文

今天，我们将 PingCAP 数据泄露事件公之于众。我们掌握了完整的 TiDB Cloud 控制平面、其计费和财务资产、GCP 存储资产、AWS 成本与计费资产、Jira 系统、CRM（客户关系管理）系统、分析数据、源代码，以及长达四年的客户连接日志——记录了每一位客户从其应用服务器 IP 地址连接到该产品的每一次操作。

PingCAP 销售的 TiDB Cloud 是开源数据库 TiDB 的托管版本。银行、游戏工作室和电子商务平台将他们的生产工作负载交由其托管；PingCAP 在一个共享的多租户平台中运行这些集群，而其整个业务都建立在“这样做既安全又可靠”的宣称之上。本文接下来的内容将证明，它既不安全，也不可靠。

首先，他们似乎对自己的云服务毫无可见性（零监控感知）。在我们攻破的公司中，这可悲地成为了常态——这些公司会斥资数百万美元购买华而不实的 EDR（端点检测与响应系统），却任由五百个 S3 存储桶大摇大摆地被人搬空。但 PingCAP 是一家云服务提供商。对其自身的每一项云服务（AWS、GCP、Atlassian / Jira、Azure）遭受大规模、毫不掩饰的入侵和数据窃取居然毫无察觉能力，这是极其恶劣且极其不负责任的。

在最初窃取了约 8 TB 数据之后，我们在近两个月的时间里持续进行数据外传，并定期补充最新数据。我们甚至利用他们自己代码仓库中提交的凭证（GCP 服务账号密钥和一个 Azure 服务主体），搭建了一个针对其自身控制平面数据库的复制订阅源（Replication feed），并让他们的基础设施自动把数据推送给我们。在行动的最后 22 天里（从 9 月 8 日到 9 月 30 日），每隔六个小时，这条数据管道就会忠实地将 TiDB Cloud 运营核心的每一张表——租户、用户、API 密钥、集群凭证、变更订阅（changefeeds）、数据迁移任务——重新导出并推送出来。连续 88 次导出，没有触发任何一次告警检测。 最后一次导出运行于 9 月 30 日 06:02 UTC。它所携带的控制平面数据已包含在第一阶段发布中。

我们拿走了什么（What We Took）

•控制平面（The control plane）：metadb 被完整复制：包含 180,046 个租户组织、292,276 条用户记录（其中 166,108 条带有真实姓名）、403,262 个独立邮箱、388,861 个项目、3,448,054 个 Serverless 集群、16,299 个专属（Dedicated）集群、115,308 对以明文存储的控制台 API 密钥对（42,612 个处于激活状态；最新的一个生成于 9 月 30 日 04:46，就在我们关闭数据通道的几个小时前）、来自客户数据迁移任务的 1,809 个外部数据库端点（客户 MySQL/Aurora 主机上的 root 和管理员账号），外加来自 VPC 对等连接（VPC peering）记录的 290 个客户 AWS 账号 ID 和 85 个 GCP 项目 ID。•客户自己的 SQL（The customers' own SQL）： 从 SQL 编辑器（SQL Editor）和 Chat2Query 中捕获的 20,645,574 条原始 SQL 语句——涵盖了数千个租户的应用程序 Schema、表结构设计和业务逻辑，并按组织、项目和集群 ID 进行了索引关联。其中一条语句创建了一张医疗专业人员表（字段为 usuario, nombre_usuario, contrasena）；另一条语句插入了一家巴西诊所的患者花名册。这些都是客户数据库的内容，由产品自身捕获，并通过 PingCAP 自己的数据管道直接打包送到了我们手里。•攻击目标地图（The targeting map）： 网关访问日志就是一家数据库公司的“客户装机名录”：记录了每个客户的连接量、他们的应用服务器 IP 地址、客户端程序（Rails 占 46 万次连接，此外还有 ProxySQL、MySQL Workbench、langgenius/dify）以及他们的集群 ID。任何计划进一步渗透 TiDB Cloud 客户的人，都可以从这里开始。全部 23,651 个按日切分的文件均包含在 09_gateway_logs.tar.gz 中。•资金与财务（The money）： 带有 resource_tags_user_tenant 标签的 AWS 成本与使用情况报告（CUR）语料库，只需一次电子表格关联（Join），就能算出 PingCAP 服务每位客户的成本：长达 57 个月的 AWS 支出总计 $107,195,238.42，EDP 折扣为 -$10,362,705.51，私有协议费率折扣为 -$8,829,018.11（约合目录价的 5.3 折 / 减免 47%），仅 us-east-1 跨可用区（cross-AZ）流量传输一项就高达 $16,509,714.87。结合财务数据库快照（按租户统计的净费用、monthly_cloud_order、应收账款表 AR、多达 880 万行的 dbaas_billing）以及 ARR（年度经常性收入）写入日志，只需一条 SQL 查询，就能算出 TiDB Cloud 按实名客户、按产品线划分的毛利率。•商业账本（The commercial book）：

•HubSpot： 433,928 个联系人，191,187 家公司，名义总价值达 5.52 亿美元的交易（Deals）——其中包括 Wetech（$7,470 万）、PayPay（$4,520 万）、Atlassian（$2,580 万）、SBI（$2,020 万）、AEON（永旺，$1,070 万）、TOPPAN（凸版印刷，$970 万）。•Stripe： 全部 8,428 个付费租户（生产环境 livemode），其中 8,301 个租户 ID 已关联至 Stripe 账户。•NetSuite： 584 家实名客户的收入分类账。•AWS Marketplace： 861 个买家的街道地址，48,991 份订阅协议。•中国区账本： 12,262 行收入确认记录，总计 3.531 亿元人民币（¥353.1M），客户中包括中国银行、中华人民共和国科学技术部以及中国人寿。

•源代码（The source code）： 413 个代码仓库。其中包括：直接信任未经验证的 X-ACCOUNT-USER-ID 请求头的计费引擎；将 admin 作为租户 ID 且拥有 owner 角色的模拟登录（Impersonation）可绕过组织检查的账户服务；以及共享加密库 pkgv2——它使用 AES-CBC 模式，但初始向量（IV）直接从密钥前缀派生（即静态 IV），并使用全服务器唯一的 SaltSecret 进行实例化；这意味着平台上每一个加密的客户下游数据库密码，距离明文都只差一个配置密钥。 •身份图谱（The identity graph）： 涵盖 108,871,828 个事件的 13,620,173 个 GA4（Google Analytics 4）设备标识符；将哈希用户 ID 与电子邮箱及雇主租户 ID 关联起来的 cloud_users 交叉映射表（290,458 行）；将登录身份与 Cookie 轨迹关联的 2,895,030 行记录；包含 3,552 个完整实名档案的 Mixpanel 导出数据；以及来自 PingCAP 购买的 reo.dev 开发者情报图谱的 24,932 个附带 LinkedIn 和 GitHub 档案的个人邮箱——其中包含腾讯最活跃的 3,327 名工程师、华为的 2,726 名、字节跳动的 2,475 名，全部按其购买倾向进行了排序。

记录中的客户名单（The Customers in the Records）

这些租户 ID 并非匿名。PingCAP 自己的运维审计追踪记录（ops audit trail）直接将它们映射到了具体客户：

客户名称 (Customer) 租户 ID / 详情 (Tenant ID / Detail) Booking.com

tenant 1372813089189081313

Shopee

tenant 1372813089191241283

CAPCOM CO., LTD

tenant 1372813089188871292 , TiDB v6.1.1, ap-northeast-1

Colopl

tenant 1326455380288475136 , TiDB v6.1.0

TOPPAN INC. prod-1372813089204501289

, aws-ap-northeast-1

Catalyst Software prod-1372813089188151289

, aws-us-east-1

SB Payment Service prod-1372813089206331321

, aws-ap-northeast-1

……此外，在同一个包含 42 个组织的表格以及 eda_service 代码仓库随附的 94 条目计费字典中，还包括：

Mercari、PayPay、Fujitsu（富士通）、SoftBank（软银）、DMM、AEON（永旺）、Square Enix（史克威尔艾尼克斯）、Konami（科乐美）、BANDAI NAMCO（万代南梦宫）、Delhivery、Flipkart、Quincus、Nylas、Airbnb、Pinterest、Databricks、bitget、Pionex、DigiPlus、NFTscan、Baidu（百度）、SES-imagotag、Persona、Transsion（传音）、ZOZO、gumi、iret、Classmethod、Wetech、Atlassian、Cygames、SBI、LINE、Chainbase、PatSnap（智慧芽）。

他们各自的 VPC CIDR 网段、集群版本和端点主机名均包含在内；而对于那些不幸被粘贴到技术支持工单里的客户，连他们的访问凭证也一并包含在内。

早就写在 Jira 里的警告（The Warning Was Already in Jira）

早在 2022 年，PingCAP 的安全团队就已经在内部安全追踪系统中一字一句地写下了他们自己产品在多租户隔离方面存在的问题。以下是来自内部安全工单 SECURITY-22 的原话：

摘要：“集群的 root 密码可以被无条件重置” “组织内的所有角色（包括：所有者 owner、审计管理员 audit admin、计费管理员 billing admin、普通成员 member）都可以无条件重置该组织内所有集群的 root 密码。这将导致组织内的所有用户都能重置集群 root 密码，随后用户即可使用 root 身份连接到集群、修改集群状态并访问集群数据。” “由于集群的 root 账户拥有极高的权限，这将带来巨大的安全风险。”

在我们长驱直入的整整四年前，他们自己的安全团队就已经记录下：客户组织中的任何成员——哪怕只是一个仅有计费权限的角色——都能以 root 身份接管该组织下的每一个集群。该工单的日期是 2022 年 8 月。而这次入侵一直持续到 2026 年 9 月。这居然是一家数据库公司。

沦为“跨租户泄密引擎”的技术支持服务（The 'Support Operation' as a Cross-Tenant Disclosure Engine）

PingCAP 的工程师们习惯将客户的生产环境凭证直接粘贴到 Jira 工单中。最恶劣的三份日志已完整包含在本次发布的数据包中（位于 02_customer_credential_logs），而工单本身则位于 05_jira_issues 中：

1.

工单 GTOC-5812（2023-02-01），工单评论内（在数据窃取时仍处于激活有效状态）：

aws s3 ls s3://pingcap-logs-pinterest/

2.

工单 APID-11182，附件 81543_tidb-log.txt，由 t.yudhanapinan@accenture.com 于 2025-05-02 上传，位于一行 TiDB BR 备份配置中（bucket:"cdx-crs-tidb-backup"）：

AKIA2VMQLYWL******** : D7kJLJ2qIcdrjHru************************

对应 ARN 为 arn:aws:iam::733131556247:user/DEVOPS —— 拥有 258 个存储桶的 AdministratorAccess（管理员权限）+ AmazonS3FullAccess（S3 完全访问权限），涉及的存储桶包括 cdx-exp-npci-vault-snapshot、cdx-dev-npci-los-loandoc、cdx-dev-pci-sftp、cdx-sit-npci-lgc-smarttax-cloudhsm、cdx-dev-crs-silverlake-misc-binaries。这些存储桶没有一个是属于 PingCAP 的。

3.

工单 APID-12036，附在支持工单上的一个 314 MB 的客户生产环境慢查询日志（附件 106965，已完整包含在发布包中）：

其中的 UPDATE 语句包含了该客户的单用户凭证存储库：共有 8,027 个独立凭证值——包括 7,485 套限定在单用户沙盒仓库范围的 AWS STS 会话密钥、345 个 GitHub 用户到服务器令牌（user-to-server tokens）、横跨 OpenAI、Anthropic、Gemini、ElevenLabs、xAI 和 OpenRouter 的 192 个 AI 平台 API 密钥、1 对 AWS root 密钥、以及 1 个拥有 24 项管理员权限范围（涵盖 1,701 个仓库，其中 843 个为私有仓库）的 GitHub 个人访问令牌（PAT）——而且这还仅仅是统计了其他公司目前依然有效的凭证。这些客户都是 PingCAP 玩忽职守的受害者；尤其是那两家极其倒霉的公司，他们的 GitHub 管理员凭证和 AWS root 凭证直接被 PingCAP 泄露了出去。这两家公司之所以遭受数据泄露，完全是因为他们选错了云服务商；虽然我们很同情他们，但我们很快就会联系他们。

4.

工单 APID-11887，包含 1,825 条内嵌了用户名和密码的独立生产环境数据库连接字符串，以下为其中一条原样摘录（密码已脱敏）：

mysql://3QqgLjKpGPJ9jgG.root:B2Bqr2e3************@gateway02.us-east-1.prod.aws.tidbcloud.com:4000/6nyf9vDx56DJcbNfYFeWX6?ssl={"rejectUnauthorized":true}

工单 TCID-2287：

mysql://redbulltest_replicated_tidb:Ite_********@95.217.43.247:3306/redbulltest_replicated_tidb.*

38 个指向某客户自有存储桶（debank-temp.s3.ap-northeast-1.amazonaws.com）的预签名 S3 URL，由同一名技术支持工程师在 2024-01-25 至 2026-02-02 期间陆续发布在工单中。

客户出于信任，将连接其应用程序与产品的核心凭证托付给了 PingCAP；而 PingCAP 的工单追踪系统随后就把这些凭证分发给了任何拿到这份数据的人。

按客户计算的利润率（The Margin, Per Customer）

ARR（年度经常性收入）写入日志记录了每个 Salesforce 账户每月的写入情况（位于 07_arr_salesforce_logs）：

Plaintext

write to salesforce success: {'Month_End_ARR_Amount__c': '1137016.2', 'Account__c': '001BV000003Ra97YAC', 'Revenue_Month__c': '2025-01-01', 'Product_Family__c': 'TiDB Enterprise Subscription'}

Cygames 的合同及其生产环境数据就躺在财务测试固件（finance fixtures）里：租户 1372813089191061283，订单号 JP-OF-25030306，净费用 $2,400,000，累计收入 $2,633,694.97。PatSnap (UK) Ltd 的月度净费用：$136,093.25。2025 财年（FY25）公司云业务配额目标：$29,438,510.37。

而在中国区 CRM 系统中，一条销售活动备注这样写道：

“中国人寿，是已经签了商务合同的客户。转移到大客户线索池。”

cloud_users 交叉映射表将假名化的分析层数据直接与实名个人关联了起来：

JSON

{"metadb_user_id": "6150003", "ga4_user_id": "a97cedec6bee3080548ba9209a65f2ab44c6a44e123bdbf84e44c9b832f1f894", "tenant_id": "1", "created_at": "2022-03-30 10:43:08 UTC", "updated_at": "2022-04-02 09:51:45 UTC", "user_email": "sophie.wang@pingcap.com", "user_email_domain": "pingcap.com", "user_status": "active", "user_first_name": "Sophie", "user_last_name": "Wang", "pseudo_users": [{}]}

控制台页面 URL 携带着租户上下文信息：

/clusters/10144798180725090481/sqleditor?orgId=1372813089209261904&projectId=1372813089454579595

Mixpanel 的 user.csv 用户档案表记录示例：

•randy.lai@klook.com — 香港，跑马地（Happy Valley），最后活跃时间 2022-08-11•hanlin.shi@pingcap.com — 美国，米尔皮塔斯（Milpitas）•yilong.rong@pingcap.com — 大阪（Osaka），最后活跃时间 2022-07-05

排名前列的国家/地区： 日本 774 · 中国 702 · 印度 499 · 中国香港 416 · 美国 342。

从邮箱域名中可见的雇主企业： Klook（客路）、Colopl、Cygames、Booking.com、Mercari、Alibaba（阿里巴巴）、Amazon（亚马逊）。

他们购买的 reo.dev 图谱将目标客户公司的开发者按购买倾向进行了排序，并附带了商务邮箱和 LinkedIn 个人档案：腾讯有 3,327 名活跃开发者、华为 2,726 名、字节跳动 2,475 名、AIG（美国国际集团）2,140 名；此外还有分布在 Mastercard（万事达卡）、Flipkart、bKash、Quark（夸克）、Actian、eSewa 的 712 名实名高意向买家。

第一阶段发布内容（Initial Release）

在我们持有的 10.6 TB 数据中，第一阶段发布包含 5 个 tar.gz 压缩归档文件——压缩后大小为 128.3 GB，解压后略超 200 GB。更多数据即将放出。

联系方式：**@onionmail.org

平凯数据库回应

https://pingkai.cn/trust/security/updates/2026-10-20[2]

老冯评论

作为数据库业内人士，老冯对这起事件的草台程度表示震惊。但是都是熟人，没法评论。

其实最近也有过一些 PostgreSQL 云托管厂商被披露和攻击的消息，但并没有引起太多关注。这里的暗潮涌动，让老冯感到很担忧。

以现在的漏洞披露速度和修复跟进的这个业界状态，我认为用不了多久，所有的云数据库和云服务器可能都会被打成筛子。

明天我会专门写一篇来聊聊这件事。

References

[1]: https://fulcrumsec.vg/pingcap/
[2]: https://pingkai.cn/trust/security/updates/2026-10-20