脆弱性情報（JVN）検索・一覧

Open WebUIは、完全にオフラインで動作するよう設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.6以前では、backend/open_webui/utils/oauth.py::_process_picture_urlが初期URLに対してのみvalidate_url(picture_url)を呼び出し、その後allow_redirects=Falseを指定せずにaiohttp.ClientSession.get(picture_url, ...)を呼び出していました。aiohttpのデフォルト設定はallow_redirects=True、max_redirects=10であり、この関数はプロジェクトのAIOHTTP_CLIENT_ALLOW_REDIRECTS環境変数も渡していませんでした。そのため、有効なOAuth IdPのIDを持つ攻撃者は、302リダイレクトを利用して内部アドレスに転送される公開URLを送信し、自らのprofile_image_urlフィールドを介して内部のレスポンスボディを読み取ることが可能でした。この脆弱性はバージョン0.9.6で修正されました。

Open WebUIは完全にオフラインで動作することを目的としたセルフホスト型の人工知能プラットフォームです。バージョン0.9.6以前では、Open WebUIは認証済みユーザーが自身のチャットメッセージに所有権や読み取り権を持っているかどうかを確認せずに、任意のfile_id値を添付することを許可していました。攻撃者がそのチャットを共有し、さらに自分自身に読み取りアクセス権を付与すると、has_access_to_file()は被害者のファイルを共有チャット経由でアクセス可能と判断し、ファイルのエンドポイントは被害者のファイルを読み取ったり削除したりします。この脆弱性はバージョン0.9.6で修正されました。

Open WebUIは完全にオフラインで動作するセルフホスト型の人工知能プラットフォームです。バージョン0.9.6以前のOpen WebUIでは、ワークスペースモデルの作成、更新、またはインポートが可能なユーザーが、自分が所有しているか参照可能かどうかを確認せずに、モデル上に任意のmeta.knowledgeエントリを保存できました。Open WebUIはmeta.knowledgeのタイプfileのエントリを2箇所で認可ソースとして扱っています。組み込みのview_fileツールはファイルの抽出テキストを読み取り、has_access_to_file()関数のモデルブランチはファイル内容およびファイル削除のエンドポイントを認可します。悪意のあるモデル所有者は他のユーザーのファイルIDを自身のモデルメタデータに付加し、そのプライベートファイルを読み取ったり削除したりできてしまいます。この脆弱性はバージョン0.9.6で修正されました。

Open WebUIは完全にオフラインで動作することを目的とした自己ホスト型の人工知能プラットフォームです。バージョン0.9.6以前では、Open WebUIはユーザープロフィール画像およびWebhookプロフィール画像におけるSVGのXSS脆弱性を修正していましたが、モデルプロフィール画像には同じ修正を適用していませんでした。ModelMetaクラスにはvalidate_profile_image_urlフィールドのバリデータがなく、モデル画像を配信するエンドポイントにはMIMEの許可リストやnosniffヘッダーが設定されていませんでした。workspace.models権限（デフォルトで有効）を持つ認証済みユーザーは、modelのプロフィール画像にdata:image/svg+xml;base64,...形式のペイロードを保存でき、その画像URLにアクセスした任意のユーザーのアカウントを完全に乗っ取ることが可能でした。この脆弱性はバージョン0.9.6で修正されています。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。0.9.6以前のバージョンでは、SafePlaywrightURLLoaderがvalidate_url関数を実装しており、ユーザーが提供したURLのIPアドレスをチェックしてSSRF攻撃を防止していました。しかし、この検証は初期のURLに対してのみ行われます。PlaywrightはデフォルトでHTTPリダイレクト（301/302）を自動的に追従するため、攻撃者は安全なURLを提供し、そのURLが制限された内部ネットワークアドレス（例：localhost、Dockerコンテナネットワーク、クラウドメタデータ）にリダイレクトされることで検証を回避できます。これにより、ENABLE_RAG_LOCAL_WEB_FETCHがFalseに設定されていても、アプリケーションが内部サービスにアクセスできてしまう状態でした。この脆弱性はバージョン0.9.6で修正されました。

