社内で生成AIを使ったアプリやアシスタントを作る動きが広がっています。その土台となるオープンソースの基盤の一つ「Bisheng(ビシェン)」に、認証を回避できる脆弱性が見つかりました。CERT/CCが2026年10月14日に公表したもので、3件のうち1件は認証なしで管理者権限を奪える深刻な問題です。しかも、修正版がなく、ベンダーからの応答もありません。
何が見つかったのか
Bishengは、DataElement社が開発する、オープンソースのLLMアプリ開発・運用の基盤です。社内のサーバーに立てて使う形が中心です。CERT/CC(VU#166125)によると、見つかったのは次の3件です。
- CVE-2026-96679(レガシーSSOの回避): ある入口(POST /user/sso)が、呼び出し元の認証なしに、送られた任意のユーザー名に有効なトークン(JWT)を発行します。該当ユーザーがいなければアカウントが作られ、設定された管理者名と一致するか最初の利用者であれば、最上位の管理者権限を得られます。認証なしでアプリ全体を乗っ取られうる、最も深刻な問題です。修正版はありません。
- CVE-2026-96681(IDOR): 権限の確認が抜けており、ログインできる利用者なら、ほかの利用者のワークフロー(設定)を読めてしまいます。版3.0.0で修正済みです。
- CVE-2026-100156(権限確認の抜け): アシスタントの自動最適化の入口が、持ち主の確認なしに識別子を受け付けます。これにより、別の利用者のアカウントに課金される形で推論を実行させたり、そのアシスタントのツールや設定を漏えいさせたりできます。版2.5.0で修正済みです。
CERT/CCが公表したBishengの脆弱性のノート(VU#166125)出典: CERT/CC(VU#166125)(引用)
やっかいなのは、最も深刻なCVE-2026-96679に修正版がない点と、ベンダーの対応です。CERT/CCは、2026年8月6日にベンダーへ通知したものの、複数回の連絡に応答がなく、対応状況は不明で、ベンダーからの声明も受け取っていないとしています。
影響を受けるのはどんな環境か
関係するのは、Bishengを自組織のサーバーに立てて使っている組織です。社内で生成AIのアプリやアシスタントを作る基盤として導入している場合、とくにそれをインターネットからアクセスできる状態に置いていると、認証なしの乗っ取り(CVE-2026-96679)のリスクが現実的になります。
見落としやすいのが、情シスが把握しないまま、開発部門や一部のチームが自分たちで立てている「シャドーIT」のケースです。生成AIの基盤は、試してみようと手軽に立てられるため、気づかないうちに社内で動いていることがあります。
情シスが今日やること
- 利用の有無を棚卸しする: Bishengを自組織で使っていないか、開発部門などが独自に立てていないかを確認します。生成AIのアプリ基盤は、把握されないまま動いていることがあります。
- バージョンを確認する: 使っている場合、CVE-2026-100156は2.5.0、CVE-2026-96681は3.0.0で修正されています。可能な版へ更新します。
- 未修正の問題に回避策を当てる: CVE-2026-96679には修正版がありません。CERT/CCは回避策として、
BISHENGPRO=trueを使わないこと、レガシーのSSO機能(sso())を無効化・廃止すること、トークン(JWT)の検証を全体で強制すること、POST /user/ssoをループバックや同一オリジンからのみに制限することを挙げています。
- 外部からのアクセスを絞る: インターネットに直接公開していないかを確認し、必要な範囲に限定します。認証を回避される入口が外から届かないようにするだけでも、リスクは大きく下がります。
- ログを点検する: 不審なアカウントの作成や、管理者権限の取得、見覚えのないアクセスがないかを確認します。
生成AIを自前の基盤で動かす動きは、これからも広がります。便利な一方で、立ち上げた基盤のセキュリティは自分たちで見る必要があります。今回のように、修正版が出ない・ベンダーが応答しないこともあります。まず「どこで何を動かしているか」を把握し、外からの入口を絞り、回避策を当てることが、情シスにできる現実的な守りになります。
