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

Open WebUIは完全にオフラインで動作するセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、Open WebUIはbase_model_idを介してモデルの構成をサポートしていました。ユーザー定義のモデル（例：「Cheap Assistant」）は、実際の推論能力を提供する既存のベースモデル（例：「gpt-4-turbo-restricted」）を参照できます。ユーザーが構成モデルにクエリを送信すると、アクセス制御パイプラインはユーザーが構成モデルへのアクセス権を持っていることを検証しますが、連鎖されたベースモデルへのアクセス権を再検証しません。さらに、モデル作成およびインポートのエンドポイントは、呼び出し元がそのベースモデルへのアクセス権を持っているかどうかを確認せずに任意のbase_model_id値を受け入れます。これにより、デフォルトのモデル作成権限を持つ任意のユーザーが制限付きベースモデルに連鎖するモデルを作成し、それを呼び出してサーバーに管理者設定済みのAPIキーを使って制限付きベースモデルへのリクエストを発行させることが可能になります。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは、完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、OpenAIルーターの/responsesエンドポイントが認証された任意のユーザーからのリクエストを受け入れ、モデルごとのアクセス制御を行わずにリクエストを上流のLLMプロバイダーに直接転送していました。主要なチャット完了エンドポイント（generate_chat_completion）は、リクエストを許可する前にモデルの所有権、グループメンバーシップ、およびAccessGrantsを確認しますが、/responsesプロキシは有効なセッションを持つユーザーであることのみをget_verified_userを通じて検証しています。これにより、認証された任意のユーザーが任意のモデルIDを指定して/api/openai/responsesにPOSTリクエストを送ることで、インスタンス上に設定された任意のモデルと対話できる状態になっていました。この脆弱性はバージョン0.9.0で修正されています。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.6.19より前では、メモリーズAPIに対する認可制御が一貫しておらず、標準ユーザーが他のユーザーのメモリを削除、復元、および内容を閲覧できる状態でした。既存のメモリを持たない新規作成の非管理者ユーザーを使用すると、POST /api/v1/memories/query経由で既存のメモリを閲覧可能でした。同様に、非管理者ユーザーがPOST /api/v1/memories/{memory_id}/updateを介して他ユーザーのメモリデータを変更できなくても、有効なmemory_idが判明している場合、このエンドポイントのレスポンスは該当メモリの内容を不適切に漏洩しました。DELETE /api/v1/memories/{memory_id}はどのユーザーでも既存のメモリを削除するために利用可能であり、削除されたメモリはPOST /api/v1/memories/{memory_id}/updateエンドポイントを再度呼び出すことで復元できました。この脆弱性はバージョン0.6.19で修正されています。

Open WebUIは完全にオフラインで動作するよう設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前には、保存されたクロスサイトスクリプティング（XSS）脆弱性が存在していました。モデル作成権限（workspace.models）を持つ認証済みユーザーは、チャットUIで悪意のあるモデルを閲覧する他のユーザー（管理者を含む）のブラウザ上で任意のJavaScriptを実行できる可能性がありました。この脆弱性はバージョン0.9.0で修正されています。

Open WebUIは完全にオフラインで動作するよう設計されたセルフホスト型の人工知能プラットフォームです。0.3.16以前のバージョンでは、すべてのファイル関連APIエンドポイントに権限チェックが欠如しており、認証された任意のユーザーがプラットフォームにアップロードされたすべてのファイルを一覧表示、アクセス、および削除できる状態になっていました。この脆弱性は0.3.16で修正されました。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.6.5以前では、HTMLレンダリングビューを通じてスクリプトを注入および実行することが可能でした。フロントエンドは、現在のチャットのHTMLコンテンツを可視化する機能を提供しています。このコンテンツは、allow-scripts、allow-forms、allow-same-originのsandboxディレクティブが設定されたiFrameに埋め込まれています。これはコンテンツがサンドボックス内に配置されているものの、スクリプトの実行や親のデータ（例えばローカルストレージ）へのアクセスが許可されていることを意味します。その結果、アラートボックスの表示など一部の機能のみが制限されますが、sandbox属性の効果は実質的にほとんど無効化されています。この脆弱性はバージョン0.6.5で修正されました。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.9.3以前では、音声文字起こしのアップロードエンドポイントがユーザー提供のファイル名から拡張子を取得し、ファイルをCACHE_DIR/audio/transcriptions/に保存していました。/cache/{path}ルートはこれらのファイルをFileResponseを介して提供し、Content-Typeはディスク上の拡張子から設定されていましたが、Content-Dispositionは送信されませんでした。デフォルトで有効なchat.stt権限を持つ認証済みユーザーは、pwn.htmlという名前の多言語対応WAV+HTMLファイルをアップロードし、他のユーザーに結果のURLを開かせて騙すことが可能でした。レスポンスはtext/htmlとして返され、埋め込まれたscriptがOpen WebUIのオリジンで実行されます。この脆弱性はバージョン0.9.3で修正されています。

