Xerj Console APIで認証回避！親トークン失効後も残る後継資格情報を点検

AIエージェント向けの検索基盤「Xerj」に、管理用のConsole APIを通じて後継の認証情報を作成できる脆弱性が公表されました。CERT/CCは2026年10月20日、Vulnerability Note VU#645818としてCVE-2026-97406を公開し、JVNも10月21日に注意を呼びかけています。

重要なのは、インターネット上の誰もが無条件で侵入できる問題ではない点です。攻撃には、すでに有効なXerj APIトークンを所持または取得していることが前提になります。しかし、そのトークンから独立した後継資格情報を作成でき、元のトークンだけを失効しても後継側が残り得ます。APIキーの漏えい対応を「見つかったキーを無効化して終わり」と考えている運用では、封じ込めが不完全になる可能性があります。

公表された内容と確認できている範囲

Xerjは、コード、ドキュメント、ログなどを索引化し、AIエージェントから検索できるようにするローカルファーストの検索エンジンです。公式リポジトリではMCPサーバー機能とElasticsearch互換APIが案内されており、開発端末だけでなく、複数のエージェントや利用者が共有する検索基盤として運用される可能性があります。

CERT/CCの説明によると、XerjはブラウザのセッションとAPIのBearerトークンを、共通の汎用的なAuthSessionへ変換します。ところが、Console APIのトークン作成処理は、そのセッションがパスキーで裏付けられた管理セッションかどうかを検証しません。このため、有効なAPIトークンを持つ呼び出し元が、同じアクセス水準を持つ別の永続的な資格情報を発行できるとされています。

さらに、元のトークンと、そこから作られた資格情報の間に失効関係がありません。親に当たるトークンを無効化しても、すでに作成された後継トークンは独立して有効なまま残り得ます。元のトークンが所有者権限を持っていた場合、後継資格情報も管理権限を保持し、招待、引き換え、攻撃者のパスキー登録へつながる可能性がCERT/CCから示されています。

2026年10月21日の確認時点で、CERT/CCはベンダーへ連絡できておらず、公式パッチは利用できないとしています。影響バージョンの範囲、CVSSスコア、実際の悪用事例は、今回確認した一次資料では示されていません。そのため、本記事では深刻度や悪用の有無を推測せず、修正版が出たとは扱いません。

攻撃成立には既存トークンが必要

この脆弱性を正しく評価するには、攻撃の入口と永続化の問題を分ける必要があります。入口は、有効なXerj APIトークンの取得です。リポジトリへの誤コミット、CIログへの出力、エージェント設定ファイルの共有、バックアップの公開、端末や拡張機能からの窃取など、トークンが漏れる経路は環境ごとに異なります。今回の一次資料は、どの経路でトークンが取得されたかを扱うインシデント報告ではありません。

問題は、入口となったトークンを管理者が発見して無効化しても、それ以前に作られた後継資格情報を同時に消せないことです。一般的な漏えい対応では、流出したキーの失効と再発行を最初に行います。しかしXerjでは、その操作だけで攻撃者のアクセスを断てたと判断できません。認証情報の一覧、招待、パスキー登録、管理操作の履歴まで確認しなければ、残存アクセスを見落とす恐れがあります。

AIエージェント運用で影響が広がる条件

Xerjを個人の開発端末で、ループバックアドレスだけにバインドして使う場合と、チーム共通のMCP検索基盤として使う場合では、露出面が異なります。公式READMEは新しいノードが初期状態で127.0.0.1へバインドすると説明しています。一方で、共有ホスト、コンテナ、リモート開発環境、リバースプロキシ配下で公開範囲を広げれば、Console APIとトークンの管理も共有サービスとして設計する必要があります。

• 複数のAIエージェントへ同じ高権限トークンを配布している
• エージェント設定やMCP構成ファイルを共同リポジトリで扱っている
• Console APIへ社外ネットワークや広い社内セグメントから到達できる
• 管理者用と検索専用の資格情報を分離していない
• トークン作成やパスキー登録を監査対象にしていない

これらの条件が重なるほど、ひとつのトークン漏えいが長期間の管理アクセスへ発展しやすくなります。反対に、ローカル限定、到達元の制限、用途別トークン、短い配布経路、操作記録を組み合わせれば、攻撃の成立可能性と調査範囲を小さくできます。

今すぐ行う封じ込めの順序

以下はCERT/CCの公表内容を踏まえた本サイトの運用提案です。製品の正式な修正手順ではなく、各組織の構成、ログ保存、事業影響に合わせて実施してください。

1 到達経路を先に狭める

