9 月 1 日，PingCAP 刚公布完 NCC Group 的源码安全评估：没有严重、高危、中危问题，全是低危。按很多团队的读法，这等于"产品没问题，可以安心把业务放上来"。
可攻击者自称 9 月 8 日——评估公布一周后——就已经在 TiDB Cloud 的控制平面上架好了复制通道：用 PingCAP 自己代码仓库里提交过的 GCP 服务账号密钥和 Azure 服务主体凭据，每 6 小时把控制平面数据库整表导出一次，连续 88 次，直到 9 月 30 日才停。原话很扎心：“Eighty-eight consecutive exports, not one detection event.”知乎
10 月 19 日，自称 FulcrumSec 的组织公开宣称窃取约 10.6TB 数据、放出首批约 200GB，还点名拿到"11.5 万对明文 API Key、约 4.2 万个仍有效"。PingCAP 当天发布安全事件报告：9 月 9 日至 10 月 7 日确有未授权方持"被盗的服务账号凭据"访问内部系统、复制数据并获取源代码；10 月 7 日发现，10 月 14 日封堵全部已识别路径；10 月 20 日建议所有客户轮换 TiDB Cloud 管理 API Key。知乎
注意这个结构：源码审计审的是数据库内核，丢数据的是控制平面和凭据管理。NCC 的评估没造假，但它回答的根本不是这次出事的那个问题。很多团队采购时把"源码审计通过"读成"这家公司安全没问题"，PingCAP 自己在新闻稿里都专门把两者区分开——一个数据库代码再干净，管理员口令写在工单附件里，数据照样出门。
一、这份清单，要分三层读
事件信息乱，媒体转引里混了不少误读。把双方原文对齐后，其实就三层：
厂商承认的：有未授权访问；账号、计费、SQL 编辑器记录、源代码被导出；已向执法机关和监管报案；日本公告给了唯一一个官方量化数字——日本国内最多约 5 万件个人信息。
厂商否认的：产品漏洞（外部机构 10 月 12–13 日报告的 4 个漏洞，10 月 14 日全部修复并复测，但官方至今没说这 4 个漏洞是什么、是否被利用）；客户集群里的业务数据受影响。
只有攻击者单方面声称、未经独立核实的：10.6TB、490 万个文件、413 个私有仓库、37.7 万条 Jira 工单、11.5 万对明文 API Key。知乎上讨论最热的那几个数字，全在这一层。既不该当定论，也不该被"不涉及产品漏洞"一句话带过。知乎
一个能帮你判断真假的分歧点：API Key 到底是不是明文？英文报告说导出的是"加密后的值"，外部机构拿样本测过，不能直接当 Key 用；日本公告说得更细——泄露的只是 Public Key 部分且已加密，Private Key 没被拿走，单凭 Public Key 操作不了 TiDB Cloud。但攻击者称共享加密库用了固定 IV、全平台共用一个密钥，官方对此没有回应。技术上还有个绕不开的点：TiDB Cloud 管理 API 用的是 HTTP Digest 认证，服务端必须保存可还原的私钥，所以私钥天生只能加密存储、不能像密码那样哈希掉。可还原的私钥一旦连加密密钥一起泄露，密文就等于明文。所以结论很实际：在官方说清之前，轮换 API Key 仍是最稳的做法。知乎
二、被传错的四个数字
“18 万客户受影响”：18 万是租户组织数，不是 18 万家企业。里面大量是 AI Agent 和开发者的免费、按需账号——据官方大会口径，半年内 Agent 在 TiDB Cloud 上创建了近 300 万个实例，Manus 一家就用了 150 万个以上集群；攻击者自己披露的付费租户约 8400 个。知乎
“泄露了 2060 万条客户 SQL，你的数据没了”：不矛盾但也别慌。SQL 编辑器记录存在 PingCAP 控制平面一侧，可能含表结构甚至部分语句内容；客户集群里存的业务数据，官方未发现受影响。
“PingCAP 泄露了 GitHub 管理员令牌和 AWS root 密钥”：按攻击者自己的描述，这两项是某个客户贴在支持工单日志里的凭据，不是 PingCAP 的。但这恰恰是真正的警示：客户生产凭据会顺着工单流进供应商系统。TiDB 的 BR 备份工具就存在把凭据写进日志的多条路径（官方 10 月 9 日才提交修复）——脱敏必须在写日志的那行代码里完成，指望不了用户提交前自己删。
“勒索软件攻击”：FulcrumSec 出现于 2025 年 9 月，到年中已声称约二三十个受害者。它不加密系统，只偷数据、靠公开施压，叫"数据勒索"更准。过往案例大多从暴露在外的长期凭据进入，在云环境里一待就是数周到数月。
顺带一提，被点名的客户里 Bitget 已公开回应：只在 TiDB 存过部分公开成交记录，两个多月前已停用，没有用户数据或密码泄露。站勒索方或站厂商都不如站分层：谁说的、有没有第三方证据、官方承不承认，分开装。知乎
三、88 次导出零告警，缺的是三个默认关闭的设置
这条通道为什么像隐形人？因为它用的就是合法凭据、正常接口，流量形态上就是一条正常数据管道。检测不能只盯"是不是坏东西"，还得看"正常的东西有没有变样"——而看得见"变样"的前提是日志开着。
把四家云对照一遍，结论相当不体面：GCP 的 Data Access 审计日志、Azure 资源诊断日志、AWS CloudTrail 数据事件、阿里云操作审计数据事件，默认全部关闭，而且按量计费。PingCAP 自己也是 10 月 10 日才"在受影响项目中启用额外的云存储访问日志"——在那之前，相关访问可能连记录都不完整。知乎
还有两个常见的"以为有"：一是泄露密钥自动处置机制（GCP 自动禁用公开仓库泄露的服务账号密钥、AWS 自动附隔离策略、阿里云检测 GitHub 上的 AccessKey），但它们基本只盯公开仓库，本案凭据据称在私有仓库；二是网络出口围栏（VPC Service Controls、Network Security Perimeter 这类），默认都不生效，要手动配。预算有限时的顺序官方攻略里没写，但很明确：先给控制平面数据库、核心存储桶这类关键资源开日志和告警，再上检测，最后配出口。根本解法则是少用长期密钥：换成 Workload Identity 联邦、托管身份、IAM 角色加 OIDC、RAM 角色加 STS。2024 年 5 月后新建的 GCP 组织已经默认禁止创建服务账号密钥，老组织还得自己去开。
四、三张真实账单：这事跟"没上云"的你也有关
企业事件看着远，API Key 被盗刷这件事，这个月已经在各平台上演了好几出。火绒安全实验室 10 月底披露了一起"AI 攻击实录"：一名站长的服务器运行变慢，排查发现攻击链完全由自动化流程驱动——写入 WebShell、执行命令、GodPotato 提权失败就立刻切换 PrintSpoofer 路线，拿到 SYSTEM 权限后导出凭证、建立 FRP 通道，最后检索的目标之一，就是站点的 PayPal API 配置。知乎
个人这边，B 站晒账单的开发者这个月排成了队：
第一例：10 月 21 日晚上 7 点 17 分，一位开发者的 OpenRouter Key 开始被陌生人调用——12 小时、18 次请求、至少六拨人。 他因为提前开了输入输出日志，才看清对方拿着他的 Key 在干什么；最后账单 1.5 美金，他反而觉得这钱花得值，因为换来了完整取证记录。有人 Gemini 的 Key 泄露被烧掉 396 港元；8 月底 Zeabur 事故里，用户放在项目环境变量里的 API Key 和数据库密码被外泄，一位开发者自己的 OpenAI Key 直接被盗用。还有人看完泄露视频连夜扫了自己的 GitHub，“结果真出事了”。哔哩哔哩
1.5 美金不痛，但它说明盗刷是流水线：一个 Key 挂出去，几个小时内就有六拨人接住。你的 Key 不需要 PingCAP 这么"大"的场子，也会进同一个市场。
而且不止个人会犯这种错。国家互联网应急中心 9 月底通报的"AI 大模型安全众测"里，2467 名白帽子对 25 家 AI 厂商测出 873 个漏洞，其中专门点到一例"API 密钥硬编码泄露"——一把 Key 直接暴露了所有用户共享云平台里 239 个模型的密钥。Cyble 10 月 22 日的报告扫了 130 万多个新注册域名，识别出 22306 个 AI 搭站工具生成的站点，其中 35 个站把私钥塞进了浏览器，有 5 个站共 16 把还能用的 OpenAI Key 躺在 JS 文件里。硬编码、塞前端、贴工单，凭据外流的姿势五花八门，但共同点是：写出去的那一刻，它就不只属于你了。知乎知乎
五、今晚就能做的 30 分钟自查
只调用 AI API 的个人/学生：① 把 DeepSeek、OpenAI、Gemini、OpenRouter 各平台后台过一遍，陌生 Key 全删；② 能给单把 Key 设消费上限的一定设（设不了就把账户余额压到只够用一周）；③ 检查所有公开仓库和网页粘贴记录里有没有 `sk-`、`AIza`、`ghp_` 这类字符串，GitHub 的 Secret Scanning 对公开仓库免费。④ 学那个 1.5 美金的同学：把请求日志开起来，出事你能看见。
独立开发者/带项目的：无论是轮换还是新建，先记住一个通用规则——密钥的私钥值通常只在创建那一刻完整显示一次，当场存进密码管理器，别截图发进群聊，更别写进仓库。
① 用 `gitleaks` 或 `trufflehog` 把整个仓库历史（不只是当前 HEAD）扫一遍——提交进历史里的密钥，删掉文件也没用；② 私有仓库推送拦截需要付费的 Secret Protection，按团队情况权衡，但历史扫描这一步免费；③ 环境变量的 .env 确认永远在 .gitignore 里；④ 凡是发给任何厂商工单、排障群、网盘的日志，先过一遍脱敏——本案最便宜的教训就是这个。
如果你跑着服务器或站点：本地安全软件全盘查杀一遍，命中驻留后门、提权工具的，处理完文件还不够，把机器上经手的凭据全部视为已泄露、挨个轮换——火绒那起"AI 攻击实录"里，攻击者正是顺着失陷主机一路摸到了 PayPal 的 API 配置。
用了 TiDB Cloud 的团队：照官方 10 月 20 日的动作来——立即轮换管理 API Key，接下来几周对"像 PingCAP 口吻"的定向钓鱼提高警惕；同时自查有没有工程师（或你自己）把连接串、口令贴进过工单附件。
六、接下来盯什么
PingCAP 至今没交代入口凭据的来源、4 个漏洞是什么、是否被利用——这三项什么时候补，能检验这份报告的成色；
攻击者称"固定 IV、全平台共用密钥"官方一直没有回应，如果坐实，"加密存储"这个说法要重新评估；
同行已经接招：据报道 Supabase 从 10 月 30 日起新建表默认不再对外公开、要显式授权。 Google 9 月底发布 AlloyDB for agents 预览，宣传点直接写着"No static passwords"。控制平面怎么防，正在从厂商的自觉变成你选型 Agent 数据库时该问出口的问题。知乎
源码审计过了 ≠ 这家公司安全没问题；日志没开 ≠ 没在丢数据。这两句话，是 PingCAP 用 88 次导出替所有人交的学费——而你的 30 分钟自查，今晚就能做。