Open WebUIは完全にオフラインで動作するよう設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、backend/open_webui/retrieval/web/utils.py内のvalidate_url()関数がvalidators.ipv6(ip, private=True)を呼び出していましたが、validatorsライブラリはIPv6に対してprivateキーワードを実装していません。そのため、この呼び出しはValidationErrorを発生させます（これはブール文脈では偽とみなされるため）、IPv6アドレスはすべてフィルターを通過してしまいます。さらに、IPv4マップドIPv6アドレス(::ffff:10.0.0.1)はIPv4チェックを完全に回避し、いくつかの予約済みIPv4範囲(0.0.0.0/8、100.64.0.0/10、192.0.0.0/24など)もブロックされませんでした。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、backend/open_webui/utils/oauth.pyの_process_picture_url()関数（約1338行目）にサーバーサイドリクエストフォージェリ（SSRF）の脆弱性が存在していました。この関数はOAuthの画像クレームから任意のURLをvalidate_url()で検証せずに取得するため、攻撃者はサーバーに内部リソースへのHTTPリクエストを強制して、完全なレスポンスを盗み出すことが可能でした。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、ユーザーが自分のAPIキー（OWUIで生成）と他のユーザーのチャットIDを使用してAPIエンドポイント/api/chat/completionsにアクセスすることで、他のユーザーの会話を継続できる状態でした。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.8.6以前にはチャット完了APIに脆弱性が存在し、攻撃者がツール制限を回避して許可されていない操作やアクセスを可能にする恐れがありました。chat_completion APIでは、tool_idsおよびtool_serversのパラメータがユーザーから提供されます。これらのパラメータはミドルウェアによってtools_dictを作成するために使用され、get_tool_by_idによって適切なツールを取得します。しかし、このAPIを使用するユーザーがそのツールを使用する許可を持っているかどうかを確認するチェックがありません。そのため、ユーザーはchat completion APIを介して正しいtool_idまたはtool_serversパラメータを提供することで任意のサーバーツールを呼び出すことが可能です。さらに、ツールの呼び出し時にはサーバーに保存された認証トークンが使用されるため、ツールはサーバーの特権で呼び出されます。この脆弱性はバージョン0.8.6で修正されました。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.9.5以前では、ツール更新エンドポイント(POST /api/v1/tools/id/{id}/update)において、ツール作成エンドポイントに存在するworkspace.toolsの権限チェックが欠如していました。これにより、明示的にツール管理権限が拒否されているユーザー（管理者がコード実行の観点から信頼していないユーザー）が、ツールのサーバー側Pythonコンテンツを置き換え、意図されたworkspace.toolsのセキュリティ境界を回避して実行をトリガーできる状態でした。この脆弱性はバージョン0.9.5で修正されています。