vLLMは大規模言語モデル（LLM）の推論およびサービスエンジンです。バージョン0.22.1以前のvLLMのDockerfileは、flashinfer-jit-cacheパッケージを通じた依存関係混乱攻撃に対して脆弱でした。このパッケージは--extra-index-urlを使用してカスタムインデックス（flashinfer.ai/whl/）からインストールされますが、パッケージ名はPyPIに登録されておらず、UV_INDEX_STRATEGY="unsafe-best-match"がグローバルに設定されていました。攻撃者がバージョン0.6.11.post2のflashinfer-jit-cacheをPyPIに登録すると、Dockerビルド中にroot権限で任意のコードを実行でき、生成されるすべてのコンテナイメージにバックドアを仕掛けることが可能になりました。これにより、本番のvLLM展開からすべてのユーザープロンプト、API認証情報、およびモデルデータが流出します。この脆弱性は0.22.1で修正されました。

protobufjs-cliはprotobuf.jsのコマンドラインアドオンです。バージョン1.3.2および2.5.0以前では、pbjsのstatic/static-moduleコード生成における安全でない名前の処理に関する修正が不完全でした。影響を受けるprotobufjs-cliのバージョンは、細工されたJSONディスクリプタ入力から静的出力を生成する際に、依然として安全でないJavaScript参照を出力する可能性があります。通常の.protoファイルからスキーマを解析するケースは影響を受けません。この問題は既知の脆弱性の回避策を回避する手法に該当します。事前に解析されたJSONディスクリプタをpbjsの静的コード生成に渡すことができる場合、攻撃者は生成されるJavaScript出力に攻撃者制御のコードを含める可能性があります。生成されたファイルがその後実行またはインポートされ、影響を受ける生成APIパスが呼び出されると、その注入されたコードが実行される場合があります。この脆弱性はバージョン1.3.2および2.5.0で修正されました。

Astroはウェブフレームワークです。6.4.6より前のバージョンでは、プリレンダリングされたエラーページ（export const prerender = trueを使用した/404または/500）を持つAstro SSRアプリが、エラー発生時にランタイムでそれらのページをHTTP経由で取得します。この取得のURLはrequest.urlから派生し、request.urlは受信したHostヘッダーからオリジンを取得します。HostヘッダーがallowedDomainsと照合されない場合、攻撃者は取得先を任意のホストに向けてレスポンスを読み取ることが可能です。この脆弱性は6.4.6で修正されました。

n8nはオープンソースのワークフロー自動化プラットフォームです。2.25.7および2.26.2以前のバージョンでは、ワークフローの作成または変更権限を持つ認証ユーザーが、MergeノードのSQLクエリモードで使用されるサンドボックスを汚染する可能性がありました。サンドボックスコンテキストはインスタンス上のすべてのワークフロー実行でキャッシュされ再利用されていたため、あるユーザーのワークフローによって導入されたプロトタイプの変更が、他のユーザーやプロジェクトに属するその後のMerge SQL実行に持続的に影響を与えました。この問題により、権限の低い攻撃者が同じインスタンス上の他ユーザーが処理するワークフローデータを傍受する可能性がありました。この脆弱性はMergeノードのSQLクエリモードを含むワークフローの作成および実行権限を複数のユーザーが持つマルチユーザーのn8nインスタンスにのみ影響します。この脆弱性はバージョン2.25.7および2.26.2で修正されています。

n8nはオープンソースのワークフロー自動化プラットフォームです。バージョン2.24.0以前では、ワークフローの作成または変更権限を持つ認証済みユーザーが、Microsoft SQLノードに対して細工された値をtableパラメータとして提供することで、グローバルなプロトタイプ汚染を引き起こす可能性がありました。この汚染はn8nサーバープロセスの実行期間中にプロセス全体でObject.prototypeを汚染し、アプリケーション全体での検証が失敗する原因となり、n8nインスタンスを再起動するまで正常に機能しなくなります。この脆弱性はバージョン2.24.0で修正されました。

