分散データベース「TiDB」を提供するPingCAPは、盗まれたサービス用アカウントの認証情報を使って社内システムに不正アクセスされ、データやソースコードが複製されたと公表しています。国内でも最大約5万件の個人情報が漏えいしたとの発表が報じられ、顧客ごとの影響確認が続いています。

同社が公表した英語の調査報告では、不正なアクセスの期間は2026年9月9日から10月7日です。7日に事案を把握し、その日から影響のある認証情報の無効化を始めました。14日までに、特定した侵害済みの認証情報をすべて無効にし、把握した不正アクセスの経路を遮断したと説明しています。

国内の最大約5万件という情報は、21日の発表を伝えたビジネス＋ITの報道によるものです。件数を、そのまま重複のない人数と扱うことはできません。また、すべての利用者のすべての情報が流出したという意味でもありません。対象の範囲は顧客ごとの調査で確認する必要があります。

公式報告は、調査した本番システムで攻撃者が命令を実行したり、持続的なアクセスを維持したりした証拠は見つかっていないとしています。一方、その結果によってデータの露出が否定されるわけではないと明記しています。侵入の継続が確認されないことと、情報が持ち出されていないことは別です。

社内の情報と顧客が保存したデータを区別します

公式の説明では、外部の専門家と調べた範囲で、TiDBに保存されているデータが影響を受けた証拠はないとしています。これは重要な説明ですが、サービスの利用に関連して同社側に保管されていた情報まで無事だったという意味ではありません。保存される場所と情報の用途で影響を分けて読む必要があります。

報告では、TiDB Cloudの利用者名やメールアドレス、組織・プロジェクトとの関連、SQLエディターのテキストやエラーなどが対象に含まれます。商取引や請求の情報も挙げられています。ただし、各種類の情報がすべての顧客について含まれると確認されたわけではなく、個別の範囲は調査中です。

認証情報についても線引きがあります。取り出された表には暗号化されたAPIキーの値があり、外部の調査会社が試した一つの値は、そのままAPIキーとして使えなかったとしています。一つの確認結果から、ほかに使用できる認証情報が一切なかったと結論付けることはできません。

攻撃者が主張する内容と、調査で確認された内容も異なります。流出量や認証情報に関する主張を、そのまま企業の確定発表と扱うのは適切ではありません。公式報告が未検証としている部分は、引き続き未確認です。本稿では攻撃者の掲げた数字を被害の確定規模として採用していません。

利用企業は自社への通知を起点にします

サービスを利用している企業は、まず契約している組織やプロジェクトが調査の対象に含まれるかを確認する必要があります。利用している製品名が同じでも、契約や運用の形態は異なります。TiDBという名前を社内で使っていることだけを理由に、自社のすべてのデータが流出したと決めることはできません。

問い合わせでは、契約主体、対象期間、利用しているサービス、受け取った通知を整理すると確認が進めやすくなります。顧客ごとの影響が確定したら直接通知するという会社側の説明もあります。通知を受けたことと、影響のすべてが確定したことは同じではないため、回答の範囲を記録しておくことが重要です。

社内では、管理者と情報セキュリティ担当、必要に応じて契約や個人情報の担当が連携することになります。調査が途中の段階で外部向けの説明が必要になった場合は、確認済みの内容と調査中の点を分ける必要があります。提供元の説明を超えて、無影響を保証する表現を使うのは慎重であるべきです。

同時に、根拠のない被害拡大を断定することも避ける必要があります。顧客のデータが置かれた本番環境と、サポートや請求のための情報を区別しない説明は、利用者の判断を難しくします。何がどこから持ち出されたかという単位で整理することが、対応の優先順位を付ける助けになります。

認証情報の対策と記録の保全です

今回の入り口として説明されているのは、盗まれたサービス用アカウントの認証情報です。人が画面に入力するパスワードだけでなく、システム同士の連携に使う認証も管理の対象になります。権限の範囲、利用先、期限が把握されているかが、一般的な運用上の確認点です。

不審な認証情報を無効化することは重要ですが、業務で利用中のキーを手当たり次第に止めるとサービスが動かなくなる場合があります。利用企業は公式の案内に沿い、どの機能が依存しているかを確認しながら対応する必要があります。本稿は個別環境の構成を確認しておらず、一律の操作手順は指定していません。

