突发,国内某大型数据库云服务厂商10.6TB数据因勒索攻击被泄漏!"

admin 2026-10-22 12:07:16 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

突发,国内某大型数据库云服务厂商 10.6TB 数据因勒索攻击被泄漏!

原创

mmc
mmc

AGI安全

2026年10月21日 01:02
北京

去阅读

突发,国内某大型数据库云服务厂商 10.6TB 数据因勒索攻击被泄漏!

2026 年 10 月 20 日,勒索/披露组织 FulcrumSec 公开宣称:已从 PingCAP 旗下托管数据库服务 TiDB Cloud 持续窃取约 10.6 TB 数据,并放出约 200GB 的第一阶段样本。同日,PingCAP 发布情况说明,承认「部分内部经营数据」遭未授权访问,但强调不涉及产品漏洞,也不会影响客户数据库与业务数据安全。

代码库中的云凭证 → 访问控制面与云存储 → 近两个月持续导出 → 公开披露① 入口:云凭证攻击方称使用代码库中GCP / Azure 服务账号搭建控制面复制管道让基础设施替他们导出官方未确认入口细节② 横向:多云资产控制面 · BigQueryGCP 桶 · AWS 账单Jira · CRM · 私有源码网关四年连接日志攻击方自称覆盖面③ 持续外泄近两个月持续导出末 22 天每 6 小时导出自称 88 次无人察觉最后一次 9/30 06:02 UTC累计约 10.6TB④ 公开披露放出约 200GB 样本点名多家客户租户官方同日发声明口径:内部经营数据客户侧陆续回应托管安全还取决于控制面、云账号和内部系统,不只取决于数据库产品本身本图为攻击方叙述的链路示意,入口与覆盖范围均未经第三方独立核验依据 FulcrumSec 披露页与 PingCAP 2026-10-20 公告整理

事件概况

PingCAP(平凯星辰)是开源分布式数据库 TiDB 的主要商业化公司。TiDB Cloud 是其托管版本:银行、游戏、电商等客户把生产库交给 PingCAP,在多租户平台上运维。

10 月 20 日,FulcrumSec 在其站点发文,声称掌握了 TiDB Cloud 的控制面、账单与财务数据、GCP 存储与 AWS 成本数据、Jira、CRM、分析仓库、私有源码,以及四年的网关连接日志。同日,深潮 TechFlow 等媒体跟进;加密交易所 Bitget 等被点名客户陆续做出澄清。

项目 内容
披露方 FulcrumSec(勒索/公开披露模式)
目标 PingCAP / TiDB Cloud 及相关内部系统
攻击方声称体量 约 10.6 TB · 约 490 万文件 · 首期公开约 200GB
攻击方声称窗口 近两个月持续外泄;末 22 天(9/8–9/30)每 6 小时导出控制面,共 88 次
官方确认(10/20) 部分内部经营数据遭未授权访问;已采取处置;称不影响客户库与业务数据
独立核验 截至本稿整理时,尚未完成公开的第三方独立核验

下面的数字和类别来自攻击方自述,不是 PingCAP 的确认清单。官方只承认部分销售线索、订单和需求单等内部经营信息受影响。双方的差异不只是数量,还包括控制面、客户密钥、SQL 和源码是否泄露。在样本被独立核验之前,不能写成「10.6TB 客户数据已被证实全部带走」。

官方声明 vs 攻击方主张

PingCAP 公告说明(2026-10-20)

平凯星辰在安全更新页发布《网络安全事件情况说明公告》,核心三点:

  1. 已采取必要防护与风险处置,消除相关风险;
    2. 不涉及平凯数据库(TiDB 企业版)、平凯数据库云服务、TiDB 社区版等产品的安全漏洞和缺陷,不会对客户数据库系统和业务数据安全造成影响;
  2. 受影响的是部分销售线索及订单记录(含部分公开招投标信息),以及部分需求单(如 SQL 优化器改进一类通用技术描述)。

FulcrumSec 勒索组织放出的声明

