この記事のポイント
- 脆弱性
- CVE-2026-96679
CVE-2026-96681
CVE-2026-100156 - 深刻度
- —
- 対象
- Bisheng
- 悪用状況
- 不明
- 情報の種類
- 二次情報のみ
- 公表日
目次
AIの回答内容を点検する前に、そのAI基盤へ誰がログインでき、誰のワークフローを実行できるのかを確認する必要があります。LLMアプリ基盤Bishengについて、管理者権限や利用者間のデータ・費用の境界に関わる脆弱性情報が国内でも公表されました。
JVNは2026年10月15日、JVNVU#94697946を公開しました。参照先のCERT/CC文書VU#166125は10月14日公開・同日改訂です。情報確認日は10月16日です。これは脆弱性情報の公表日であり、被害事件の発生日ではありません。本記事では実際の悪用やAIによる攻撃を確認したとは扱いません。出典：JVN：JVNVU#94697946 Bishengにおける複数の認証回避の脆弱性、CERT/CC：Vulnerability Note VU#166125。
なお、発見者の技術報告は9月25日付です。10月15日に世界で初めて詳細が公開されたという意味ではなく、今回の国内掲載を受け、未確認の導入先が対応を点検するためのニュースとして取り上げます。出典：Voke Cyber：Bishengの認証・認可不備に関する発見者の技術報告。
スポンサーリンク
3件を一つの「更新済み」で処理しない
BishengはLLMアプリケーションの構築・管理に使うオープンソース基盤です。CERT/CCは、旧SSO経路、利用者をまたぐワークフロー情報の参照、他利用者のLLM設定を使う処理という3件を整理しています。修正状況が同じではないため、製品のバージョンを一つ確認しただけで点検を終えるべきではありません。
- CVE-2026-96679：旧SSO経路の認証回避。CERT/CCの10月14日改訂文書では未修正として緩和策を案内しています。
- CVE-2026-96681：ワークフローのバージョン情報に対するIDOR。CERT/CCは3.0.0での修正を記載しています。
- CVE-2026-100156：assistantサービスのアクセス制御不備。CERT/CCは2.5.0での修正を記載しています。
この版数はCERT/CCの記載によるもので、本記事が各配布物をソース監査した結果ではありません。導入先の派生版やベンダー保守版は、提供元へ個別に対応を確認してください。3.0.0の記載を、3件すべて解消したという意味へ広げないことが重要です。出典：CERT/CC：Vulnerability Note VU#166125。
入口の本人確認と対象ごとの権限が別々に問題になる
旧SSO問題では、CERT/CCが示す POST /user/sso への認証前の呼び出しから、有効なセッションや高い権限へつながる経路が説明されています。一方、残る2件はログインした利用者による他人の情報や処理へのアクセスが中心です。入口のログインを強化する対策と、ログイン後の対象ごとの許可を直す対策は、同じ作業ではありません。
発見者のVoke Cyberは、Pro設定を使う構成や、ゲートウェイとバックエンドの関係を説明しています。ただし、設定変数の表記にはCERT/CC文書と発見者報告で差があります。本記事から一律の環境変数変更コマンドは提示しません。実際の導入版の設定と経路を保守担当者が確認する必要があります。出典：Voke Cyber：Bishengの認証・認可不備に関する発見者の技術報告。
以下の台帳、優先順位、確認例は本サイトからの運用上の提案です。個別環境で侵害が起きたことを示すものではなく、すべてのBisheng導入先が同じ条件で影響を受けると断定するものでもありません。
スポンサーリンク
最優先はバックエンドへの別経路を把握すること
自社にBishengがあるか、制作会社や委託先が提供するAI機能の裏側で使っていないかを確認します。製品名だけでなく、稼働版、コンテナーイメージの識別子、更新担当者、SSOの有無、管理用URL、外部へ出る経路を記録します。SaaSの場合は、利用者が直接パッチを当てられる範囲とは分けて、提供元へ照会します。
「社内向け」と呼んでいるだけでは、到達範囲は分かりません。リバースプロキシ経由の入口に加え、バックエンドの公開ポート、別ホスト名、検証環境、古い経路を確認します。正規の入口だけに認証を付けても、バックエンドへ直接届く経路が残れば、その入口の制御を通らない構成になり得ます。
CERT/CCは旧SSO経路の無効化・廃止や認証の強制、経路へのアクセス制限などを緩和策として挙げています。実施する場合は、どのサービスがその経路を使うかを先に把握し、必要な連携の代替と復旧担当を決めます。単に画面のログインボタンを隠す変更では、APIの呼び出し条件は変わりません。
本サイトでは、未修正の入口が外部から到達可能と確認された場合、保守担当へ直ちに連絡し、その入口の制限や機能の一時停止を優先することを提案します。「定例更新日にまとめる」という判断の前に、到達範囲と接続先の重要度を見てください。これは緩和であり、コードの修正確認を終えたという意味ではありません。
更新は「対応版」と「実際に動く版」を照合する
更新計画はCVEごとに作ります。対応版が示された2件については、採用しているリリース系列からの移行条件を確認します。設定形式やワークフローの互換性、必要なデータ移行は環境に依存するため、名前が新しいイメージを取得しただけで本番へ切り替えないようにします。
検証後の本番反映では、取得したイメージ、実行中のプロセス、複数台構成の各ノードまで照合します。ローリング更新の途中で旧版が残る、管理画面とワーカーが別の版で動く、といった見落としを点検します。画面上の版数だけでなく、運用担当者が確認できる稼働情報を記録します。
正常なワークフローが動くかに加え、許可されていない利用者が拒否されるかも確認します。機能試験の成功だけでは、認可の修正が効いている証拠になりません。失敗時に古い版へ戻す判断が必要なら、既知の問題を再び公開しないよう、アクセス制限を併用した復旧条件を用意します。
スポンサーリンク
読み取りAPIとAI処理の実行権限を組にして試す
OWASPのAuthorization Cheat Sheetは、各要求での権限検証や原則拒否の考え方を説明しています。Bishengの点検でも、ログインできるかだけでなく、誰のどの対象を読む・実行する処理かを確認します。IDが推測しにくいことは、その対象を使ってよいという判断の代わりにはなりません。出典：OWASP：Authorization Cheat Sheet。
説明用の検証例として、架空の利用者AとB、内容が区別できるテスト用ワークフローを用意します。Aが自分の情報を取得できる正常例と、Bの情報を取得できない拒否例を対にします。履歴の一覧、履歴の詳細、エクスポート、補助的な最適化処理など、対象を読む別経路も確認します。これは本サイトの提案であり、すべてが今回の脆弱なAPIとして報告されたという意味ではありません。
拒否の確認は、画面にエラーが出たかだけで終えません。モデル提供元への呼び出しが発生していないか、別の利用者の課金先が選ばれていないか、バックグラウンドのジョブが残っていないかを、許可された検証環境の記録で照合します。実データや本番の秘密を使わず、低い上限のテスト用資格情報で確認できる範囲を決めます。
フローの中の秘密と利用記録を点検する
発見者報告は、ワークフロー定義に接続用の情報などが含まれる点を指摘しています。自社では、定義や履歴へ実際に何を保存したかを棚卸しします。APIキー、接続文字列、認証ヘッダー、外部ツールの設定を区別し、「キーはブラウザーへ出していない」という確認だけで終えないことを提案します。出典：Voke Cyber：Bishengの認証・認可不備に関する発見者の技術報告。
漏えいや不正利用が疑われる場合は、調査対象の期間、接続先、利用者、保存記録を絞って保全します。証拠を残す前にログを一括削除したり、すべてのキーを無計画に入れ替えたりすると、調査と復旧が難しくなることがあります。緊急に止めるべき資格情報は担当者が判断し、影響と再接続の手順を記録します。
キーを変更する際は、新しい値を発行して保存するだけでなく、古い値の失効と、別の経路に複製が残っていないかも確認します。外部AIサービスの利用明細に急増があっても、それだけで今回の脆弱性の悪用と断定はできません。アプリの処理記録と提供元の利用時刻・識別子を突き合わせる必要があります。
WordPress運営者が委託先へ確認する項目
WordPress自体の更新だけでは、別に動いているAI基盤の修正にはなりません。問い合わせチャットや社内の記事作成機能を外部サービスへ接続しているなら、どの製品を使い、どこで利用者と接続先を選び、誰が更新するのかを確認します。Bishengを使っていない場合、本件だけを理由に無関係なWordPress設定を変更する必要はありません。
- 製品と範囲：Bishengの利用有無、実稼働版、管理用と一般利用用の到達経路を確認する。
- 3件の対応：CVEごとの修正状況と、未修正の旧SSO経路をどう制限したかを回答してもらう。
- 権限の検証：別の利用者のフローを読めないこと、別の課金先でAI処理を動かせないことを確認する。
- 秘密と復旧：保存された資格情報の範囲、失効の担当、影響時の停止と再開条件を決める。
再開の条件を「画面が開く」より具体的にする
再開判断は、正常なログインと動作だけでなく、旧経路の扱い、対応版の稼働、拒否されるべき操作、秘密の処置まで含めて記録します。未確認の項目は担当者と期限を残し、確認済みという一語へまとめないことを提案します。委託先の回答が製品名と「最新版です」だけなら、対象CVEと緩和策を追加で確認してください。
本件は、AIの回答を操るプロンプト攻撃とは別に、AI基盤の通常の認証・認可が破られるリスクを示しています。公開された技術情報は被害の発生日時や国内の被害件数を確定する資料ではありません。新たな修正やベンダー説明が出る可能性があるため、作業直前にもJVNとCERT/CCの更新を確認し、現在の状態に合わせて対策を見直してください。
スポンサーリンク
