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

GotenbergはPDFファイル用のDockerベースのステートレスAPIです。バージョン8.32.0より前のFilterOutboundURLはホスト名を解決し、その解決されたIPをプライベートアドレスの拒否リストと照合してエラーのみを返し、解決されたアドレスを破棄していました。Chromiumはその後、URLにナビゲートする際に独自のDNS解決を行います。攻撃者が短いTTLのホスト名のDNSを制御している場合、最初のクエリでパブリックIPを返し（Gotenbergはこれを許可します）、2回目のクエリでプライベートIPを返します（Chromiumは攻撃者が選択した内部アドレスに接続します）。CDPのFetch.requestPausedハンドラはURLを再確認しますが、独自のDNS解決を実行するため、Chromiumの実際のTCP接続が行われる前にタイミングの隙間が生じます。レンダリングされた内部サービスの応答はPDFとして呼び出し元に返されます。この脆弱性はバージョン8.32.0で修正されました。

GotenbergはPDFファイル用のDockerベースのステートレスAPIです。8.32.0以前のバージョンでは、pdfengines/merge、pdfengines/split、libreoffice/convert、chromium/convert/url、chromium/convert/html、およびchromium/convert/markdownが匿名の呼び出し元からstampSource=pdf + stampExpression=/pathおよびwatermarkSource=pdf + watermarkExpression=/pathを受け入れていました。専用のスタンプ/ウォーターマークルートは、ソースタイプが画像またはPDFの場合にアップロードされたファイルを必要としますが、これら6つのルートはファイルがアップロードされた場合のみ式を上書きし、ファイルが添付されていないときはユーザー制御のパスをそのままにします。pdfcpuはそのパスを開き、そのページを出力PDFに合成して呼び出し元に返しました。攻撃者はGotenbergプロセスがコンテナ内のファイルシステムでアクセス可能な任意のPDFを読み取ることが可能でした。この脆弱性は8.32.0で修正されました。

GotenbergはPDFファイルのためのDockerベースのステートレスAPIです。バージョン8.32.0以前の/forms/chromium/convert/urlおよび/forms/chromium/screenshot/urlルートは、匿名の呼び出し元からurl=file:///tmp/...を受け入れていました。デフォルトのChromiumの拒否リストは意図的にfile:///tmp/を除外しており、HTML/Markdownルートが自身のリクエストのローカル資産を読み込めるようにしています。また、それらのルートはリクエストごとにAllowedFilePrefixesガードを適用し、読み取りの範囲を制限しています。しかし、URLルートはAllowedFilePrefixesを設定しないため、このスコープガードを静かにスキップしてしまいます。これにより、攻撃者は/tmp/を列挙し、Gotenbergのリクエストごとの作業ディレクトリを辿って他の進行中の変換の元ファイルをレンダリング済みPDF出力として読み取ることが可能になります。本脆弱性はバージョン8.32.0で修正されました。

Mattermostのバージョン11.5.xから11.5.1および10.11.xから10.11.13において、プレイブックの更新時に{{team_id}}が変更されているかどうかの確認が行われていません。そのため、{{Manage Playbook Configurations}}権限のみを持つユーザーがプレイブックのチームを変更することが可能です。この脆弱性により、PUT APIを利用してメンバー管理制限を回避できます。MattermostアドバイザリIDはMMSA-2025-00552です。

Linuxカーネルにおいて、x86/kexecのload_segments()実行後にKCOV計測が無効化される問題が修正されました。この関数はセグメントレジスタやGSベースを変更し、CONFIG_KCOVが有効な場合には計測付きコード呼び出しでカーネルが無限ループに陥る原因となっていました。問題の再現はKCOV対応カーネルでのkexec実行で簡単に可能です。特に、syzkallerのクラッシュダンプ収集でCONFIG_KEXECとCONFIG_KCOVが同時に有効な状況で顕著に現れていました。KCOVの高速パスに直接安全策を加えるとパフォーマンスに悪影響が出るため、該当するカーネルコード全体でKCOV計測を無効化しました。将来的にこれらのコンポーネントがカバレッジ誘導型ファズィングに必要となる場合は、別の対策が求められます。CONFIG_KCOV非対応の32ビットカーネルには影響がありません。