攻击方的说法不同。他们声称拿到的不只是销售线索,还包括控制面元数据库、客户控制台 API 明文密钥、SQL Editor / Chat2Query 中的客户 SQL、四年网关连接日志、413 个私有仓库、Jira 全量、CRM、财务与成本明细,并列出 Booking.com、Shopee、CAPCOM、PayPay、Bitget、Pionex、百度等租户对应关系。他们还称:用代码库中的云凭证建立复制任务后,控制面每 6 小时自动导出一次,22 天共 88 次,没有检测记录。

如果官方说法成立,受影响的主要是内部经营信息。如果攻击方样本经核验后大体属实,则供应商的控制面、身份系统和工单已被访问;客户即使没有产品漏洞,相关密钥和日志也可能外泄。接下来需要看的是样本核验结果,而不是标题里的数字。

攻击方声称拿走了什么

以下类别与数字均来自 FulcrumSec 披露页,不是官方确认清单。列出这些内容,是为了说明控制面和后台系统一旦被访问,可能同时涉及哪些数据。

类别 攻击方宣称内容(摘要)
控制面 metadb 约 18 万租户组织、约 29 万用户、约 40 万邮箱;Serverless / Dedicated 集群清单;约 11.5 万控制台 API 密钥对(称约 4.3 万仍有效)
客户 SQL 约 2060 万条来自 SQL Editor / Chat2Query 的原始语句,按组织、项目、集群 ID 关联
网关日志 四年约 1.02 亿次连接、约 500 万客户侧 IP、客户端指纹(Rails / ProxySQL / Workbench 等)
财务与成本 带租户标签的 AWS CUR、Stripe / HubSpot / NetSuite / Marketplace 等商业数据
源码与工单 413 个私有仓库全历史;约 37.7 万条 Jira;称支持工单中长期粘贴客户生产密钥
身份图谱 GA4 / Mixpanel / 外购开发者情报图,可把匿名分析 ID 回连到邮箱与雇主租户

控制面数据和业务库数据的差别

对多租户数据库云来说,风险不只是某张业务表被读出,还包括:谁能创建集群、谁持有 API Key、迁移任务是否保存了客户侧 MySQL/Aurora 的管理员账号、VPC 对等连到了哪些云账号。攻击方称,网关日志和租户映射可以用来定位客户;如果这些记录外泄,后续针对客户的访问会更容易。

攻击方还引用了一张据称来自 2022 年 8 月的内部安全工单(SECURITY-22):组织内包括计费管理员在内的角色,可无条件重置该组织下所有集群的 root 密码。这是攻击方的引用,官方尚未确认是否属实、是否已修复,以及是否与本次事件有关。

客户侧怎么回应

被点名不等于业务库已被读取。目前公开回应最完整的是 Bitget:大中华区负责人谢家印表示,经排查,Bitget 曾在 TiDB Cloud 存放的是公开成交日志(成交频道本就对所有用户可见),并已于两个多月前停止使用;事件不涉及用户数据或密码等敏感信息。CryptoBriefing 等报道认为,这是托管服务商侧的问题,不是交易所自身系统被直接入侵。

攻击方名单里还出现 Booking.com、Shopee、CAPCOM、PayPay、Pionex、DigiPlus、NFTscan、Chainbase、百度等名称。除 Bitget 外,多数公司在本稿整理时尚未发布同样详细的公开说明。仍在使用 TiDB Cloud 的客户,可以先做密钥轮换、访问日志审计,并检查支持渠道里是否留有凭据,不必等公开辟谣。

给普通用户的提醒。若你只是某家交易所或 App 的终端用户,优先警惕「借此事钓鱼」的短信与邮件。任何让你提交助记词、二次验证码、冷钱包地址的「安全核实」,默认当作骗局。是否真的有你的业务数据在泄露包里,要等你所使用产品的官方说明,而不是攻击方的点名列表。

公开时间线

时间 事件
约 2026 年 8–9 月 攻击方自称近两个月持续外泄;初期约 8TB,之后定期补充导出
2026-09-08 ~ 09-30 自称控制面每 6 小时导出一次,共 88 次;最后一次 09-30 06:02 UTC
2026-10-20 FulcrumSec 公开发布;PingCAP 同日发情况说明;Bitget 等客户回应
后续(待观察) 样本独立核验、官方影响评估更新、其他被点名客户是否发声

如果「88 次导出均未被发现」属实,问题就不只是入侵入口,还包括控制面和对象存储缺少异常导出告警。终端检测(EDR)不能替代对合法服务账号大批量导出的监控。