Open WebUIは完全にオフラインで動作するよう設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、低権限の認証済みユーザーがGET /api/tasksおよびPOST /api/tasks/stop/{task_id}メソッドを通じてシステム全体のアクティブなバックグラウンドタスクを列挙し、他のユーザーのタスクを停止できました。これにより、一般ユーザーが継続的に他ユーザーのアクティブなタスクをキャンセルし、システム全体のチャット利用を妨害することが可能でした。この脆弱性はマルチユーザー環境の整合性と可用性に影響を与える重大な認可欠陥です。なお、この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.9.5以前では、複数のエンドポイントがユーザー提供のfile_idを受け取り、呼び出し元が所有しているかアクセスを許可されているかを検証せずに参照されたファイルを呼び出し元が管理するリソース（フォルダ知識、知識ベースのコンテンツ）に添付していました。これにより、そのファイルの内容が下流のRAG / file-content経路を通じてアクセス可能となり、認証された任意のユーザーが他のユーザーのプライベートファイルをUUIDを知っているだけで持ち出すことができました。さらに、知識ベース経路では上書きも可能でした。この脆弱性はbackend/open_webui/routers/folders.py（POST /api/v1/folders/{id}/update）、backend/open_webui/routers/knowledge.py（add_file_to_knowledge_by_id）、およびbackend/open_webui/routers/knowledge.py（add_files_to_knowledge_by_id_batch）に影響を与えます。この脆弱性はバージョン0.9.5で修正されました。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.8.0以前では、不適切なサニタイズ処理の順序（具体的には、DOMPurifyがmarkedライブラリの前に実行される）により、バナーコンポーネントに永続的なクロスサイトスクリプティング（Stored XSS）の脆弱性が存在していました。この脆弱性により、権限を持つ、もしくは悪意のある管理者がグローバルバナーに悪意あるペイロードを仕込むことが可能です。特に、この攻撃経路は権限昇格を可能にし、悪意あるバナーはスーパ管理者（プライマリアドミン）を含む全ユーザーに表示されます。その結果、ペイロードは既存のセキュリティ機構を回避します。攻撃者はこれを利用してスーパ管理者のセッショントークンを盗むことが可能です。この脆弱性はバージョン0.8.0で修正されています。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、認証された任意のユーザーがDELETE /api/v1/files/{id}を介して、共有チャット内で参照されている他のユーザー所有のファイルを永久に削除できました。has_access_to_file()の認可ゲートは、その共有チャットのブランチで無条件にアクセスを許可しており、要求ユーザーの身元や実行される操作の種類を確認していません。ファイルのUUID（通常は推測が困難なもの）は、GET /api/v1/knowledge/{id}/filesを介してナレッジベースへの読み取りアクセス権を持つ任意のユーザーに公開されています。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、LDAPおよびOAuth認証のフローにおいて、初回ユーザーに管理者ロールを割り当てる際にTOCTOU（チェック時と使用時のタイミングの不一致）パターンが存在していました。通常のサインアップハンドラー（auths.pyの663行目のsignup_handler）には、「TOCTOU競合を回避するために最初にデフォルトロールで挿入する」というコメント付きで明示的にこの競合を防ぐパッチが適用されていましたが、LDAPおよびOAuthのコードパスには同様の修正が適用されていませんでした。この脆弱性はバージョン0.9.0で修正されました。

Fleetはオープンソースのデバイス管理ソフトウェアです。バージョン4.80.1より前のFleetにはIP抽出ロジックに脆弱性があり、認証されていない攻撃者がクライアントのIPヘッダーを偽装することでAPIのレート制限を回避できます。これにより、パブリックインターネットに公開されているFleetインスタンスに対してブルートフォースログイン試行やその他の悪用が可能となります。Fleetはリクエストヘッダー（`True-Client-IP`、`X-Real-IP`、`X-Forwarded-For`）からクライアントIPアドレスを抽出していますが、これらのヘッダーが信頼できるプロキシから発信されたものであるかどうかを検証していません。抽出されたIPはレート制限およびIP禁止の決定のキーとして使用されます。その結果、攻撃者はこれらのヘッダーの値をリクエストごとに変更でき、Fleetは各試行を異なるクライアントからのものとみなします。これにより、ログインAPIなどの機密性の高いエンドポイントに対するIPごとのレート制限を実質的に回避でき、無制限のブルートフォースやクレデンシャルスタッフィング攻撃が可能となります。この問題は、転送IPヘッダーを上書きするリバースプロキシなしで直接インターネットに公開されているFleetインスタンスに主に影響します。適切に設定されたプロキシやWAFの背後にあるインスタンスへの影響は少ないです。バージョン4.80.1で修正されました。すぐにアップグレードできない場合、管理者はFleetを`X-Forwarded-For`ヘッダーを真のクライアントIPに上書きするリバースプロキシ（例：nginx、Cloudflare、AWS ALB）の背後に展開し、プロキシやWAFレイヤーでレート制限を適用することを推奨します。

