今天，我们公开平凯星辰（PingCAP Inc.）的泄露事件。我们已掌握 TiDB Cloud 的完整控制平面及其计费、GCP 存储、Jira、CRM、分析与源代码，并拥有四年来客户连接日志。泄露总计 10.6 TB，第一阶段发布 200 GB，包含 4,901,203 个文件，以及对生产控制平面 88 次未被发现、每六小时一次的连续导出。平凯星辰售卖 TiDB Cloud，这是开源 TiDB 数据库的托管版本，客户将生产负载交由它在共享多租户平台上运营集群。
正文
PingCAP Inc. / TiDB Cloud • 分布式数据库 • 外泄总量 10.6 TB • 首批发布 200 GB
今天，我们公开 PingCAP 的泄露事件。泄露数据总计 10.6 TB，涵盖 4,901,203 个文件；首批发布 200 GB。我们掌握了 TiDB Cloud 完整的控制平面、计费与财务体系、GCP 存储体系（约 50 个存储桶）、AWS 成本与计费体系、Jira、CRM、分析数据、源代码，以及四年来每个客户对其产品发起的每一次连接的日志（包括其应用服务器的 IP 地址）。
PingCAP 销售 TiDB Cloud，这是开源 TiDB 数据库的托管版本。银行、游戏工作室和电商平台把生产工作负载交给它；PingCAP 在共享的多租户平台上运维这些集群，其整个业务都建立在“这样做安全且可靠”这一说法上。而接下来的内容就是证据：事实并非如此。
首先，他们似乎对自己的云服务毫无可见性。可悲的是，在我们入侵过的公司里这很常见：它们愿意砸几百万买花哨的 EDR，却坐视五百个 S3 存储桶大摇大摆地外流。但 PingCAP 是一家云厂商。对 AWS、GCP、Atlassian / Jira、Azure 等每一个云服务的规模化、毫不隐蔽的入侵与外泄，竟然看似无法检测，这既可怕又极不负责。在初始约 8 TB 外泄之后，我们持续外泄近两个月，并定期补充。我们甚至用他们自己仓库里提交的凭证——GCP 服务账号密钥和一个 Azure 服务主体——搭建了他们控制平面数据库的复制流，并让他们自己的基础设施把数据送给我们。在行动的最后 22 天里，从 9 月 8 日到 9 月 30 日，这条管道每六小时准时重新导出 TiDB Cloud 运营核心的每一张表——租户、用户、API 密钥、集群凭证、changefeeds、迁移任务——并推送出来。连续 88 次导出，没有一次检测事件。最后一次运行于 9 月 30 日 06:02 UTC。它带出的控制平面数据在首批发布中。
我们拿走了什么
- 控制平面。 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 和 admin 账号——以及来自 VPC 对等记录的 290 个客户 AWS 账号 ID 和 85 个 GCP 项目 ID。
- 客户自己的 SQL。 从 SQL Editor 和 Chat2Query 捕获的 20,645,574 条原始 SQL 语句——数千租户的应用 schema、表结构和业务逻辑，按组织、项目和集群 ID 索引。其中一条语句创建了一张医疗专业人员表（usuario, nombre_usuario, contrasena）；另一条插入了巴西一家诊所的患者名单。这就是客户数据库的内容，由产品本身捕获，并经 PingCAP 自己的管道发送给我们。
- 目标地图。 网关访问日志就是一家数据库公司的在册客户目录：每个客户的连接量、应用服务器 IP、客户端程序（Rails 0.46M 次连接、ProxySQL、MySQL Workbench、langgenius/dify）以及集群 ID。任何想进一步接触 TiDB Cloud 客户的人都会从这里开始。全部 23,651 个每日文件都在 09gatewaylogs.tar.gz 中。
- 资金。 带有 resourcetagsusertenant 的 CUR 语料把 PingCAP 服务每个客户的成本变成了一次表连接：57 个月的 AWS 支出总计 107,195,238.42 美元，EDP 折扣 −10,362,705.51 美元，私有费率 −8,829,018.11 美元（较目录价约低 47%），仅 us-east-1 跨可用区传输就达 16,509,714.87 美元。结合财务数据库快照（按租户的净费用、monthlycloudorder、AR 表、8.8M 行的 dbaasbilling）和 ARR 写入日志，TiDB Cloud 的毛利——按具名客户、按产品家族——就是一条 SQL 查询。
- 商业账簿。 HubSpot：433,928 个联系人，191,187 家公司，名义价值 5.52 亿美元的交易——Wetech 7470 万美元，PayPay 4520 万美元，Atlassian 2580 万美元，SBI 2020 万美元，AEON 1070 万美元，TOPPAN 970 万美元。Stripe：全部 8,428 个付费租户，livemode，其中 8,301 个租户 ID 已关联到 Stripe 账号。NetSuite：584 家具名客户的收入分类账。AWS Marketplace：861 个买家街道地址，48,991 份订阅协议。中国分类账：12,262 行收入确认记录，总计 3.531 亿元人民币，客户包括中国银行、科技部和中国人寿。
- 源代码。 413 个仓库。计费引擎信任未经验证的 X-ACCOUNT-USER-ID 头。账号服务里 admin 就是一个租户 ID，且模拟身份能用 owner 角色绕过组织检查。共享加密库 pkgv2：AES-CBC 的 IV 由密钥前缀派生——一个静态 IV——并用单一服务器级 SaltSecret 实例化；平台中每一个加密的客户下游数据库密码，距离明文只差一个配置密钥。
- 身份图谱。 108,871,828 个事件中的 13,620,173 个 GA4 设备标识符；cloud_users 交叉表（290,458 行）把哈希用户 ID 关联到邮箱和雇主租户 ID；2,895,030 行把登录身份链接到 cookie 轨迹；Mixpanel 导出包含 3,552 个完整具名档案；来自 PingCAP 购买的 reo.dev 开发者情报图谱的 24,932 个个人邮箱及 LinkedIn、GitHub 档案——按购买倾向排名的腾讯 3,327 名最活跃工程师、华为 2,726 名、字节跳动 2,475 名。
记录中的客户
租户 ID 并非匿名。PingCAP 自己的运维审计轨迹把它们映射了出来：
| 客户 | 租户 ID / 详情 | | --- | --- | | 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 里早已写明警告
PingCAP 的安全团队在 2022 年就准确写下了他们自己产品多租户隔离的问题。来自内部安全跟踪器的 SECURITY-22，用他们自己的话说：
摘要：集群的 root 密码可以被无条件重置。
“组织中的所有角色（包括 owner、audit admin、billing admin、member）都可以无条件重置该组织内所有集群的 root 密码。这会导致组织内所有用户都能重置集群 root 密码，随后用户即可以 root 身份连接集群、修改集群状态并访问集群数据。”
“由于集群 root 账号权限极高，这将带来极大的安全风险。”
在我们进入的四年前，PingCAP 自己的安全团队就已经记录：客户组织中的任何成员——包括仅有计费权限的角色——都能以 root 身份接管该组织内的每一个集群。工单日期为 2022-08。泄露持续到 2026 年 9 月。一家数据库公司。
“支持操作”如何成为跨租户泄露引擎
PingCAP 的工程师把客户的生产凭证粘贴进 Jira 工单。最严重的三条日志完整收录在发布中（02customercredentiallogs），工单本身在 05jira_issues 中：
GTOC-5812，2023-02-01，工单内评论（外泄时仍有效）：
AWSACCESSKEYID=AKIAYM5Y2YXDRDJD2IOM AWSSECRETACCESSKEY=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 aws s3 ls s3://pingcap-logs-pinterest/
APID-11182，附件 81543_tidb-log.txt，由 t.yudhanapinan@accenture.com 于 2025-05-02 发布，位于一行 TiDB BR 备份配置中（bucket:"cdx-crs-tidb-backup"）：
AKIA2VMQLYWL3LJEHQFC : D7kJLJ2qIcdrjHrusWh5VTygW82hWN1ILirDosS7 ARN arn:aws:iam::733131556247:user/DEVOPS — 对 258 个桶拥有 AdministratorAccess + AmazonS3FullAccess，包括 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。
APID-12036，一份 314 MB 的客户生产慢查询日志，附在支持工单上（附件 106965，完整收录于发布中）。UPDATE 语句中包含客户的按用户凭证库：8,027 个不同值——7,485 组限定于每用户沙箱仓库的 AWS STS 会话密钥、345 个 GitHub user-to-server 令牌、192 个 AI 平台 API 密钥（涵盖 OpenAI、Anthropic、Gemini、ElevenLabs、xAI 和 OpenRouter）、一对 AWS root 密钥、一个拥有 24 项管理 scope、覆盖 1,701 个仓库（843 个私有）的 GitHub 个人访问令牌——而这还只统计了仍然有效的其他公司凭证。这些客户是 PingCAP 疏忽的受害者；尤其是那些 GitHub 管理员凭证和 AWS root 凭证被 PingCAP 泄露的不幸公司。这两家公司的泄露完全源于它们选错了云服务提供商；尽管我们确实同情他们，但他们很快就会收到我们的消息。
APID-11887，1,825 条带用户名和密码的生产连接字符串，其中一条原文如下：
mysql://3QqgLjKpGPJ9jgG.root:B2Bqr2e3W887JYkODVju@gateway02.us-east-1.prod.aws.tidbcloud.com:4000/6nyf9vDx56DJcbNfYFeWX6?ssl={"rejectUnauthorized":true}
TCID-2287：
mysql://redbulltestreplicatedtidb:IteXIxM6ew1@95.217.43.247:3306/redbulltestreplicated_tidb.*
同一名支持工程师在 2024-01-25 至 2026-02-02 期间发布的 38 个预签名 S3 URL，指向一个客户自己的桶 debank-temp.s3.ap-northeast-1.amazonaws.com。
客户把连接其应用到该产品的凭证托付给 PingCAP。而 PingCAP 的工单系统随后把这些凭证分发给了任何持有这份数据的人。
每位客户的毛利
ARR 写入日志记录了按 Salesforce 账号的每一次月度写入（07arrsalesforce_logs）：
write to salesforce success: {'MonthEndARRAmountc': '2931005.0', 'Accountc': '0015g000002hX2QAAU', 'RevenueMonthc': '2025-01-01', 'Product_Familyc': 'TiDB Enterprise Subscription'}
write to salesforce success: {'MonthEndARRAmountc': '2100000.0', 'Accountc': '0015g000002hX2SAAU', 'RevenueMonthc': '2025-01-01', 'Product_Familyc': 'TiDB Enterprise Subscription'}
write to salesforce success: {'MonthEndARRAmountc': '1137016.2', 'Accountc': '001BV000003Ra97YAC', 'RevenueMonthc': '2025-01-01', 'Product_Familyc': 'TiDB Enterprise Subscription'}
Cygames 的合同在财务 fixture 中，并带有其生产数据：租户 1372813089191061283，订单 JP-OF-25030306，净费用 2,400,000 美元，累计收入 2,633,694.97 美元。PatSnap (UK) Ltd 的月度净费用：136,093.25 美元。FY25 公司云配额：29,438,510.37 美元。
而在中国 CRM 里，一条销售活动备注写道：
中国人寿，是已经签了商务合同的客户。转移到大客户线索池。 （China Life —— 一家已签署商业合同的客户。已转入企业线索池。）
身份图谱中的客户
cloud_users 交叉表把匿名化的分析层关联到了具名的人：
{"metadbuserid": "6150003", "ga4userid": "a97cedec6bee3080548ba9209a65f2ab44c6a44e123bdbf84e44c9b832f1f894", "tenantid": "1", "createdat": "2022-03-30 10:43:08 UTC", "updatedat": "2022-04-02 09:51:45 UTC", "useremail": "sophie.wang@pingcap.com", "useremaildomain": "pingcap.com", "userstatus": "active", "userfirstname": "Sophie", "userlastname": "Wang", "pseudousers": [{}]}
控制台页面 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 — 大阪，最后出现于 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 名具名的高意向买家。
首批发布
在我们掌握的 10.6 TB 中，首批发布是五个 tar.gz 归档——压缩后 128.3 GB，解压后略超 200 GB。更多内容即将发布。
| 归档 | 大小 | 内容 | 下载 | | --- | --- | --- | --- | | 11curtenantcosts.tar.gz | 70.6 GiB | 按租户归集的 AWS 成本数据（2022–2026）：92 GB 按月分区的 parquet，其中每一行都带有 resourcetagsusertenant——即按集群、区域、组件，对照全套 savings plan 和预留实例定价，服务每个具名客户的成本；外加 916,945 条结果的 Athena 成本分析语料（按小时的 Dedicated 与 Serverless 层级成本、NLB 与跨可用区传输分析） | MAGNET | .torrent | ONION | | 04bigquery.tar.gz | 31.5 GiB | 完整的 BigQuery 分析体系，83 个数据集、5.338 亿行：metadb 控制平面镜像（2360 万行）、sqleditor 视图、cloudusers 去匿名化交叉表、GA4 Web 分析（1.089 亿事件、1360 万设备标识符）、salesforce、netsuite 和 hubspot 摄取数据集、reodev 开发者情报图谱，以及 401,911 行原始销售通话转录 | MAGNET | .torrent | ONION | | 10repos.tar.gz | 17.2 GiB | 413 个私有仓库，跨五个 GitHub 组织（tidbcloud、pingcap-inc、pingcap、tidb-incubator、Sibyl-TiDB）的完整 git 历史：计费引擎、账号/身份服务、运维门户、共享加密库、内部 IT 平台，以及把客户映射到活跃租户 ID 的 SRE 审计仓库 | MAGNET | .torrent | ONION | | 09gatewaylogs.tar.gz | 6.9 GiB | 四年 TiDB Cloud Data Gateway 访问日志——23,651 个每日文件，41 GB 原始日志：846,527 个客户集群上的 102,003,766 次连接，1,443,915 个 SQL 用户名，5,036,738 个唯一客户端 IP，以及每个客户端的软件指纹 | MAGNET | .torrent | | pingcapleakpackrest.tar.gz | 2.1 GiB | 八个精选集合：01decoderadmissions（SECURITY 与 HR 跟踪器、生产配置、cloudsqlsecrets.json、opstrail 客户→租户解码器、94 条账单字典） • 02customercredentiallogs（三条带凭证的支持日志：vida BYOK 存储、CardX 管理员密钥、CDC 管道日志） • 03customerbook（HubSpot、Stripe、AWS Marketplace 数据源、中国 CRM 提取、Mixpanel 已识别用户表） • 05jiraissues（57 个项目中的全部 377,446 个工单） • 06financesnapshots（2026-10-04 的 dffinance 与 nexuscrm 生产快照，helix/pingkai/rdgroup 摄取，财务门户源码与 terraform state） • 07arrsalesforcelogs（月度 ARR 写入日志） • 08firewatchchats（290 个租户告警聊天导出） | MAGNET | .torrent | | pingcap-stage-one.torrent | 128.3 GiB | 五个归档合为一个下载 | MAGNET | .torrent |
评论
讨论气氛以震惊和追责为主。多数人把这次事件视为 PingCAP / TiDB Cloud 控制平面、计费财务、源代码和全部客户数据的灾难性泄露，并严厉批评其凭证管理与运维监测失职；分歧并不在“是否严重”，而在少数人转向讽刺安全宣传、补充攻击者身份与云成本等外围信息，社区里基本没有替厂商辩护的声音。
认为这是控制平面与客户数据的全面泄露，规模被严重低估
- 攻击者自称已拿到 TiDB Cloud 控制平面、计费与财务、GCP 存储、AWS 成本账单、Jira、CRM、分析、源代码，以及客户四年连接日志和应用服务器 IP；评论者认为这等于所有客户和数据都被泄露，且同一天还叠加其他云事故，事态已经“完了”。（高赞） > 这是 TiDB Cloud 所有客户和数据的整体泄露，而且全都发生在同一天（@rvz）
- 也有人直接质疑外界为什么不更大规模讨论这起泄露，认为严重程度和关注度不匹配。（少数人）
认为 PingCAP 存在“登峰造极”的失职，凭证管理尤其致命
- 攻击者被指用代码仓库里提交的 GCP 服务账号密钥和 Azure 服务主体，搭建了对控制平面数据库的持续复制管道；在 22 天里每 6 小时导出租户、用户、API 密钥、集群凭证、变更流、迁移等核心表，而 PingCAP 长时间未发现。最反直觉的是，失败点并非被未知漏洞打穿，而是自己把长期有效的云凭证提交进仓库，并让基础设施持续向攻击者“投喂”数据。（高赞） > 攻击者用仓库里的 GCP 服务账号密钥和 Azure 服务主体，让 PingCAP 自己的基础设施每 6 小时投递一份控制平面数据库（@dherls）
认为刚通过 NCC 安全审计就泄露，让厂商和审计方都很尴尬
- NCC 对 TiDB 的安全评估刚结束不久就发生如此严重的控制平面泄露，评论者认为这不仅打脸厂商，也让安全审计的公信力受损；审计结论与真实风险之间的落差成为集中嘲点。（较多人） > 紧跟在 NCC 安全审计之后发生，对所有相关方都很尴尬（@xKingfisher）
- 还有人以讽刺口吻指出：厂商和社区强调“全内存安全、没有数据竞争”，但真正暴露的却是集群 root 密码可被无条件重置这类基础鉴权问题，安全宣传与实际防护完全脱节。（少数人）
担心自己作为客户或评估者的个人信息已卷入泄露
- 有开发者表示自己最近从 Aurora 迁移到 PlanetScale，曾认真评估 PingCAP，最终因云定价太复杂而放弃；现在担心个人或评估资料已在泄露范围内，折射出客户对厂商数据保管的直接不安。（少数人） > 我最近认真考虑过 PingCAP，因为云定价太复杂没选，现在怀疑我的个人信息也在泄露里（@nemothekid）
有价值的补充
- PingCAP 的云成本结构被顺带披露：其 AWS 私有价格约为目录价 47% 折扣，跨可用区流量占账单 15%，对数据库公司而言并不意外。 > PingCAP 享有约 47% 的 AWS 私有价格折扣，跨可用区流量占其账单 15%（@arpinum）
- 攻击者背景方面，这次活动疑似出自云敲诈组织 FulcrumSec；相关分析称该组织已累计约 21 名受害者。 > 这次攻击疑似来自已累计约 21 名受害者的云敲诈组织 FulcrumSec（@esafak）