Xerjを導入している管理者向けです。CERT/CCは、既存の有効なAPIトークンから独立した後継の認証情報を発行できる問題を公表しました。元のトークンを失効しただけで封じ込めが完了したと考えないでください。公式修正の提供は、参照した勧告では確認できていません。
XerjはAIエージェント向けの検索・索引基盤です。CERT/CCのVU#645818は2026年10月20日公開、JVNの国内案内は21日公開です。対象はCVE-2026-97406。似た名前の別製品や、Elasticsearchそのものの脆弱性として取り扱わないようにしてください。
問題の中心は「トークンを使える」と「発行してよい」の混同
CERT/CCによると、Xerjでは新しいAPIトークンの発行をパスキーで認証したセッションに限る設計のはずが、APIのBearerトークンとブラウザーのセッションを共通のAuthSessionとして扱い、発行時にパスキー認証の有無を確認していません。攻撃の前提には有効な既存トークンが必要です。「何も持たない外部の人が直接ログインできる」とは異なります。
作られた後継トークンは、元のトークンを失効させても連動して無効になりません。アカウント所有者の権限を持つトークンの場合は、後継の認証情報やアカウントの状態まで確認が必要になります。これはトークンを文字列として交換するだけの対処では足りない、という運用上の問題です。
確定したことと、未確認のこと
| 項目 | 確認結果 |
|---|---|
| 識別子 | CVE-2026-97406／CERT VU#645818 |
| 入口の条件 | 有効なXerj APIトークンを持つこと |
| 影響 | パスキーの確認を経ない後継認証情報の発行と、持続的な不正アクセス |
| 影響版・修正版 | 参照勧告に具体的な版の範囲はなく、公式パッチ未提供と記載 |
| 評価・実悪用 | 参照勧告にCVSS数値の記載なし。実悪用の有無は未確認 |
公開資料から分からない項目を、最新版の番号や独自の深刻度で埋めません。修正版が不明でも、導入の有無と不必要な公開を確認する作業は進められます。開発元の修正を確認する際は、単に新しいリリースがあるかではなく、このCVEの修正が明記されているかを見ます。
トークンのローテーションだけで閉じない点検手順
- 1Xerjを使う環境を列挙し、管理コンソールへの到達経路、運用担当、認証情報の発行権限、導入コミットまたは配布版を記録する。
- 2監査ログがあれば保全し、通常と異なるトークン発行、招待、メンバー追加、パスキー登録などを点検する。ログに見当たらないことだけで無被害と判定しない。
- 3トークンの値を外に出さず、識別子・発行日時・権限・所有者の一覧を作る。既存の持ち主が確認できないものを未確認として残す。
- 4侵害が疑われる場合は、管理APIの到達制限やサービス隔離を担当者が検討する。業務停止の影響と証拠保全の順序を確認する。
- 5認証情報の再発行だけでなく、独立した後継トークンや不正なメンバー・登録済み認証手段を含めて回復計画を立てる。承認された作業後に通常のAPI利用を確認する。
これは編集部による一般的な封じ込め・棚卸しの提案です。特定設定で脆弱性を完全に直せると確認した手順ではありません。正常な自動処理もトークンを使うため、無計画な一括削除は業務を止めます。インシデント担当と所有者が、正当なアクセスと不明なアクセスを分けて判断します。
AIエージェントへ渡す鍵の管理にも関係する
AIエージェントに渡す認証情報は、検索に必要な最小限の権限へ絞る、利用先と所有者を記録する、失効後に残る別のアクセス経路を点検する、といった基本が重要です。今回の件は「パスキーが弱い」という話ではなく、パスキーで確認すべき操作に別の認証経路が通ってしまう設計上の問題です。
通常の利用者にできるのは、提供事業者へ導入の有無と対処状況を確認することです。攻撃者の操作を模したトークン発行を本番で試す必要はありません。記事には悪用用リクエストを掲載せず、防御側の確認対象を示しています。
LLMに依頼する、根拠付きの点検
以下は編集部が作成した棚卸し用の指示文です。LLMの回答は安全性の保証にはなりません。未確認項目を残し、担当者が公式資料と実際の稼働状態を照合してください。
あなたは防御目的の運用点検担当です。権限のある自社環境について、提供した匿名化済み台帳と公式勧告だけで読み取り専用の棚卸しをしてください。 Xerjの導入有無、管理APIの到達経路、トークン発行・招待・パスキー登録の監査項目を整理してください。トークン値を使わず識別子で管理し、元トークンの失効と後継認証情報の処理を別項目にしてください。 各項目を「対象」「対象外（根拠付き）」「未確認」に分け、根拠URL・配布元・稼働版・条件・担当者・修正版または未確認事項・確認期限を表にしてください。版だけで安全と断定しないでください。秘密鍵、トークン、パスワード、個人情報を要求せず、設定変更や攻撃再現、外部へのスキャンは実行しないでください。更新案と回帰確認案は作成しても、適用は担当者の判断に分けてください。
点検指示文をダウンロード。基本の進め方は脆弱性のトリアージも参照してください。
確認日：2026年10月22日。公開された一次資料を確認した解説であり、編集部がこの脆弱性の攻撃やパッチ適用を実環境で再現したものではありません。手順のうち優先順位・台帳・回帰確認は編集上の提案です。