数据泄漏预警 | FulcrumSec声称窃取PingCAP TiDB Cloud 10.6TB数据：涉及18万租户组织、42万邮箱及多家知名企业

众智维安

2026年10月22日 18:17
江苏

去阅读

事件概述

2026年10月，一个自称为FulcrumSec的实体在其泄漏发布站点架设专题页面（“THE LEAKS”），声称已完成对PingCAP Inc.（TiDB Cloud） 云环境的大规模数据窃取，总量10.6TB、约490万个文件，并已开始分阶段公开发布第一阶段样本（多个tar.gz分卷，合计约128.3GiB）。

按照其声明，泄漏数据并非单点失陷的结果，而是通过滥用PingCAP自有代码仓库中遗留的GCP服务账号密钥与Azure服务主体凭据，在受害者云环境中搭建了一条每6小时执行一次、持续近两个月、累计88次导出且自称“无一次触发检测”的控制面数据库复制管道，最终拖走了控制面元数据库、客户SQL语句、网关访问日志、成本财务数据、商业CRM数据、身份关联图谱及413个私有代码仓库。

页面还点名展示了多家知名企业与租户ID的对应关系（Booking.com、Shopee、CAPCOM、Colopl、TOPPAN等），声称42个组织的完整表与94条计费字典中还包含Mercari、PayPay、Fujitsu、SoftBank、DMM、AEON、Square Enix、Konami、BANDAI NAMCO等企业，并单独列出含中国银行、科技部、中国人寿等机构的中国区账本（12,262行、约¥3.531亿）。

以上全部内容均来自攻击者自述，真实性、完整性、时效性均待核实。 但考虑到其声称的凭据类数据（11.5万对控制台API密钥、客户外部数据库root/admin凭据、支持工单历史凭据）一旦属实即构成现实可利用风险，建议相关方按“真实事件”先行开展低成本自查。

图：泄漏站声明页面

攻击者声称的事件经过

时间线（攻击者自述）

声称的手法

攻击者声称使用了PingCAP自己的仓库中提交（commit）过的GCP服务账号密钥和Azure服务主体凭据，直接在受害云环境内建立控制面数据库（metadb）的复制导出管道——即攻击路径的核心不是打穿边界，而是复用受害方自己泄漏到代码库里的云凭据，以“合法”身份从内部持续搬运数据。

页面同时将PingCAP支持体系描述为“跨租户披露引擎”，声称工程师长期将客户生产凭据直接粘贴进Jira支持工单，包括：

• 工单评论中出现可用于列举客户S3日志桶的AWS密钥对；
• 备份配置附件中的IAM凭据，声称对258个不属于PingCAP的存储桶具有管理员级权限；
• 一份314MB 的客户生产慢查询日志附件，声称内含约8,027个不同凭据值：大量AWS STS会话密钥、GitHub token、覆盖OpenAI/Anthropic/Gemini 等平台的API key、一对AWS root 密钥，以及一个对1,701个仓库（843个私有）具有24项管理权限的GitHub PAT；
• 另一工单含1,825条内嵌用户名密码的生产数据库连接字符串；
• 同一支持工程师在约两年内发布38个指向客户自有存储桶的预签名S3 URL。

页面还附有威胁性表述，称其中两家被泄出管理员凭据的公司“很快就会收到我们的消息”（they will be hearing from us soon），带有典型的事后勒索倾向。

声称的泄漏数据规模

图：泄漏站声明页面

已发布内容（第一阶段）

页面以分卷压缩包+种子链接的形式发布第一阶段样本（合计约128.3GiB），主题分别为：按租户归因的AWS成本数据（70.6GiB）、BigQuery分析资产全量（31.5GiB）、私有代码仓库（17.2GiB）、网关日志（6.9GiB）、杂项精选合集（2.1GiB，含SECURITY/HR工单、生产配置、含凭据的支持日志、客户商业簿、全部约37.7万条Jira工单、财务快照等）。