Linuxカーネルにおいて、以下の脆弱性が修正されました：usb:gadget:f_rndisにおいて、RNDISオプションをミューテックスで保護します。クラス、サブクラス、プロトコルのオプションはconfigfsを通じて同時にアクセスされるため、競合状態が発生しやすいです。既存のミューテックスを使用してこれらのオプションを保護しました。この問題はコード検査中に特定されました。

Linuxカーネルにおいて、usb: gadget: f_subsetのgeth_free関数に存在した参照カウントの不均衡に関する脆弱性が修正されました。具体的には、geth_alloc()は参照カウントを増加させますが、geth_free()は適切に減少させていませんでした。この問題により、関数のリンク解除後にconfigfsを介した属性の設定が妨げられていました。現在は、適切なクリーンアップを確実に行うために、geth_free()で参照カウントを正しく減少させるように修正されています。

Linuxカーネルにおいて、以下の脆弱性が修正されました。perf/x86/intel/uncoreにおけるdie IDの初期化および検索のバグを修正しました。snbep_pci2phy_map_init()関数のnr_node_idsが8を超える経路において、すべてのCPUがオフラインである場合に、uncore_device_to_die()が-1を返すことがあります。WARN_ON_ONCE(die_id == -1)のチェックを削除した理由は2点あります。1点目は、現在のコードがループを途中で抜けてしまい、pci_get_device()がドメインやバスの順序での反復を保証しないため、スキャン中に追加のUBOXデバイスがスキップされる可能性があるからです。2点目は、-EINVALを返すのは誤りであり、die_id == -1でオフラインバスをマークすることは想定されており、エラーとして扱うべきではないからです。さらに、NUMAがNUMA対応プラットフォームで無効化されている場合において、pcibus_to_node()はNUMA_NO_NODEを返し、uncore_device_to_die()はすべてのPCIデバイスに対して-1を返します。その結果、Intel SPRおよびEMRで使用されるspr_update_device_location()は対応するPMONユニットを無視し、それらをRBツリーに追加しません。本問題は、UBOXのGIDNIDMAPレジスタからトポロジーを取得し、LinuxでNUMAが有効か無効かに関係なく動作するuncore_pcibus_to_dieid()を使用することで修正されました。これにより、snbep_pci2phy_map_init()をspr_uncore_pci_init()に追加する必要があります。uncore_device_to_die()は、NUMAが有効であることが期待されるnr_node_idsが8を超える場合のみに保持されます。

pyLoadはPythonで書かれた無料かつオープンソースのダウンロードマネージャーです。0.5.0b3.dev100より前のバージョンでは、pyload-ngのWebUIが未処理の例外発生時にクライアントに対して完全なPythonトレースバックの詳細を返していました。認証なしでアクセス可能な/web/path:filenameが攻撃者制御のテンプレート名をレンダリングするため、認証されていないユーザーが確実にサーバ例外（例えば存在しないテンプレートのリクエスト）を発生させ、HTTPレスポンス内で内部スタックトレースを受け取ることができます。この脆弱性は0.5.0b3.dev100で修正されました。

ShellHubは集中型のSSHゲートウェイです。バージョン0.24.2以前では、GET /api/devices/:uidは呼び出し元が認証されていれば、デバイスが呼び出し元の名前空間（テナント）に属しているかどうかを確認せずにデバイスの完全なオブジェクトを返していました。認証された任意のユーザー（JWTまたはAPIキー）がデバイスのUIDを知っているか推測できれば、他の名前空間のデバイスメタデータを読むことが可能でした。この脆弱性はバージョン0.24.2で修正されました。

ShellHubは集中管理されたSSHゲートウェイです。バージョン0.24.2以前では、device listエンドポイントがbase64エンコードされたfilterクエリパラメータ内の各フィルタプロパティのnameフィールドやsort_byクエリパラメータにユーザー制御の識別子を受け入れており、それらを検証せずにそのままデータベース層のBSON/SQLキーとして渡していました。認証済みの任意のユーザーは、集約やクエリを失敗させるペイロードを作成でき、その結果APIは本文なしのHTTP 500を返します。また、レート制限は適用されません。この脆弱性はバージョン0.24.2で修正されています。