如果你是 TiDB Cloud / 同类托管库客户

  1. 先轮换凭据

在官方评估和第三方核验完成前,按控制台凭据可能已暴露处理:轮换 TiDB Cloud 控制台 API Key、集群连接凭据、迁移任务中的外部库账号,以及曾经写进工单和聊天记录的临时密钥。

  1. 检查支持工单中的凭据

攻击方称,工程师为排障把生产密钥、连接串和预签名 URL 写进了 Jira。无论这次样本最终核验结果如何,厂商和客户都应检查:排障材料是否默认脱敏,密钥是否通过一次性通道传递并及时作废。

  1. 检查网关日志外泄后的暴露面

如果网关访问日志确实外泄,其中会有应用服务器 IP、客户端程序、连接量和集群 ID。应结合对外暴露面检查异常登录和扫描;对来源未知、但能准确指向集群标识的探测流量提高优先级。

  1. 把托管方的后台系统纳入安全评审

使用托管数据库减少的是自行运维。供应商的控制面、对象存储、工单系统、源码仓库、财务和 CRM 仍在访问范围内。安全评审除了看数据库产品有没有已知漏洞,还应确认:云凭证是否进入私有仓库,大批量导出是否有告警,支持系统是否强制脱敏,客户密钥是哈希存储还是可逆加密、加密密钥是否全局共用。

最后

攻击方称数据量约 10.6TB,官方称受影响的是内部经营信息,并称不影响客户数据库和业务数据。控制面与客户密钥是否外泄,官方尚未确认。样本完成核验前,两边都不能当作最终结论。无论数字最终如何,有三件事需要确认:

第一,如果控制面每 6 小时导出一次且没有告警,说明导出监控没有覆盖这条路径。

第二,支持工单、私有仓库、CRM 和账单不在数据库产品本身的范围内,但一次供应商入侵可能同时涉及这些系统。

第三,把生产交给托管方之后,密钥轮换、日志审计和工单脱敏由谁负责,合同里是否写清;事件发生后,是否先轮换凭据,再等待公开结论。后续我们会继续跟踪样本核验与官方更新,并分享云控制面安全、SaaS 供应链与企业数据外泄检测的实践经验,欢迎收藏转发!

AGI 安全 · 企业 AI 安全专项培训

针对云供应链、数据外泄检测、智能体攻防与企业安全体系建设

我们提供完整的企业 AI 安全培训体系,助力企业建立完整的安全防护能力

大模型安全 智能体安全
AI 合规审计 组件供应链安全
数据安全 云控制面安全
企业安全体系搭建

如需定制企业内部安全培训、对外系统与云供应链风险评估,欢迎扫码咨询

联系人:马老师 | 微信:AICodingC | 公众号:AGI安全

参考资料

FulcrumSec:The PingCAP / TiDB Cloud Leaks

PingCAP / 平凯星辰:网络安全事件情况说明公告(2026 年 10 月 20 日)

深潮 TechFlow:PingCAP database and customer data suspected stolen(2026-10-20) | Bitget 回应专访

CryptoBriefing:Bitget says no user data exposed in alleged TiDB Cloud breach

    第三届TCH,第60名,以及最近对Agent的一点想法" 网络安全文章

    第三届TCH,第60名,以及最近对Agent的一点想法"

    作者分享第三届腾讯云TCH比赛获第60名的经历,使用DeepSeekFlash消耗近3亿Token。文章核心观点是Agent架构已不重要,简单脚手架加基础工具即可,应遵循AIFirst、ToolsFirst理念,从万能Agent转向多个专业系统,让专业工具做确定性工作,Agent专注需理解分析的任务。工具决定Agent探索世界的边界。
    某医院互联网医院平台存在弱口令" 网络安全文章

    某医院互联网医院平台存在弱口令"

    文档披露某医院互联网医院平台存在弱口令漏洞,作者通过默认账号密码成功登录系统,并测试了预约上传点及个人信息修改功能,但上传点有云存储拦截且参数控制严格,未能深入利用。文章提示医疗系统需加强账号安全防护,建议启用强密码策略与多因素认证。
    评论:0   参与:  0