n8nはオープンソースのワークフロー自動化プラットフォームです。バージョン2.24.0より前では、ワークフローの編集権限を持つ認証ユーザーがMongoDBノードの「Find And Replace」操作に悪意のあるフィルタ値を提供することができました。この値はMongoDBにクエリフィルタとして渡される前に検証されておらず、意図しないドキュメントが一致し、攻撃者が制御する内容で上書きされる可能性がありました。この脆弱性はバージョン2.24.0で修正されました。

n8nはオープンソースのワークフロー自動化プラットフォームです。バージョン2.24.0以前のCompressionノードのDecompress操作では、解凍された出力サイズに制限がなく、攻撃者が制御するアーカイブをメモリ内に展開していました。認証されていない攻撃者がこのノードを使用する公開ウェブフックワークフローに小さな圧縮アーカイブを送信すると、メモリ不足によりn8nプロセスが終了し、同じインスタンス内のすべてのワークフローが中断される可能性があります。この脆弱性はバージョン2.24.0で修正されています。

Langflowは、AI搭載のエージェントおよびワークフローを構築・展開するためのツールです。バージョン1.0.19以前では、攻撃者が認証トークンやクッキーなしで/api/v1/files/upload/リクエストを送信し、非常に長いマルチパートフォームの境界を悪用することで、Langflowアプリを全ユーザーに対して無期限に使用不能にできる可能性がありました。この脆弱性はバージョン1.0.19で修正されました。

http-proxy-middlewareはNode.jsのhttp-proxyミドルウェアです。バージョン3.0.4から3.0.7および4.1.1まで、fixRequestBody()はボディパーサーによって既に消費されたリクエストボディを再送信するためのライブラリのドキュメント化されたヘルパーです。送信されるContent-Typeがmultipart/form-dataの場合、handlerFormDataBodyData()を使ってボディを再構築しますが、これは各req.bodyのキーと値をCR/LFを無効化せずにマルチパートのワイヤ形式に直接埋め込みます。値（またはキー）内の\r\nは攻撃者に現在のパートを閉じ、新しいフォームパートを完全に注入させることを可能にします。プロキシ自身のボディパーサーは単一の不透明な値を認識したため、ゲートウェイ側でreq.bodyに対して行われるポリシーや検証はアップストリームのバックエンドが最終的に解析するフィールドセットとは異なり、信頼境界を越えたリクエストやパラメータの非同期化が発生します。この脆弱性はバージョン3.0.7および4.1.1で修正されています。

Crawl4AIのバージョン0.8.8未満には、スクリーンショットおよびPDFエンドポイントに任意ファイル書き込みの脆弱性があります。この脆弱性により、認証されていない攻撃者がoutput_pathパラメータに対してシンボリックリンクおよびチェック時と使用時の時間差攻撃（TOCTOU）を利用し、意図されたディレクトリ外にファイルを書き込むことができます。リモートの攻撃者は不十分なパス検証およびシンボリックリンクの追従を悪用し、任意のファイル書き込みを行い、さらに実行可能ファイルやcronの場所への書き込み権限がある環境ではコードを実行する可能性があります。

Flowiseバージョン3.1.2以前には、/api/v1/chatflows/apikey/:apikeyエンドポイントに情報漏洩の脆弱性があります。keyonlyクエリパラメータが省略された場合（デフォルト設定）、このエンドポイントは提供されたAPIキーに紐付けられたチャットフローだけでなく、APIキーが割り当てられていないすべてのワークスペースのチャットフローも返します。これは基となるクエリにワークスペースフィルターが欠けているためです。したがって、あるワークスペースの有効なAPIキーを持つ攻撃者は、他のワークスペースに属する保護されていないチャットフローの完全なChatFlow構成（system promptsやノード構成を含むflowData、chatbotConfig、apiConfig、および資格情報ID）を取得できます。