Open WebUIは完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、FolderFormはmodel_config = ConfigDict(extra='allow')を使用しており、これにより任意のフィールドがPydanticのバリデーションを通過し、model_dump(exclude_unset=True)に含まれることが可能でした。insert_new_folderにおいて、サーバーが割り当てるuser_idは辞書の先頭に配置され、その後フォームデータの展開によって上書きされます。FolderModelはuser_id: strを実フィールドとして宣言しているため、攻撃者がPOSTボディに含めた任意のuser_idがモデルに受け入れられ、Folder行に永続化されます。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、_validate_collection_access関数が不完全な許可リストを使用しており、user-memory-*およびfile-*パターンに一致するコレクションに対してのみ所有権チェックを強制していました。他のすべてのコレクション名はチェックされずに通過しており、インスタンス上のすべての知識ベースのID、名前、および説明を保存するシステムレベルのknowledge-basesメタコレクションも含まれています。認証された任意のユーザーは、このメタコレクションをリトリーバルクエリエンドポイント経由で直接照会でき、すべてのユーザーにわたる全知識ベースのグローバルインデックスを取得できます。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作するよう設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、チャネルルーターが作成または更新パスのいずれの場合でもfilter_allowed_access_grantsを呼び出しませんでした。非管理者ユーザー（またはチャネルの所有者）がグループチャネルを作成でき、任意のアクセス権限（公開のワイルドカード権限を含む）を提出できます。それらの権限は管理者の権限フレームワークをバイパスしてそのまま保存されます。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、GET /api/v1/channels/{id}/membersエンドポイントはグループおよびダイレクトメッセージ（DM）チャンネルタイプのメンバーシップのみをチェックしていました（467〜469行）。標準チャンネル、特にプライベートチャンネルに対しては、メンバーリストを返す前にchannel_has_accessのチェックが行われていませんでした。認証済みのユーザーはプライベートチャンネルのUUIDを知っていれば、そのチャンネルにアクセスできるすべてのユーザーを列挙することが可能でした。この脆弱性はバージョン0.9.0で修正されています。

Open WebUIは完全にオフラインで動作するよう設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前のバージョンでは、get_sources_from_items関数内でtype: "file"（フルコンテキストではない）、type: "text"（collection_name付き）、および裸のcollection_name/collection_namesパスが認証チェックなしにベクターストアクエリを実行しており、ユーザーはアクセス権のないファイルやナレッジベースからコンテンツを抽出できる状態にありました。この脆弱性はバージョン0.9.0で修正されています。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、is_user_channel_member関数がChannelMember行の存在を確認しますが、is_activeフィールドを確認していませんでした。ユーザーがグループまたはDMチャンネルから非アクティブ化されると（チャンネル所有者によって削除されるか、ユーザー自身が退会した場合）、そのメンバーシップ行はis_active=Falseおよびstatus='left'のまま残ります。認可チェックがこのフィールドを無視するため、非アクティブ化されたユーザーは直接のAPI呼び出しを通じてチャンネルへの完全な読み書きアクセス権を保持してしまいます。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作する自己ホスト型人工知能プラットフォームです。バージョン0.9.0以前では、POST /api/v1/models/importエンドポイントを使用するユーザーは、workspace.models_import権限を持っている場合、所有権に関係なくデータベース内の既存モデルを上書きできました。インポートされたモデルのIDが既存モデルと一致すると、このエンドポイントは攻撃者のペイロードを既存モデルのデータに上書きし、所有権やアクセス権限の検証を行わずにデータベースへ書き込みます。さらに、filter_allowed_access_grantsは決して呼び出されず、他のすべてのモデル変更エンドポイントに課されているアクセス権制限を回避します。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、/api/generate、/api/embed、/api/embeddings、および/api/showエンドポイントがユーザーから任意のモデル名を受け取り、そのユーザーがそのモデルへのアクセス権を持っているかを確認せずにリクエストをOllamaバックエンドに転送していました。これらのエンドポイントはget_verified_user（認証済みで保留中でないユーザー）を必要とし、モデルがフィルタリングされていない完全なモデルリストに存在するかを検証しますが、AccessGrants.has_access()による確認は決して行いませんでした。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。0.9.0以前のバージョンでは、ydoc:document:updateのSocket.IOイベントハンドラーは送信者がドキュメントのSocket.IOルームのメンバーであるかどうかを確認していました（行678）が、送信者が書き込み権限を持っているかどうかは検証していませんでした。読み取り専用アクセス権を持つユーザーはydoc:document:joinを介してドキュメントルームに参加でき、これは読み取り権限のみを要求します（行520）。ルーム内に入ると、ユーザーはydoc:document:updateイベントを送信でき、その結果メモリ内のYjsドキュメント状態が変更され、その変更はリアルタイムで他のコラボレーター全員にブロードキャストされます。この脆弱性は0.9.0で修正されました。