⚠️ 本预警不提供、不转载任何下载地址、种子链接或联系方式。请各单位禁止从该站点下载任何数据包（既是法律风险，也可能捆绑恶意载荷）。

攻击者画像与可信度评估

画像：FulcrumSec采用“展示证据+分阶段放包+遮蔽邮箱联络”的典型泄漏站运营模式，兼具数据窃取炫耀、勒索与流量变现动机。其页面文字带有明显的嘲讽与羞辱性叙事（如反复反问\"A database company\"），风格上更接近泄露主义（leakivism）型行为者，而非传统以赎金为唯一目的的勒索组织。

可信度评估（初步）：

倾向于“至少掌握了部分真实数据”的信号

数据颗粒度异常具体（精确到美分的成本数字、工单编号SECURITY-22/GTOC-5812/APID-11182/TCID-2287等、精确的租户ID与时间戳），这类细节通常难以凭空伪造；声明的时间结构（8TB初始+两个月补货+88次导出）符合自动化拖库的行为模式。

存疑与需警惕的信号

01 10.6TB的数字与2024年初公开披露的旧事件高度重合——当时有独立研究者声称可从TiDB Cloud serverless层跨租户访问约10.6TB数据，并引发赏金金额争议。本次数字完全复用，存在三种可能：巧合、攻击者刻意借用旧披露数字抬高可信度、或双方确有关联。此点需重点核实。

02全部“涉事企业名单”均为攻击者单方面指认，未经任何一方证实，不宜直接采信或传播为事实。

03声称“88次导出无一检测”自述成分高，无法独立验证。

综合判断

按“部分真实、部分夸大”假设开展应对是最稳健的基线；凭据类风险（API 密钥、工单历史凭据）无论声明真伪都应立即处置。

风险分析

凭据级风险（最紧迫、可直接利用）

声称42,612对控制台API密钥发布时仍有效；迁移任务配置中的客户外部数据库root/admin凭据直指客户自有生产库；支持工单中沉淀的AWS /GitHub/AI平台凭据如被批量利用，可形成跨企业的连锁失陷。

数据级风险

客户SQL语句与网关日志组合，可还原客户数据库的表结构、业务语义、连接源IP与账号命名规范，为后续定向入侵提供“目标地图”。

商业与合规风险

客户名单、合同金额、逐客户毛利率、中国区账本一旦属实，涉及商业秘密泄露；医疗、政务、金融类数据涉及《数据安全法》《个人信息保护法》及境外对应法规（GDPR等）下的通报义务。

人的风险

40余万邮箱+真实姓名+公司+职位与购买倾向图谱，是高质量定向钓鱼/BEC（商务邮件欺诈）的完美弹药库，预计未来数周针对相关企业员工的精准钓鱼将上升。

产品供应链风险

私有仓库（含共享加密库、计费引擎、账号服务）公开，意味着针对TiDB Cloud/TiDB产品本身的新漏洞挖掘可能加速；叠加2022年即被内部记录的多租户隔离缺陷叙事，DBaaS多租户隔离信任模型受到正面冲击。

二次传播风险

第一阶段样本已公开分发，数据将不可避免地扩散至更多（包括恶意）第三方，泄漏影响将长期化，而非随事件热度消退。

排查与处置建议

TiDB Cloud现任/历史客户（最高优先级）

01立即轮换TiDB Cloud控制台API密钥（组织级与个人级全部轮换，不做豁免），并在审计日志中回溯近90天API密钥的异常调用；

02轮换所有曾配置在TiDB Cloud数据迁移/同步任务中的外部数据库凭据（尤其MySQL/Aurora的root、admin类账号）；

03收紧集群网络访问白名单，对网关日志中记录的连接源IP进行基线核对，排查2026-08以来（按声称时间线）的异常连接与异常SQL；