Console APIとXerjの管理面を、インターネットや不要なセグメントから切り離します。ループバック、管理用VPN、明示した送信元だけのファイアウォール許可、リバースプロキシのアクセス制御など、現在の構成で即時に適用できる境界を選びます。調査前にサービスを停止できない場合でも、到達元の縮小は後継資格情報を追加発行される機会を減らします。

2 証拠を保全して資格情報を棚卸しする

トークン、利用者、招待、登録済みパスキー、管理操作、APIアクセスの記録を保存し、通常の運用と照合します。単に現在使っているキーだけでなく、作成者が不明な資格情報、想定外の時刻や送信元からの作成、元の運用台帳にない管理主体を確認します。ログの保持期間が短い環境では、ローテーションより先に必要な記録を退避する判断も必要です。

3 親トークンだけの失効で完了としない

漏えいが疑われるトークンを無効化しつつ、そこから派生した可能性があるすべての資格情報を調査します。確実に列挙できない場合は、信頼できる管理経路から全資格情報を再構成すること、インスタンスを隔離してクリーンな環境へ移行することも検討します。どこまで再構築が必要かはXerjの保存データ、周辺の秘密情報、バックアップ設計によって変わります。

4 エージェントへ渡す権限を減らす

検索だけを行うAIエージェントへ所有者権限のトークンを渡さない構成に改めます。製品が提供する権限範囲の中で、管理操作と検索操作を分け、環境やエージェントごとに資格情報を分離します。MCPクライアントの設定ファイル、CI/CDのシークレット、開発コンテナ、共有端末を横断して、同じトークンが複製されていないかも確認します。

5 修正版は公式情報で確認する

CERT/CCは、XerjのGitHubを監視し、修正が公開されたら最新バージョンへ更新するよう案内しています。リポジトリの更新日時だけで修正済みと判断せず、CVEへの言及、リリースノート、認証処理の変更、公式の修正宣言を照合してください。更新後は、APIトークンだけでConsoleのトークン作成処理を実行できないことと、失効の期待動作を隔離した検証環境で確認します。

insecure設定も同時に点検する

Xerjの公式READMEは、--insecureを付けるとTLSと認証が無効になり、すべての呼び出し元がスーパーユーザーとして扱われるため、単一利用者の隔離された開発端末に限定するよう説明しています。今回のCVEとは別の設定上のリスクですが、同じ棚卸しで確認すべき項目です。コンテナのポート公開やクラウド開発環境の転送によって、ローカルのつもりだったサービスが外部から到達可能になっていないかを確認してください。

設計面で得られる教訓

パスキーを採用していても、強い本人確認が必要な操作の直前で、その認証特性を検証しなければ保護は成立しません。ブラウザセッションとAPIトークンを同じセッション表現へ正規化すると実装は簡潔になりますが、「どの認証方式を通過したか」という情報まで失えば、資格情報の発行や管理者追加にステップアップ認証を要求できなくなります。

また、トークンの親子関係を記録しない設計では、漏えい時の失効範囲を特定できません。AIエージェント基盤では、人が直接操作しないトークンが多数の端末や自動処理へ複製されやすいため、発行元、用途、所有者、最終利用、失効伝播を監査できる設計が重要です。これはXerj固有の問題を越え、MCPサーバーやツール実行基盤を選定するときの確認項目になります。

更新後に確認する検証項目

修正版が提供された場合も、更新の成否だけで対応を完了させないことが大切です。検証用の低権限APIトークンを用意し、Consoleの資格情報発行が拒否されること、管理者のパスキーセッションでは正規の発行ができること、親トークンの失効時に関連資格情報がどのように扱われるかを確認します。検証には本番の秘密情報を使わず、結果と製品バージョンを記録します。

あわせて、外部ネットワークから管理面へ到達できないこと、検索専用トークンで管理操作ができないこと、トークン作成とパスキー登録が監査ログへ残ることを確認します。期待と異なる場合は公開範囲を戻さず、ベンダーの案内を待つか、代替の分離構成を維持してください。脆弱性修正と、過去に作られた不審な資格情報の除去は別の作業です。アップデートしても、侵害の可能性がある環境の調査は省略できません。

現時点の限界

本記事は2026年10月21日に、CERT/CC、JVN、Xerj公式GitHubの公開情報を確認して作成しました。影響バージョン、CVSS、悪用の観測、修正リリースは確認できていません。今後ベンダーから情報が公開された場合は、対象範囲と更新手順が変わる可能性があります。運用判断では、CVE番号だけでなく、自組織の到達性、配布済みトークンの権限、後継資格情報を追跡できるかを基準にしてください。