Mattermostのバージョン11.5.x = 11.5.1、10.11.x = 10.11.13、11.4.x = 11.4.3では、サポートパケット生成時に機密構成フィールドが適切にサニタイズされないため、Mattermostシステム管理者やサポートパケットにアクセスできる者がシステムコンソールからサポートパケットをダウンロードすると、機密資格情報をプレーンテキストで取得できる可能性があります。

Mattermostのバージョン11.5.x（11.5.1以下）、10.11.x（10.11.13以下）、および11.4.x（11.4.3以下）には、Mattermost Callsプラグインの機密設定フィールドを適切にサニタイズしない脆弱性が存在します。この脆弱性により、サポートパケットへのアクセス権を持つ攻撃者が、エクスポートされたプラグイン設定に含まれる平文の値を通じてTURNサーバーの資格情報を取得できます。

複数のPostgreSQLサーバー機能における整数オーバーフローにより、特権を持たないデータベースユーザーがサーバーに対して割り当てサイズを過小評価させ、境界外への書き込みを引き起こす可能性があります。これにより、データベースを実行しているオペレーティングシステムのユーザー権限で任意のコードを実行できる場合があります。ギガバイト規模のユーザー入力を該当するデータベース関数に渡すアプリケーションでは、入力提供者がセグメンテーションフォルトを引き起こすことがあります。PostgreSQLの18.4、17.10、16.14、15.18、および14.23より前のバージョンがこの問題の影響を受けます。

PostgreSQLのpg_basebackupのプレーン形式およびpg_rewindにおけるシンボリックリンク追跡の脆弱性により、オリジンスーパーユーザーがローカルファイル（例：/var/lib/postgres/.bashrc）を上書きし、オペレーティングシステムのアカウントを乗っ取る可能性があります。これらのコマンドの実行後にサーバーを起動する際には、shared_preload_librariesのような機能によりオリジンスーパーユーザーが暗黙的に信頼される状態が続きます。したがって、この攻撃が実際的な意味を持つのは、これらのコマンドの実行とサーバー起動の間に、ファイルを異なるVMに移動するかVMのスナップショットを取るなどの適切な対策を講じた場合に限られます。影響を受けるバージョンはPostgreSQL 18.4未満、17.10未満、16.14未満、15.18未満、および14.23未満です。

PostgreSQLのpg_createsubscriberにおけるSQLインジェクションにより、pg_create_subscription権限を持つ攻撃者はスーパーユーザーとして任意のSQLを実行できます。この攻撃はpg_createsubscriberが次回実行された際に効果を発揮します。メジャーバージョン17および18のうち、PostgreSQL 18.4および17.10より前のマイナーバージョンが影響を受けます。PostgreSQL 17より前のバージョンは影響を受けません。

PostgreSQLのlibpqのlo_export()、lo_read()、lo_lseek64()、およびlo_tell64()関数において、本質的に危険な関数PQfn(..., result_is_int=0, ...)の使用により、サーバーのスーパーユーザーがクライアントのスタックバッファを任意の大きさのレスポンスで上書きすることが可能です。gets()と同様に、PQfn(..., result_is_int=0, ...)は任意の長さのサーバーが決定したデータを未指定のサイズのバッファに格納します。psqlの\lo_exportコマンドとpg_dumpの両方がlo_read()を呼び出すため、サーバースーパーユーザーはpg_dumpまたはpsqlのスタックメモリを上書きできます。PostgreSQLのバージョン18.4未満、17.10未満、16.14未満、15.18未満および14.23未満が影響を受けます。

PostgreSQLのSSLおよびGSSネゴシエーションにおける制御されていない再帰により、PostgreSQLのAF_UNIXソケットに接続可能な攻撃者が持続的なサービス拒否を引き起こす可能性があります。SSLとGSSが両方無効化されている場合、攻撃者はPostgreSQLのTCPソケットにアクセスすることで同様の攻撃を行うことができます。対象となるバージョンはPostgreSQL 18.4、17.10、16.14、15.18、および14.23以前です。

PostgreSQLのモジュール「refint」におけるスタックバッファオーバーフローの脆弱性により、権限のないデータベースユーザーが、データベースを実行しているオペレーティングシステムのユーザー権限で任意のコードを実行できる可能性があります。アプリケーションがユーザー制御のカラムを「refint」のカスケード主キーとして宣言し、そのカラムへのユーザー制御の更新を許可すると、異なる攻撃が可能になります。この場合、SQLインジェクションにより、主キーの更新値の提供者が主キー更新を行うデータベースユーザーとして任意のSQLを実行できます。影響を受けるバージョンはPostgreSQL 18.4、17.10、16.14、15.18、および14.23より前のバージョンです。

