PingCAP泄露10.6T数据

原创

泼猴
泼猴

表哥带我

2026年10月27日 10:41
广东

去阅读

开源数据库 TiDB 背后的厂商 PingCAP（平凯星辰）的托管云服务 TiDB Cloud 在近日遭勒索组织 FulcrumSec 攻击，攻击者声称窃取约 10.6TB 数据并公开了首批约 200GB 样本供下载。

TiDB Cloud 是 PingCAP 面向企业客户推出的全托管云数据库服务，用户可以不开源版、直接用它的云端数据库。这次被勒索组织盯上并声称窃取 10.6TB 数据的，正是这个云服务的控制平面（租户、集群、密钥等元数据）。

戏剧的是，顶级第三方机构NCC Group在9月1日对 TiDB 的源码安全发布评估为：没有严重、高危、中危问题，全部为低危对产品源码的审计结论，但没有覆盖运营区。

同一天，公司宣布任命新的首席安全官（CISO）。

几天后（9月8-9日），攻击开始。攻击者自称 9 月 8 日搭建控制平面复制通道、开始导出；官方确认的未授权访问从 9 月 9 日开始。

零告警

FulcrumSec在声明中描述，攻击是从 PingCAP 自己托管在 GitHub 的代码仓库中，发现了已提交进仓库的 GCP 服务账号密钥和 Azure 服务主体凭据。

2026 年 9 月 9 日起，攻击者利用这些被盗的服务账号凭据进入 PingCAP 内部系统，接触到云管理、财务、分析、存储系统，并复制数据、取得源代码。

他们利用云环境中过度授权的权限和缺乏分段，横向扩展到 Google Cloud 存储（自称约 50 个 GCP 存储桶）、BigQuery 数据仓库（自称 5.338 亿行）、Jira、CRM 等平台 —— 全程使用合法云凭据和云原生 API，无恶意软件、无外部 C2 基础设施，传统基于 IOC 的检测基本失效。

9 月 8 日至 30 日连续 22 天、88 次导出、零告警，最后一次运行于 9 月 30 日 06:02 UTC。初期拖走约 8TB，之后持续 \"补货\" 到 10.6TB。

疑似被拖走的核心资产

被黑客点名的企业名单相当庞大，包括 Booking、Shopee、CAPCOM、Mercari、PayPay、富士通、软银、Square Enix、BANDAI NAMCO、Airbnb、Pinterest、Databricks 等公司，也包括 Bitget、Pionex、DigiPlus、NFTscan 和 Chainbase 等加密货币相关企业

· 控制平面 metadb 全量：18 万租户、40 万邮箱、11.5 万明文 API Key

· 客户 SQL：2064 万条 SQL 编辑器/查询语句

· 网关日志：4 年 1.02 亿连接、503 万客户服务器 IP

· 财务/商业资料、37.7 万 Jira 工单、413 个私有代码仓库

云厂商被打成筛子

云数据库资深从业者在事件评论中直接断言几乎所有联网的云服务器和云虚拟机，都可能被打成筛子，因为攻击者现在只需要盯住开源项目的公开 commit log 就能反向分析利用条件，而云厂商的补丁落地存在几周到几个月的 \"致命时间差\"；

同期国际同行也密集爆雷：PaaS 平台 Zeabur 两度被入侵并于 12 月底关停、日本 IDCF Cloud 遭勒索 3.6PB 被加密、Hetzner 控制台遭攻击、Supabase 1.6 万个数据库因配置裸奔。

运营面疏漏高发

某网于2026年5月披露的一起案例与本次事件根因完全同构：某3万+企业客户提供云存储和数据处理服务的服务商，因一名运维工程师把云服务器管理员密钥遗留在了GitHub公开仓库，导致存储数万客户数据、API密钥和业务配置的核心数据库被外部IP频繁访问。

国家网信办于2026年9月发布的典型案例，安徽某数据公司因ES源版本存在未授权访问漏洞、且开发测试完成后未删除测试数据，导致400余份企业内部文件被窃取。

AI漏洞挖掘工业化

PostgreSQL 8 月 13 日一次性披露修复 28 个 CVE，其中 14 个是 CVSS 8.8 的高危 RCE，创历史纪录。

AI的发展让攻击成本断崖式下降，攻击从稀缺资源变工业品裸奔的惩罚被放大：配置错误、泄露密钥从隐患变定时炸弹。

对此你怎么看在评论区发表你的意见吧