• BrbiwsFtd9zDGZqB

    原文: https://fulcrumsec.vg/pingcap/

    摘要:

    - 累计外泄数据:10.6 TB

    - 文件数量:4,901,203 个

    - 生产控制平面导出:连续 88 次(每 6 小时导出一次),全程未被检测/察觉

    - GCP 存储桶:约 50 个

    - BigQuery 数据仓库:单仓数据量达 5.338 亿行

    - 租户组织:180,046 个

    - 独立电子邮箱:403,262 个

    - 客户明文 API 密钥:115,308 个(其中 42,612 个处于有效/活跃状态)

    - 客户 SQL 语句:20,645,574 条

    - 网关连接记录:102,003,766 次

    - 客户服务器 IP:5,036,738 个

    - Jira 工单 (Issues):377,446 个

    - CRM 联系人:433,928 个

    - 带租户标签的 AWS 成本数据:92 GB

    - 私有源码仓库:413 个

    主楼
  • DT37

    今天这是怎么了,到处都是爆炸的东西

    #1
  • putaozhenhaochi

    这不得赔破产

    #2
  • BrbiwsFtd9zDGZqB

    @putaozhenhaochi 难说

    https://www.pingcap.com/trust-hub/security/security-update-october-2026/

    一家外部事件响应公司审查了 PingCAP 的生产系统,未发现攻击者在被审查的系统中运行命令或保持持久访问权限的证据.

    在外部律师和第三方取证专家的支持下,没有证据表明存储在 TiDB 中的数据受到影响

    #3
  • Hozzz

    漏的主要是 tidb 内部经营数据,数据库本身及客户的数据库不受影响

    #4
  • utodea

    "We even stood up a replication feed of their own control-plane database using credentials committed in their own repositories — GCP service-account keys and an Azure service principal — and let their infrastructure deliver it to us. Every six hours, for the last twenty-two days of the campaign... that pipeline faithfully re-exported every table of the operational heart of TiDB Cloud — tenants, users, API keys, cluster credentials... Eighty-eight consecutive exports, not one detection event."

    这写得还挺嚣张的... 或许大家真的需要类似 https://keyrotate.sh 的产品主要去发现环境、系统、仓库里都有哪些 api key 、秘钥,然后周期性自动地去轮换、失效它们。 这应该不是个例,在 AI 时代,感觉会一直上演。

    #5

发表回复

登录后回复