PingCAP TiDB Cloud 数据泄露分析

PingCAP 安全事件概述

2026 年 10 月，与 FulcrumSec 相关的安全研究人员披露了 PingCAP TiDB Cloud 基础设施遭受全面入侵的事件。攻击者窃取了 10.6 TB 的数据，包括完整的控制平面、客户 SQL 语句、明文 API 密钥以及内部财务记录。此次泄露凸显了云安全方面的系统性失败，攻击者利用平台自身的基础设施进行了长达近两个月的数据窃取，且未被发现。

数据窃取范围

此次泄露导致攻击者获得了对海量敏感信息的未经授权访问权限，严重损害了 TiDB Cloud 服务的运营完整性。攻击者获取的关键数据点包括：

• 控制平面数据： 180,046 个租户组织、403,262 个唯一电子邮件地址以及 115,308 个明文客户 API 密钥。
• 客户工作负载： 20,645,574 条原始 SQL 语句，包括数千个租户的数据库架构和业务逻辑。
• 基础设施凭证： 客户 MySQL/Aurora 主机的根用户和管理员凭证，以及 AWS 和 GCP 项目标识符。
• 财务与商业数据： 详细的服务成本指标、NetSuite 收入账本以及包含全球大型企业信息的 CRM 记录。
• 源代码： 413 个私有代码仓库，包括计费引擎和加密库。

运营疏忽与监控缺失

攻击者报告称，他们保持了对 PingCAP 基础设施长达近两个月的持续访问权限。最值得注意的是，他们建立了一个自动化复制管道，每六小时导出一次整个控制平面数据库。该管道利用了在 PingCAP 自身源代码仓库中发现的凭证。尽管进行了 88 次连续导出，PingCAP 的安全监控系统却未能触发任何检测事件。

批评人士指出，这证明了“极度无能”，并指出虽然公司通常在端点检测与响应 (EDR) 工具上投入巨资，但往往忽视了基本的云安全规范，例如保护存储桶和监控服务账户的使用情况。

多租户隔离中的漏洞

内部文档显示，PingCAP 在泄露发生前几年就已经意识到存在重大的安全缺陷。一份 2022 年的内部安全工单 SECURITY-22 明确记录道，客户组织的任何成员（包括仅拥有计费角色的成员）都可以无条件重置该组织内所有集群的根密码。这一漏洞导致了潜在的跨租户数据访问，对于托管数据库提供商而言，这是一个致命的失败。

此外，调查发现 PingCAP 的工程师经常将客户的生产环境凭证粘贴到 Jira 工单中。这种做法实际上将公司的支持跟踪系统变成了一个敏感客户机密的存储库，随后被攻击者一并窃取。

行业反应与争议

在公开披露后，PingCAP 发表声明称，没有证据表明存在未经授权的命令执行或对客户数据造成影响。这一回应遭到了安全界的质疑，特别是考虑到攻击者持有并发布了包含 PingCAP 声称未受影响的数据的归档文件。

Hacker News 上的评论者对行业内反复出现的淡化此类事件的模式表示沮丧。正如一位观察者所言：“他们手里拿着数据压缩包，而 PingCAP 却声称没有数据受到影响。”此次事件重新引发了关于当前防御策略的有效性、集中式云管理的风险，以及基础设施提供商进行更严格、透明的安全审计的必要性的讨论。