また、認証情報を替える前後のログや通知を残すことは、影響の確認に役立ちます。記録を消してしまうと、後から自社の利用と不審なアクセスを照合しにくくなる場合があります。保存方法や閲覧権限は各社の規程に沿って決め、調査のために新たな漏えいを起こさない配慮も必要です。

問い合わせを装う連絡にも注意が必要です。実在する事故の名称を使い、本人確認や認証情報の入力を求める案内が来る可能性は一般にあります。今回そうした二次被害が何件発生したかは未確認です。リンクを受け取った場合は、普段の公式窓口から同じ案内があるかを確認する方法が基本になります。

家計や一般利用者に届く影響は間接的な場合もあります

業務向けのデータベースサービスで起きた事案は、契約している企業を通じて一般利用者に関わることがあります。ただし、提供元で事故があったというだけで、すべての導入企業の顧客情報が漏えいしたとはいえません。実際に利用するサービスから通知があれば、その対象項目と対応を確認する必要があります。

氏名やメールアドレス、契約に関する情報の漏えいは、口座からお金が引き出されたことと同じではありません。一方で、詳しい取引情報があれば、もっともらしい連絡を作る材料になる可能性があります。情報の種類ごとに想定される影響が違うため、単に漏えいという言葉だけで対応を決めないことが重要です。

企業が費やす調査や再設定の負担は、現場の人員や作業時間にも関わります。ただし、今回の損害額や国内企業全体の対応費用は確認していません。最大件数から一件当たりの費用を仮定して総額を出すことには根拠が不足します。実際の対応の範囲を待つ必要があります。

サービスの停止も、情報漏えいと別に判断する事項です。機能を止めることで被害拡大を抑える場合がある一方、利用者の業務に影響します。今回、すべての顧客がサービスを停止しなければならないという一律の案内を確認したわけではありません。自社の条件と提供元の最新の通知に沿って考える必要があります。

修復済みの部分と調査中の部分が併存します

公式報告によると、外部調査で指摘された脆弱性は14日までに修正され、再検証も受けています。ただし、修正したことだけで過去の持ち出しの範囲がすべて分かるわけではありません。技術的な封じ込めと、顧客への影響確認が別の作業として進むことを理解する必要があります。

今後の更新では、顧客別の対象範囲、追加の認証情報の有無、修正前に別の悪用がなかったかという調査結果を確認します。対象件数が変わった場合には、新たな侵入か、過去の調査の精査かも分けて伝えます。数字が増えたというだけで攻撃が継続していると断定しません。

本稿は23日未明までに確認した会社の公表資料と国内報道に基づきます。写真はサーバー設備のイメージで、PingCAPの被害設備を撮影したものではありません。被害を受けた企業の一覧など、未確認の情報は掲載していません。

SQLエディターに残るテキストには、実行しようとした処理や調査のための記述が含まれる場合があります。データベース本体への侵入が確認されていなくても、周辺の管理情報にどのような内容を残していたかは別に確認する必要があります。今回の顧客ごとの内容は調査中であり、すべて同じ情報が含まれるとは限りません。

社内で連絡する際には、契約先から来た通知の原文と、自社が追加で確認した事項を分けて記録すると、説明の変化を追いやすくなります。調査が進むたびに対象の理解が変わる可能性があるため、回答を受けた日付も重要です。最新の説明に置き換えるだけでなく、何が判明したかを把握することが対応の継続に役立ちます。

確認元：PingCAP「Security Update – October 2026 Security Incident Report」、ビジネス＋IT「TiDBのPingCAP、日本国内で最大約5万件の個人情報が不正アクセスで漏洩したと発表」。https://www.pingcap.com/trust-hub/security/security-update-october-2026/　https://www.sbbit.jp/article/cont1/187662

まとめ

PingCAPは認証情報を悪用した不正アクセスとデータの持ち出しを公表し、経路の遮断後も顧客別の調査を続けています。利用企業は保存されたデータと管理用の情報を分け、公式通知と自社の記録に基づいて影響と必要な対応を確認することが重要です。