Open WebUIは完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、AccountPending.svelteコンポーネントがadminによって設定された「保留中ユーザーオーバーレイコンテンツ」を{@html}内でmarked.parse()を使用してレンダリングしていましたが、DOMPurifyの適用順序が誤っていました。これにより、管理者は任意のJavaScriptを保留中ユーザーオーバーレイコンテンツに注入でき、そのJavaScriptはオーバーレイページを表示する保留中ユーザーのブラウザコンテキストで実行されてしまう恐れがありました。この脆弱性はバージョン0.9.0で修正されています。

Open WebUIは、完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。0.8.6以前の標準チャンネル（すなわちchannel.typeがgroupでもdmでもないチャンネル）において、エンドポイントPOST /api/v1/channels/{channel_id}/messages/{message_id}/updateは読み取り権限のみでアクセス可能でした。access_controlがNoneに設定されている場合、authorizationチェックのhas_access(..., type="read")はTrueと評価され、メッセージの所有者でないユーザーもメッセージを更新できます。その結果、他ユーザーのメッセージが不正に改変される可能性があります。この脆弱性は0.8.6で修正されました。

Vimはオープンソースのコマンドラインテキストエディタです。バージョン9.2.0450より前のバージョンには、UTF-8エンコーディングが有効な状態で細工されたスペルファイル（.spl）を読み込む際に、src/spellfile.cのread_compound()でヒープバッファオーバーフローの脆弱性が存在します。スペルファイルの複合セクションにある、攻撃者が制御可能な長さフィールドが32ビット符号付き整数の乗算をオーバーフローさせ、その結果、小さいバッファが書き込みループのために割り当てられます。しかし、そのループは多数の反復を実行し、ヒープのオーバーフローを引き起こします。'spelllang'オプションはmodelineから設定可能であるため、悪意のある.splファイルがruntimepathに設置されている場合、テキストファイルのmodelineによってスペルファイルの読み込みがトリガーされることがあります。この問題はバージョン9.2.0450で修正されました。

Open WebUIは完全にオフラインで動作するよう設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.8.0以前では、ユーザープロファイル更新フォームのprofile_image_urlフィールドがMIMEタイプの検証を行わず、任意のデータURI値を受け入れていました。その結果、クロスサイトスクリプティング（XSS）が発生する脆弱性が存在していました。この脆弱性はバージョン0.8.0で修正されました。

Open WebUIは完全にオフラインで動作するよう設計された自己ホスト型の人工知能プラットフォームです。バージョン0.9.3以前では、チャネルのwebhook作成および更新フローで任意のprofile_image_urlの値が受け入れられており、その中にはdata:image/svg+xml;base64,...形式のペイロードも含まれていました。プロフィール画像のエンドポイントは、このSVGをサニタイズせずにimage/svg+xmlとしてデコードして配信していたため、攻撃者が制御するスクリプトハンドラー（例えばonload）がプロフィール画像のURLをブラウザで開いた際に実行される可能性がありました。この脆弱性はバージョン0.9.3で修正されました。

Open WebUIは完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.3以前では、Open-WebUIの画像アップロード機能にアプリケーション全体に影響を及ぼすクロスサイトリクエストフォージェリ（CSRF）の脆弱性が存在していました。攻撃者は画像のURLを悪意のあるエンドポイントに設定でき、これにより被害者ユーザーを代表して操作を実行できます。認証されたユーザーであれば誰でもこの脆弱性を悪用でき、また、侵害された画像（例：プロフィール写真）を閲覧した任意のユーザーは知らずに攻撃者が管理するURLへGETリクエストを送信してしまいます。これによりクッキーの盗難、サービス拒否（DoS）、その他の悪意ある行為が引き起こされる可能性があります。この脆弱性はバージョン0.9.3で修正されました。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.9.3以前では、このアドバイザリは元のExcelプレビューXSSの回帰を追跡しています。同じ根本原因であるXLSX.utils.sheet_to_html()の出力が{@html excelHtml}を介してDOMPurifyなしでレンダリングされる問題がv0.8.0以降のどこかで再導入され、再び悪用可能となっていました。この脆弱性はバージョン0.9.3で修正されました。

