Microsoft内部分析サービス「Titan」に認証不備　約17.3兆行へ到達可能だったと研究者報告、MicrosoftはAPIを閉鎖

16歳のセキュリティ研究者Faav氏は2026年9月25日、Microsoftの内部分析サービス「Titan」に、JWT（JSON Web Token）の署名を検証しない認証不備が存在していたと公表しました。

研究者によると、偽造したトークンが受け入れられ、Titan上で管理者権限のSQLクエリを実行できる状態でした。接続先を調査した結果、17のClickHouse分析データベース、9,863の一意なテーブル名を確認し、メタデータから到達可能な環境を約17.3兆行と推計しています。

ただし、17.3兆という数字は「漏えい件数」や「顧客数」ではありません。研究者自身が、履歴データ、重複、派生データなどを含むストレージ上の行数推計だと説明しており、顧客データを大量取得した事実もありません。Microsoftは報告後の9月9日に対象APIを閉鎖しました。

Microsoft「Titan」の認証不備に関するサマリー

確認できている内容：

• セキュリティ研究者Faav氏が2026年9月25日に調査結果を公開しました。
• 対象はMicrosoft内部の分析サービス「Titan」です。
• TitanのWeb画面はVPN経由に制限されていましたが、研究者によるとバックエンドAPIは別経路でインターネットから到達可能でした。
• TitanはJWT内のテナント、対象サービス、アプリケーション、ユーザーなどの情報を確認する一方、トークンの暗号学的な署名を検証していなかったと報告されています。
• この結果、偽造した未署名トークンが受け入れられ、ローカルの管理者アカウントとしてSQLを実行できる状態になりました。
• 研究者は17のClickHouse分析データベースと9,863の一意なテーブル名を確認しました。
• データベースのメタデータから、到達可能な環境を17,333,335,124,315行と推計しています。
• 研究者は顧客PII（個人を特定できる情報）を取得しておらず、大量のデータ抽出も行っていないとしています。
• Microsoft Security Response Center（MSRC）には2026年9月5日に報告され、9月9日に対象APIが閉鎖されました。
• Microsoftは9月17日に研究者へ5,000ドルのバグ報奨金を支払ったと、研究者が公表しています。

現時点で確認できない内容：

• 約17.3兆行が外部へ漏えいした事実は確認されていません。
• 約17.3兆行が17.3兆人分、または17.3兆件の顧客レコードを意味するものではありません。
• 第三者がこの不備を実際の攻撃で悪用したとの一次情報は確認できません。
• 2026年9月29日時点で、研究者の公開資料やMicrosoftの公開セキュリティ情報から本件に対応するCVE番号は確認できませんでした。
• Microsoftから本件単独のセキュリティアドバイザリは確認できず、修正内容の詳細は公開されていません。

VPNで保護された画面とは別にバックエンドAPIへ到達可能だった

Faav氏によると、TitanのWebインターフェースはMicrosoft従業員向けのVPN接続を要求する状態でした。

一方、バックエンドAPIは別のAzure上のエンドポイントから到達でき、公開されていたAPI仕様からデータベースへクエリを送る機能の存在を確認したとしています。

ここで問題となったのが認証処理です。APIはJWTを利用しており、トークン内のテナントや対象サービス、アプリケーション、ユーザーに関する値を検査していました。しかし、研究者の検証では、そのJWTが信頼できる発行元によって署名されたものかを確認する処理が機能していませんでした。

JWTの各種属性を検査していても、署名を検証しなければ、それらの属性が正規の発行元によって生成されたことを保証できません。

Microsoft Learnでも、Microsoft Entraのアクセストークンを受け取るWeb APIについて、トークンの署名と発行者を検証したうえで、対象となるAPIやテナントなどの情報を確認する手順を示しています。

偽造トークンが管理者として扱われ、SQLを実行可能に

研究者は、署名のない偽造トークンでもTitanがトークン内の属性を処理し続けることを確認しました。

その後、トークン内のユーザー情報がTitan内部のローカルユーザーと照合されていることを突き止め、偽造した認証情報がローカルの管理者アカウントへ解決される状態を確認しています。

研究者は影響確認を限定し、最小限のSQLクエリを使って管理者権限で処理できることを検証しました。

本記事では、再現可能なトークン生成方法、具体的なAPIパス、認証回避の操作手順は扱いません。

17の分析データベース、9,863のテーブルへ到達可能だったと報告

Faav氏は、過去に公開されていたTitanの設定情報から56のルーティング値を確認し、安全性を考慮した限定的なクエリで到達可否を調査しました。

その結果、30のルーティング値が有効で、24の設定を経由して17のClickHouse分析データベースにつながっていたとしています。一意なテーブル名は9,863でした。

Titan自身のプラットフォームメタデータからは、次の情報を確認したと報告しています。