Flowise 3.1.0未満のバージョンには、Execute Flowノードにサーバーサイドリクエスト偽装の脆弱性があります。この脆弱性により、攻撃者はbase URLフィールドにイントラネットのアドレスを指定してセキュリティ検証を回避できます。攻撃者はこれを悪用して内部ネットワークのアドレスにHTTPリクエストを送信し、クラウドのメタデータにアクセスしたり、httpSecurity.ts内のsecureFetchの検証不足を利用して内部サービスを列挙したりすることが可能です。

MISP Coreには、イベントレポートおよび共有グループの一括削除処理においてアクセス制御の欠陥がありました。影響を受けるdeleteSelectionハンドラーは、各選択オブジェクトの認可を検証する代わりに、広範なロールレベルの権限で削除を許可していました。イベントレポートに関しては、EventReportsController::deleteSelectionはレポートごとの所有権や認可チェックを行わず、グローバルなperm_add権限に依存していました。そのため、寄稿者レベルのユーザーが他組織のレポートIDまたはUUIDを送信し、インスタンス全体でハード削除できる状態でした。修正により削除前に各選択レポートについてEventReport::fetchIfAuthorized($user, $itemId, 'delete')が呼ばれるようになりました。共有グループに関しては、SharingGroupsController::deleteSelectionが各選択共有グループの所有権を検証せず、グローバルなperm_sharing_group権限に依存していました。これにより、共有グループ権限を持つユーザーが他組織の共有グループをハード削除でき、単一オブジェクト削除時に使用される所有権ゲートを回避していました。修正で各選択共有グループに対しSharingGroup::checkIfOwner($user, $itemId)が呼ばれるように変更されました。認証済みで該当の広範なロール権限を持つ攻撃者は、影響を受ける一括削除エンドポイントを悪用し、自組織の認可範囲外のオブジェクトを削除できるため、インスタンス全体でイベントレポート内容や共有グループ設定が失われる可能性があります。

MISPコアには複数のアクセス制御の不具合があり、認可チェックが誤ったエンティティに対して実行されることや、書き込み経路で所有権および編集権のチェックが欠如していました。影響を受けるサブシステムでは、関連する機能権限を持つ権限の低い認証済みユーザーが、あるオブジェクトの認可を受けていながら別のオブジェクトを変更したり、ユーザーの組織が閲覧可能だが編集権限のないオブジェクトを変更することが可能でした。影響を受けるパスは以下の通りです。 * イベントレポートのタグ削除：ルート認可されたレポートとタグ解除に使用されるレポートIDが異なり、別組織の他のイベントレポートからタグを削除できました。 * コレクション要素の一括削除：一括削除がコレクション要素の行IDと一致するコレクションIDに対して認可されており、要素の親コレクションのIDではなかったため、ユーザーが所有していないコレクションから要素を削除できます。 * アナリストデータの取得・更新：入れ子になったアナリストデータの更新がcanEditAnalystDataの所有権チェックを適用せずに既存レコードを上書きでき、組織間でアナリストデータレコードを上書き可能でした。 * テンプレート要素の編集：テンプレート要素のIDと一致するテンプレートに対して編集が認可されていましたが、実際の親テンプレートではなかったため、別組織のテンプレート要素を不正に編集できました。 * 減衰モデルの編集およびマッピング：書き込み経路がビュー・スコープのアクセスを使ってモデルを読み込んでいたものの編集所有権を確認せず、別組織が所有する表示可能なモデルを編集または再マッピングできました。 これらの不具合を悪用すると、特定サブシステムの権限を持つ認証済みユーザーがMISPデータの組織間で不正な変更や削除を行い、整合性を喪失させ、共有インテリジェンスの不正改ざんやアナリストのワークフロー混乱を引き起こす可能性があります。