04若曾通过SQL Editor/Chat2Query执行过高敏查询，评估相应业务数据的暴露面与合规通报义务。

曾向PingCAP提交过支持工单的组织

将历史上提交到工单中的任何凭据一律视为已泄漏，逐项处置：

• AWS：在IAM中禁用/轮换相关访问密钥，用CloudTrail回溯其调用记录；重点排查STS会话与疑似root凭据的使用；
• GitHub：审计组织审计日志，撤销所有可疑PAT/token，检查近90天对私有仓库的异常克隆；
• AI平台（OpenAI/Anthropic/Gemini等）：轮换API key，核对账单与用量异常；
• 生产数据库连接串：全部改密，并审查来源IP白名单。

一般企业（无论是否为TiDB客户）

01面向数据库/云平台管理岗位开展定向钓鱼提示；高管层加强BEC防范；

02关注数据是否出现自身业务标识（邮箱、域名、租户ID），必要时启动暗网/渠道监测服务。

对PingCAP的期待动作（供客户侧持续关注）

官方确认或否认事件；强制全量客户凭据轮换与通报；对代码仓库中提交过的云密钥进行历史使用审计；委托第三方取证；按适用法规履行监管通报与客户通知义务。

后续跟踪计划

• 重点核实：10.6TB数字与2024年旧披露的关系、涉事企业名单真实性、声称工单编号的真实性（可通过工单系统公开索引比对）；
• 如有官方确认或权威信源证实/证伪，本预警将升级为正式事件通告并同步修订IOC与建议。

应对支持：排查指导专家Agent已上线

为帮助客户高效完成本次事件的排查与处置，我们已在御知智能体平台中上线针对本事件的排查指导专家Agent，将本预警中的排查与处置建议封装为可交互、可留痕的排查流程。该Agent可协助您完成：

影响范围快速评估

根据您对TiDB Cloud的实际使用情况（使用的版本与时段、是否配置过数据迁移/同步任务、是否提交过支持工单、是否使用过SQL Editor/Chat2Query），逐项判定适用的处置级别，输出个性化的排查清单；

凭据处置操作指引

按处置优先级逐步指导完成TiDB Cloud控制台API密钥轮换、迁移任务外部数据库凭据轮换，以及AWS/GitHub/AI平台等工单历史凭据的回溯与撤销；

审计回溯辅助

围绕声称的入侵时间窗（2026-08起）生成数据库与云平台侧的日志排查要点及检索特征（异常源IP、异常时段连接、root账号使用、权限变更、批量导出行为等），辅助完成回溯取证；

钓鱼风险应对

结合声称泄漏的身份信息图谱，生成面向DBA、IT、财务等岗位的定向钓鱼防范提示，识别冒充PingCAP的“紧急轮换密钥”类钓鱼话术；

处置留痕与报告输出

自动汇总排查过程与处置结果，形成可供内部留档、合规通报与监管沟通使用的排查报告。

Agent的知识库将随事件进展（官方回应、独立验证结论、新的泄漏证据）持续更新，确保排查口径与本预警的修订保持同步。

图：泄漏站声明页面

信息来源与免责声明

• 交叉验证：截至2026-10-21，未检索到PingCAP官方回应及主流媒体独立报道（公开搜索引擎可见结果中无相关内容，部分结果可能因合规原因被过滤）；
• 背景参考：2024年曾有独立研究者针对TiDB Cloud serverless层多租户隔离缺陷进行公开披露并引发赏金争议（细节待进一步核实）；
• 免责声明：本文为预警性质的技术通报，所有涉事企业与数据规模均为攻击者声称，不代表已证事实；文中不包含任何可获取泄漏数据的链接或凭据信息。相关企业名单的传播请附加“未经证实”限定，避免对无辜第三方造成声誉损害。

我们时刻关注客户需求，为您提供最新漏洞信息。如果您想了解更详细的支持信息，可联系下方邮箱或者电话进行咨询！

[email protected]

400-0133-123