PingCAP不正アクセス｜TiDB CloudのメールアドレスとSQLエディタの入力が流出、利用者がやること

PingCAP は2026年10月、「Security Update」で、権限のない第三者が盗まれたサービスアカウントの認証情報を使い、9月9日から10月7日まで一部の内部システムに入っていたと発表しました。データのコピーとソースコードの取得があり、持ち出された記録には TiDB Cloud のユーザー名・メールアドレスと SQL エディタのテキストが含まれます。発表の前日には、恐喝グループ FulcrumSec がリークサイトに約10.6TB を持ち出したと載せていました。本記事は PingCAP の発表と攻撃者の主張を分け、TiDB Cloud の利用者がやることを整理します。

事案の読み方とほかのインシデントは サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にまとめています。

PingCAP 不正アクセスの時系列

侵入が始まってからリークサイトに載るまで約6週間、PingCAP が把握してからも約2週間あります。その間に外へ出た鍵やパスワードは、利用者が替えるまで有効なままです。

PingCAP の発表で分かった TiDB Cloud の流出範囲

サービスアカウントは、人ではなくシステム同士の処理に使うアカウントです。PingCAP はその認証情報が盗まれたと書いていますが、どう盗まれたかは発表から確かめられません。外部のインシデント対応会社は本番システムを調べ、調べた範囲では攻撃者がコマンドを実行した形跡も、アクセスを保ち続けた形跡も無かったとしています。発表は、この結果が持ち出されたデータの範囲を変えるものではないとも書いています。

PingCAP Japan は X で「TiDB Cloud への不正アクセス、クレジットカード情報の流出は確認されておりません」と書いています。入られたのは PingCAP の内部システムで、そこにあった TiDB Cloud の記録が持ち出された、という英語の発表と合わせて読む必要があります。SQL エディタのテキストは、利用者が自分で打った文そのものです。そこにパスワードや鍵を書いていれば、TiDB のデータとは別の経路で出たことになります。

PingCAP の発表と FulcrumSec の主張はどこが違うか

攻撃者の数字は、リークサイトの記載を伝えた報道と Hackmanac の投稿によります。本記事はリークサイトへのリンクを載せません。FulcrumSec はクラウドの設定と鍵の管理の甘さを狙う恐喝グループとして Sysdig や MOXFIVE が分析していて、交渉の圧力のために規模を大きく見せることもあります。

主張には利用企業の名前も並んでいますが、本記事は一覧を載せません。声明を出した当事者として、暗号資産取引所の Bitget は10月20日、同社が TiDB Cloud に置いたのは公開している取引の記録だけで、2か月以上前に使うのをやめており、利用者のデータは出ていないと説明しました。名前が挙がったことは、その企業のデータが出たことを示しません。主張が先に広まった段階の読み方は メルカリ情報漏洩の主張｜2,400万件のデータ販売は未確認、分かっていることと利用者の備え でも扱いました。

TiDB Cloud の利用者がとる対策

以下は当サイトの推奨で、PingCAP の発表が示した手順ではありません。PingCAP から個別の連絡が来たら、そちらを優先してください。

SQL エディタと Chat2Query に書いた文を見直す

SQL Editor の SQL Files タブで、保存したファイルを順に開きます。SQL Editor は AWS 上の Starter で使え、Dedicated ではサポートに頼んで使う機能です。使ったことが無ければ、この項は飛ばしてかまいません。

・CREATE USER … IDENTIFIED BY '…' と ALTER USER … IDENTIFIED BY '…'、SET PASSWORD
・接続文字列、ほかのサービスの API キーやトークンを値に入れた INSERT・UPDATE
・顧客の氏名・メールアドレスなどの個人情報を条件や値に書いた文
・Chat2Query に打った質問文（表の名前や業務の内容が入っていることがある）

見つけたら、そのパスワードや鍵を差し替えます。ファイルを消しても、持ち出された写しは消えません。個人情報が入っていた場合は、自社の個人情報の担当に伝えてください。SQL Files に何も無くても、書いていないとは限りません。発表が言う「テキストとエラー」が保存したファイルと同じものかは分かっていないので、打った覚えがあるパスワードは替えておきます。

鍵・パスワード・接続元・記録

アクセスキー漏洩を防ぐ｜開発用クラウドの長期キーをやめ、漏れても使えず気づける形にする手順と、漏れた最初の1時間 で扱ったとおり、鍵を替えたら古い鍵が本当に使えなくなったかまで確かめて、作業は終わりです。

手元のリポジトリとメモに残った接続情報と SQL を探す

SQL エディタに貼った文は、手元のリポジトリやメモから写したものかもしれません。次の2つは値を表示せず、ファイル名とコミットだけを出します。1つ目は TiDB Cloud のホスト名とパスワード入りの接続文字列、2つ目はパスワードを書いた SQL を探します。

git fetch --all --prune
# 追跡中のファイルで TiDB Cloud のホスト名を含むものを、ファイル名だけ出す
git grep -l -I -E 'tidbcloud\.com'
# パスワード入りの接続文字列（mysql://ユーザー:パスワード@…tidbcloud.com）を含むファイル
git grep -l -I -E 'mysql://[^:/@ ]+:[^@ ]+@[^ ]*tidbcloud\.com'
# 過去のコミットに入ったことがあるか（消したファイルも含む。値は出さず、コミットとファイル名だけ）
git log --all -G 'tidbcloud\.com' --format='%h %ad %s' --date=short --name-only
# Git で追跡していないファイル（.env など）も含めて、作業ディレクトリを探す
grep -rlI --exclude-dir=.git -E 'tidbcloud\.com' .