MISPは、サイト管理者がJsonLogToolで使用されるNDJSONエラーログの任意のファイルシステムパスを設定できるようにしていました。ログエントリには攻撃者が制御する内容が含まれる可能性があるため、認証されたサイト管理者権限を持つ攻撃者は、ログ出力をWebアクセス可能なディレクトリ内のPHPファイルに向けてログデータを通じてPHPコードを注入できました。生成されたファイルにアクセスすると、Webサーバープロセスの権限でリモートコード実行が発生する可能性があります。修正によって、ログの出力先はAPP/tmp/logsまたは/var/log以下の既存ディレクトリに制限され、絶対パスが必須となりました。また、ストリームラッパーおよびトラバーサルに関連する入力が拒否され、ファイル名は.logまたは.ndjson拡張子に限定され、実行可能な拡張子のセグメントは許可されなくなりました。

MISPは認証されたサイト管理者にKafka_rdkafka_config設定を任意のファイルシステムパスに設定させることを許可していました。MISPはその後、参照されたINIファイルを解析し、そのオプションをrdkafkaに渡していました。作成された攻撃者制御の設定ファイルは、plugin.library.pathsのようなrdkafkaオプションを使用して外部ライブラリを読み込み、結果としてMISPプロセスの権限で任意のコードを実行させる可能性があります。攻撃者はアップロードファイルや管理用画像など、MISPが書き込み可能な場所を利用して悪意のある設定ファイルをホストする可能性があります。問題は、設定をウェブルートおよびMISPアップロードターゲット外の認可された設定ディレクトリ内の絶対パス.iniファイルのみに制限することで修正されました。

Jenkins Assemblaプラグイン1.4およびそれ以前のバージョンは、XML外部実体（XXE）攻撃を防ぐようにXMLパーサーを適切に構成していません。そのため、攻撃者は構成されたAssemblaサーバーの応答を制御し、Jenkinsコントローラーから秘密情報を抽出したり、サーバー側リクエスト偽造（SSRF）を実行したりすることが可能です。

IBM WebSphere Application Server および IBM WebSphere Application Server Liberty は、WebSphere Web Server プラグインコンポーネントにおいてリモートコード実行およびサービス拒否を引き起こす脆弱性を有しています。この脆弱性は、攻撃者がアプリケーションサーバーになりすまし、プラグインに細工された応答を送信することで悪用される可能性があります。

IBM WebSphere Application Server 9.0および8.5、ならびにIBM WebSphere Application Server - Liberty 17.0.0.3から26.0.0.6には、特別に細工されたリクエストを送信することで引き起こされるサービス拒否の脆弱性があります。リモートの攻撃者はこの脆弱性を悪用して、サーバーのメモリリソースを消費させることが可能です。

IBM WebSphere Application Server 9.0、および8.5、ならびにIBM WebSphere Application Server - Liberty 17.0.0.3から26.0.0.6には、特別に細工されたリクエストの送信によりサービス拒否の脆弱性があります。リモートの攻撃者はこの脆弱性を悪用して、サーバーのメモリリソースを消費させることが可能です。

Flowise のバージョン 3.0.10 未満（特に 3.0.7 以前のバージョン）には、未確認のメールアドレス変更の脆弱性があります。認証済みユーザーは、元のメールアドレスの確認や現在のパスワードの再入力を行わずに、アカウントプロフィールエンドポイントを使ってログイン識別子およびパスワード回復チャネルとして使用されるアカウントのメールアドレスを変更できます。回復用メールアドレスを変更すると、攻撃者はアカウントを乗っ取り、パスワードリセット機能を悪用できます。

IBM WebSphere Application Server 8.5および9.0には、リモートの攻撃者が認証を回避してJAX-WSアプリケーションに不正アクセスを行う可能性があります。

BerriAI litellm バージョン 1.59.8 までに脆弱性が確認されました。影響を受けるコンポーネントは MCP Proxy のファイル litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py 内の UserAPIKeyAuth 関数です。この関数で操作を行うと不適切な認証につながる可能性があります。この攻撃はリモートから実行される可能性があります。エクスプロイトは既に公開されており、攻撃に利用される恐れがあります。ベンダーにはこの脆弱性の開示について早期に連絡済みです。