Open WebUIは完全にオフラインで動作するよう設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.0以前では、Open WebUIは管理者がAPIキーを使ってアクセス可能なAPIエンドポイントを制限できました。APIキーが/api/v1/messagesに制限されている場合、Authorization: Bearer sk-... ヘッダーを使用したリクエストは正しく403でブロックされます。しかし、同じキーがx-api-keyヘッダーを通じて送信されると制限を完全に回避してしまい、そのリクエストは認証されてモデルが呼び出され、完全なレスポンスが返されます。この脆弱性はバージョン0.9.0で修正されました。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.5.7以前では、ユーザーが他のユーザーのモデルの可視性をプライベートに設定していても、そのモデルを変更できる可能性がありました。編集時にアクセス権限が変更されることで、不正なアクセスを得ることが可能でした。この脆弱性はバージョン0.5.7で修正されました。

Open WebUIは完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。0.6.31以前のバージョンには、Open WebUIのSVGレンダラー実装にクロスサイトスクリプティングの脆弱性が存在していました。この脆弱性は0.6.31で修正されています。

Open WebUIは完全にオフラインで動作することを目的としたセルフホスト型の人工知能プラットフォームです。バージョン0.5.11以前には、PDF生成機能を介したブラインドサーバーサイドリクエストフォージェリ（SSRF）の脆弱性が存在していました。PDFエクスポート時にユーザー入力がHTMLとして解釈され、PDFに埋め込まれます。検証の結果、スクリプトや一部の潜在的に危険なタグ（iFrame、Objectなど）はブロックされており、この脆弱性を通じてサーバー側のコンテンツが読み取られることは防止されています。しかし、画像タグを用いることでサーバー側へのリクエスト（SSRF）を強制でき、その詳細は以下の通りです。この脆弱性はバージョン0.5.11で修正されています。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。バージョン0.8.9以前では、一般ユーザー（管理者ではない）がアプリケーションにログインすると、アプリケーションがhttp://IP:8080/api/models? へウェブリクエストを発行しました。その応答として、管理者がワークスペースのモデルページで設定した利用可能なモデルのシステムプロンプトが公開され、アプリケーションの機密性に影響を及ぼしていました。この脆弱性はバージョン0.8.9で修正されています。

Open WebUIは完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。0.8.11以前のバージョンでは、FastAPIのクエリ文字列バインディングを介して/openai/chat/completionsおよび/ollama/api/chatのHTTPエンドポイントに内部専用のbypass_filterパラメータが公開されていました。認証された任意のユーザーは?bypass_filter=trueを追加することでモデルアクセス制御チェックを回避し、管理者制限のあるモデルを呼び出すことが可能でした。この脆弱性は0.8.11で修正されました。

Open WebUIは完全にオフラインで動作するよう設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.5以前には、Open WebUIのChannels機能にIDOR（不適切な直接オブジェクト参照）脆弱性が存在し、同じチャネル内の任意のチャネルメンバーが他のメンバー（管理者を含む）が送信したメッセージを改ざんできる可能性がありました。update_message_by_id関数において、グループまたはダイレクトメッセージタイプのチャネルの場合、is_user_channel_member関数によって呼び出し元のチャネルメンバーシップのみがチェックされ、メッセージ所有権の検証は行われていませんでした。これにより、同じチャネル内の任意のチャネルメンバーが他のメンバーの送信したメッセージを改ざんできる状況が生じていました。この脆弱性はバージョン0.9.5で修正されました。

Open WebUIは完全にオフラインで動作するように設計されたセルフホスト型の人工知能プラットフォームです。バージョン0.9.5以前では、Pin/Unpinは書き込み操作（メッセージのis_pinned、pinned_by、pinned_atフィールドを変更する操作）ですが、標準チャネルでは読み取り権限のみをチェックしており、読み取り専用アクセスを持つユーザーでも任意のメッセージをピン留めまたはピン留め解除できてしまいます。この脆弱性はバージョン0.9.5で修正されています。

Open WebUIは完全にオフラインで動作する自己ホスト型の人工知能プラットフォームです。0.9.5以前のバージョンでは、グループに読み取り権限を設定して他のユーザーがモデルを使用できるようにすると、そのユーザーもモデルのシステムプロンプトを読み取れる状態になっていました。しかし、ユーザーはシステムプロンプトを機密情報と見なすことがあるため、これはセキュリティ上の問題でした。この脆弱性は0.9.5で修正されています。