PostgreSQLの論理レプリケーションにおけるALTER SUBSCRIPTIONのREFRESH PUBLICATIONにSQLインジェクションの脆弱性があります。そのため、サブスクライバのテーブル作成者がサブスクリプションのパブリケーション側の認証情報を使用して任意のSQLを実行できる可能性があります。この攻撃は次回のREFRESH PUBLICATION実行時に効果を発揮します。メジャーバージョン16、17、および18のうち、PostgreSQL 18.4、17.10、および16.14より前のマイナーバージョンが影響を受けます。なお、PostgreSQL 16より前のバージョンには影響がありません。

MongoDBサーバーの時系列コレクション実装における問題により、データベースの書き込み権限を持つ認証ユーザーがmongodプロセス内で境界外メモリ書き込みを引き起こす可能性があります。この問題は、時系列バケットカタログ内の内部フィールド名からインデックスへのマッピングが不整合になることが原因です。特定の条件下で、これにより任意のコードが実行される可能性があります。この問題は、MongoDBサーバーのv5.0系では5.0.33未満、v6.0系では6.0.28未満、v7.0系では7.0.34未満、v8.0系では8.0.23未満、v8.2系では8.2.9未満、v8.3系では8.3.2未満のバージョンに影響を与えます。

Google Chromeの148.0.7778.168以前のWebMLにおけるヒープバッファオーバーフローの脆弱性により、リモートの攻撃者が細工されたHTMLページを介してサンドボックス内で任意のコードを実行する可能性があります。

Google Chromeの148.0.7778.168以前のバージョンのFileSystemにおけるUse after freeの脆弱性により、特定のUIジェスチャーを実行するようユーザーを騙したリモートの攻撃者が、細工されたHTMLページを介してサンドボックスを脱出する可能性がありました。

Google Chromeの148.0.7778.168より前のバージョンのAuraにおけるUse after freeの脆弱性により、レンダラープロセスを乗っ取ったリモート攻撃者が、細工されたHTMLページを介してサンドボックスから脱出できる可能性がありました。

Google Chrome のバージョン 148.0.7778.168 より前の HID における Use after free の脆弱性により、リモートの攻撃者が特定の UI ジェスチャーをユーザーに実行させることで、細工された HTML ページを介してサンドボックスから脱出できる可能性がありました。

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

Google Chromeの148.0.7778.168より前のバージョンにおいて、Paymentsの競合状態が原因で、リモートの攻撃者が細工されたHTMLページを介してサンドボックスを脱出できる可能性がありました。

Google Chromeの148.0.7778.168より前のバージョンのタブグループにおけるUse after freeの脆弱性により、リモートの攻撃者が悪意のあるネットワークトラフィックを介して任意のコードを実行できる可能性がありました。

Google Chromeの148.0.7778.168以前のバージョンにおけるMojoのUse after freeの脆弱性により、リモート攻撃者が細工されたHTMLページを介してレンダラープロセスを侵害し、サンドボックスを脱出できる可能性がありました。

Google Chromeの148.0.7778.168以前のバージョンにおけるWeb Audioの範囲外書き込みの脆弱性により、リモートの攻撃者が細工されたHTMLページを介してサンドボックス内で任意のコードを実行できる問題です。

Google Chrome 148.0.7778.168より前のバージョンのWebRTCにおける境界外書き込みの脆弱性により、リモートの攻撃者が細工されたHTMLページを介してサンドボックス内で任意のコードを実行できるようになりました。

Google Chromeの148.0.7778.168以前のバージョンにおいて、Downloadsの信頼されていない入力の検証が不十分であったため、リモートの攻撃者が細工されたHTMLページを介して任意のコードを実行する可能性がありました。この脆弱性はChromiumセキュリティで高く評価されています。

148.0.7778.168以前のGoogle ChromeのCodecsにおけるヒープバッファオーバーフローにより、リモートの攻撃者が細工された動画ファイルを介してサンドボックス内で任意のコードを実行する可能性がありました。