BerriAI litellm バージョン 1.82.2 までに脆弱性が確認されました。この脆弱性はコンポーネント SSO Debug Flow のファイル litellm/proxy/management_endpoints/ui_sso.py 内の関数 json.dumps に影響を与えます。この問題により、操作を実行した際に認証が省略される可能性があります。この攻撃はリモートで実行可能であり、エクスプロイトは公開されているため悪用される恐れがあります。ベンダーには早期に本脆弱性の開示が通知されています。

Google Chromeの149.0.7827.197より前のバージョンのWeb認証におけるUse after freeの脆弱性により、悪意のある拡張機能のインストールをユーザーに促し、攻撃者が細工されたChrome拡張機能を介してヒープ破損を悪用する可能性がありました。

Google Chrome 149.0.7827.197 未満の Blink において、Use after free の脆弱性により、リモートの攻撃者が細工された HTML ページを介してサンドボックス内で任意のコードを実行できる可能性がありました。Chromium のセキュリティ上の深刻度は高いと評価されています。

Google Chromeのバージョン149.0.7827.197以前のBlinkにおけるInterestGroupsでの境界外読み取りおよび書き込みの脆弱性により、リモートの攻撃者が細工されたHTMLページを介して任意のコードを実行する可能性がありました。

Mac上のGoogle Chrome 149.0.7827.197以前のバージョンにおけるBluetoothのUse after freeの脆弱性により、リモートの攻撃者が悪意のある周辺機器を介して任意のコードを実行できる問題が報告されています。

Google Chromeの149.0.7827.197以前のBlinkにおけるUse after freeの脆弱性により、リモート攻撃者が細工されたHTMLページを介してサンドボックス内で任意のコードを実行できる可能性がありました。

Android版Google Chromeのバージョン149.0.7827.197より前のWebViewに存在するUse after freeの脆弱性により、ローカルの攻撃者が細工されたHTMLページを介してサンドボックス内で任意のコードを実行できる可能性がありました。

Windows上のGoogle Chromeバージョン149.0.7827.197以前のAutofill機能でUse after freeの脆弱性が存在し、リモートの攻撃者が細工されたHTMLページを介して任意のコードを実行する可能性がありました。

Cactiはオープンソースのパフォーマンスおよび障害管理フレームワークです。バージョン1.2.30以前には、Reports機能のgraph_name_regexpを通じて保存されたSQLインジェクションの脆弱性が存在していました。この問題はバージョン1.2.31で修正されました。

vLLMは大規模言語モデル（LLM）の推論およびサービングエンジンです。0.22.0より前のバージョンでは、vLLMの活性化関数読み込みにおけるassertベースのセキュリティチェックによって、認証されていない攻撃者が悪意のあるHuggingFaceモデルを公開することで、vLLMがPython最適化モード（python -OまたはPYTHONOPTIMIZE=1）で実行されている場合にサーバー上で任意のコードを実行される脆弱性が存在していました。この脆弱性は0.22.0で修正されています。

n8nはオープンソースのワークフロー自動化プラットフォームです。バージョン1.123.43、2.22.1、および2.20.7より前のバージョンでは、ワークフローの作成または変更権限を持つ認証済みユーザーがGitノードのプッシュ操作でCLIフラグを注入できました。その結果、攻撃者はn8nサーバーから任意のファイルを読み取ることが可能となり、最悪の場合は完全な侵害につながる可能性がありました。この脆弱性はバージョン1.123.43、2.22.1、および2.20.7で修正されています。

Apache NiFi 1.2.0から2.9.0に含まれるCaptureChangeMySQLプロセッサで、データベーステーブル名の不適切なエスケープにより、特別に作成した名前を使ってSQLコマンドを注入できる可能性があります。Apache NiFi 1.8.0では手動による引用符境界の追加により潜在的な注入リスクが減少しましたが、追加の攻撃手法には対応していません。CaptureChangeMySQLプロセッサを使用していないApache NiFiのインストール環境は、この脆弱性の影響を受けません。より堅牢な識別子エスケープを取り入れたApache NiFi 2.10.0へのアップグレードを推奨する緩和策です。