• 約25,000件のアプリケーションアカウント・メール関連レコード
• 17,990件の社員メール関連レコード
• 15,001件の社員・組織関連レコード
• 355件のデータベース設定
• 20,979件の仮想データセット用SQL定義
• 24,569件のダッシュボード
• 425,891件のチャート
• 27,347件のデータセット定義

社員関連情報には、Titanを利用する一部従業員の役職、部署、管理関係なども含まれていたとしています。

一方、研究者は「顧客PIIにはアクセスしていない」と明記しています。社員関連データの確認と、顧客個人情報を大量取得したかどうかは分けて扱う必要があります。

Bing分析データは1行サンプルを2回だけ確認

研究者は接続先の一つとしてBingの分析データを確認し、最新の分析パーティションから1行だけ取得するクエリを2回実行したとしています。

サンプルには検索情報、識別子、国・州レベルの位置情報などが含まれていました。

研究者は、利用者を特定したり、複数のデータセットを関連付けてプロファイルを作成したりする検証は行っていません。

このため、Bing利用者の大量データが取得された、あるいは外部流出したとの事実は一次情報から確認できません。

9月5日にMSRCへ報告、4日後にAPIを閉鎖

研究者が公開したタイムラインでは、2026年8月25日にTitanの公開APIを発見し、9月5日に管理者権限でSQLを実行できる状態を確認しました。

同日、MSRCへ報告し、ケース番号144051が発行されています。

9月6日から8日にかけてMicrosoftは追加調査のため研究者へ検証停止を依頼し、9月9日に対象APIを閉鎖しました。9月17日には5,000ドルのバグ報奨金が支払われ、9月22日にMicrosoftと開示内容を協議しています。

Faav氏は、公開前の9月22日から24日にMicrosoftの要請で記事の一部を削除・修正し、Microsoftが公開内容に編集上の関与を持ったことも明記しています。

Microsoftは研究者のブログに掲載された声明で、協調的な脆弱性開示がサービスの強化につながったと説明しています。

AIツールが調査を継続、人間の判断で認証経路を特定

今回の調査では、Faav氏が開発したAI支援ツール「Antares」も利用されました。

研究者によると、Antaresはサブドメインの探索、API仕様の確認、認証エラーの整理などを継続的に行い、約10日間にわたって調査を進めました。

一方、AIはユーザー識別子を一般的なMicrosoft Entraの形式として解釈し続け、Titan内部のローカルアカウントとの対応関係を突き止められませんでした。

最終的に、研究者がバックエンドの実装を推測して検証方法を変えたことで、管理者権限へ到達できることを確認しています。

この点についてFaav氏は、AIだけでも、人間だけでも同じ速度では到達できなかったとして、AIによる継続的な探索と人間の仮説形成を組み合わせた調査だったと説明しています。

情報システム・開発部門が確認したいポイント

今回の問題はMicrosoft側で修正されており、一般のMicrosoft利用者向けにパッチ適用手順が公開された事案ではありません。

一方、自社でJWT認証や社内分析基盤、管理APIを開発・運用している企業では、同じ種類の設計不備がないか確認できます。

• JWTのペイロードを読む前提ではなく、署名検証を認証処理の必須条件としているか
• 許可する署名アルゴリズムを固定し、未署名トークンを拒否しているか
• issuer、audience、tenant、subjectなどの検証を、署名検証後に実施しているか
• 独自実装ではなく、Microsoft Identity Webなど実績のある認証ライブラリを利用できるか
• 外部IDの属性を、ローカルの管理者アカウント名や権限へ直接対応付けていないか
• VPNやSSOで保護した管理画面とは別に、バックエンドAPIがインターネットへ公開されていないか
• Swagger/OpenAPIなどのAPI仕様を、本番環境で不要に外部公開していないか
• 分析基盤のサービスアカウントに、複数データベースを横断する過剰な権限を与えていないか
• 管理APIから実行されたクエリ、認証失敗、異常なトークン利用を監査ログで追跡できるか
• 本番データへアクセスする内部ツールについても、外部公開サービスと同じ認証・認可レビューを行っているか

JWTを利用した認証では、トークン内の属性を確認するだけでは本人性を保証できません。Microsoft Learnは、署名を検証し、信頼できる発行元から生成されたトークンであることを確認してから、各種クレームを認可判断に利用するよう説明しています。

認証・認可の設計全体については、セキュリティ対策Labの「ユーザー認証とは？認証・本人確認・認可の違い、方式と企業の設計ポイントを解説」でも整理しています。

出典

• How I Could’ve Accessed 17 Trillion Microsoft Records – Faav
• Access tokens in the Microsoft identity platform – Microsoft Learn
• Secure applications and APIs by validating claims – Microsoft Learn
• Microsoft Security Response Center
• Microsoft Bounty Program Guidelines