git fetch --all --prune
# パスワードを書いた SQL（IDENTIFIED BY '…'・SET PASSWORD）を含む追跡中のファイル名だけ出す
git grep -l -I -i -E "identified( with [a-z_]+)? by ['\"]|set password"
# 過去のコミットに入ったことがあるか（消したファイルも含む。値は出さず、コミットとファイル名だけ）
git log --all -i -G "identified( with [a-z_]+)? by ['\"]|set password" --format='%h %ad %s' --date=short --name-only
# Git で追跡していない書き出しやメモ（.sql・.md など）も含めて、作業ディレクトリを探す
grep -rliI --exclude-dir=.git -E "identified( with [a-z_]+)? by ['\"]|set password" .

ダミーのリポジトリで、追跡中のファイル・削除済みのコミット・追跡外のファイルに置いた接続文字列と CREATE USER … IDENTIFIED BY・IDENTIFIED WITH … BY・SET PASSWORD がそれぞれ出ること、パスワードを含まない CREATE USER と説明文の「identified by」が出ないこと、関係の無いリポジトリでは何も出ないことを確かめています。

何も出なくても、パスワードが漏れていないとは限らない点に注意してください。見ているのはこのリポジトリと作業ディレクトリだけで、SQL エディタの中身、チャット、ほかのリポジトリ、端末の履歴は見ていません。SET PASSWORD は説明文にも当たるので、出たファイルは中を見て判断します。秘密情報全般を探すには、シークレットスキャンの入れ方｜gitleaksをコミット前・プッシュ時・CIの3層に組み込み誤検知を絞る の gitleaks を使ってください。

監査ログで普段と違う接続元を数える

DB 監査ログには接続元の IP（CLIENT_IP）が記録されます。公式ドキュメントは項目を列挙するだけで、1行の書式までは示していません。次のコマンドは CLIENT_IP=…・CLIENT_IP="…"・"CLIENT_IP":"…" のどの形でも IPv4 を拾うように書いた例です。先に head -n 3 でログの形を見て、合わなければ正規表現を直してください。

# 監査ログを置いたディレクトリ（例: ./audit-logs）で、接続元IPごとの件数を多い順に出す
grep -rhoE 'CLIENT_IP[^0-9]{1,4}[0-9.]+' ./audit-logs | grep -oE '[0-9.]+$' | sort | uniq -c | sort -rn
# 許可している接続元の一覧（allowed_ips.txt、1行に1つ）に無いIPだけを出す
grep -rhoE 'CLIENT_IP[^0-9]{1,4}[0-9.]+' ./audit-logs | grep -oE '[0-9.]+$' | awk 'NR==FNR {ok[$1]=1; next} !($1 in ok) {n[$1]++} END {for (ip in n) print n[ip], ip}' allowed_ips.txt - | sort -rn

3つの書式を混ぜたダミーのログで、一覧に無い2つの IP だけが2つ目に出ること、許可済みの IP だけのログでは何も出ないことを確かめています。allowed_ips.txt は IP を1つずつ書く形で、CIDR の範囲は扱いません。

一覧に無い IP が出ても、それだけでは侵入とは判断できません。新しい CI のランナーや在宅の接続かもしれません。何も出なくても安全とは言えず、監査ログを有効にする前の接続は残っていません。AWS PrivateLink 経由の接続はロードバランサーの IP が記録される場合もあります。説明のつかない接続があれば PingCAP のサポートに相談します。

セルフホストの TiDB と影響範囲

TiDB 本体は Apache 2.0 の OSS で、自分のサーバーで動かす TiDB のデータは PingCAP のクラウドにはありません。気にかけておく点はソースコードの取得です。公開リポジトリの中身が出ても新しい弱点にはなりませんが、非公開の部分が含まれていた場合は、そこから脆弱性が見つかる可能性が残ります。PingCAP の Security Vulnerabilities のページと、GitHub の pingcap/tidb の Security タブ（SECURITY.md とアドバイザリ）を見ておけば、修正が出たときに気づけます。

続報では次の点を見ると、自分の対応を見直しやすくなります。

・顧客ごとの範囲の確定と、PingCAP からの個別の連絡
・ほかの認証情報が出ていないかの調査結果と、API キーの差し替えを求めるかどうか
・修正前の脆弱性4件が悪用されていなかったかの結果

続報が出たら、本記事も更新します。

参照ソース

• PingCAP「Security Update」（2026年10月）
• PingCAP「Security Update」日本語版
• PingCAP Japan の X 投稿「不正アクセスによる情報漏洩に関するお詫びとご報告」
• Ransomware.live「Victim: PingCAP / TiDB Cloud」（2026-10-19 掲載）
• Hackmanac（@H4ckmanac）の X 投稿
• TechFlow「PingCAP database and customer data suspected stolen by hackers」
• Crypto Briefing「Bitget says no user data exposed in alleged TiDB Cloud breach」
• Sysdig「The FulcrumSec playbook」
• MOXFIVE「FulcrumSec: The Cloud Extortion Group Behind 21 Victims and Counting」
• TiDB Cloud「Explore Your Data with AI-Assisted SQL Editor」
• TiDB Cloud「Configure an IP Access List」
• TiDB Cloud「TiDB Cloud Dedicated Database Audit Logging」
• TiDB Cloud「Console Audit Logging」
• TiDB Cloud「API Keys in Data Service」
• TiDB Cloud API Overview
• PingCAP「Security Vulnerabilities Guidelines」
• pingcap/tidb の Security