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

シックス・アパート株式会社が提供するMovable Typeには、次の脆弱性が存在します。 ・権限チェックの欠如（CWE-862）- CVE-2026-44392 この脆弱性情報は、製品利用者への周知を目的に、開発者がJPCERT/CCに報告し、JPCERT/CCが開発者との調整を行いました。

Microsoft Edge（Chromiumベース）における重要情報のユーザーインターフェース（UI）の誤表示により、認証されていない攻撃者がネットワーク上でなりすましを行うことが可能になります。

Mattermostのバージョン11.5.x（11.5.1以下）および10.11.x（10.11.13以下）には、PostEditTimeLimitがメッセージ以外の投稿フィールドに適用されず、認証されたユーザーが編集時間制限が切れた後でも投稿のファイル添付やプロパティ、ピン留め状態をpost patchおよびupdate APIエンドポイントを通じて変更できる脆弱性があります。この問題はMattermostアドバイザリーID MMSA-2026-00631で報告されています。

Mattermostのバージョン11.5.xから11.5.1まで、10.11.xから10.11.13まで、11.4.xから11.4.3までにおいて、プロキシされた画像のレスポンスボディの検証に失敗する問題があります。これにより、リモートの攻撃者が自身で管理するオリジンから提供されるSVGファイルを、非SVGのContent-Typeヘッダー（例：image/png）でog:imageメタタグやMarkdownの画像リンクに埋め込むことで、クライアントサイドでDoS攻撃を実行できる可能性があります。

Ciliumは、eBPFベースのデータプレーンを備えたネットワーキング、可観測性、およびセキュリティのソリューションです。バージョン1.17.15、1.18.9、および1.19.3より前のバージョンでは、WireGuard暗号化が有効なCiliumデプロイメントに対してcilium-bugtoolを実行すると、その出力に機密データが含まれる可能性がありました。この問題は、バージョン1.17.15、1.18.9、および1.19.3で修正されています。

攻撃者はIMAPで過剰な中括弧の使用により制御不能なメモリ使用を引き起こす可能性があります。この脆弱性により、攻撃者は設定されたメモリ制限までメモリ使用を引き上げることが可能です。修正済みのバージョンをインストールし、imapプロセスのvsz_limitを低い値に設定することが対策として推奨されます。

Kirbyはオープンソースのコンテンツ管理システムです。バージョン4.9.0および5.4.0より前のバージョンでは、システムAPIエンドポイントが認証済みユーザーにライセンスデータおよびインストールされたバージョン情報を漏洩していました。この問題はバージョン4.9.0および5.4.0で修正されました。

Kirbyはオープンソースのコンテンツ管理システムです。バージョン4.9.0および5.4.0より前のバージョンでは、サイト、ユーザー、およびロール情報への読み取りアクセスが権限によって制御されていませんでした。この問題はバージョン4.9.0および5.4.0で修正されています。

Kirbyはオープンソースのコンテンツ管理システムです。バージョン4.9.0および5.4.0より前のバージョンでは、`pages.access/list`および`files.access/list`の権限がパネルおよびREST APIで一貫して正しくチェックされていませんでした。この問題はバージョン4.9.0および5.4.0で修正されました。

Kirbyはオープンソースのコンテンツ管理システムです。バージョン4.9.0および5.4.0より前のバージョンでは、ユーザーアバターの作成、置換、および削除がユーザーの更新権限によって制限されていませんでした。この問題はバージョン4.9.0および5.4.0で修正されました。

NanaZipはオープンソースのファイルアーカイブソフトウェアです。バージョン5.0.1252.0から6.0.1698.0未満の間、NanaZipのElectronアーカイブ（ASAR）パーサーに制御されていない再帰の脆弱性が存在していました。深くネストされたJSONをヘッダーに持つ細工された.asarファイルを開くと、nlohmann::json::parseおよびハンドラのGetAllPaths関数が深さの制限なく再帰し、スレッドスタックを枯渇させてNanaZipプロセスをクラッシュさせます。この脆弱性はバージョン6.0.1698.0で修正されました。

uriparser 1.0.1より前のバージョンには、アプリケーションがギガバイト単位の長さのURIを受け入れる場合に、テキスト範囲の比較で数値の切り捨てに問題が発生する脆弱性があります。

NanaZipはオープンソースのファイルアーカイブソフトウェアです。バージョン5.0.1252.0から6.0.1698.0未満の間、NanaZipのUFS/UFS2ファイルシステムイメージパーサーにヌルポインタ参照の脆弱性が存在していました。この脆弱性は、ルートiノード（iノード2）がIFDIR（ディレクトリ）ではなくIFLNK（シンボリックリンク）に設定された細工されたUFSイメージを開いたときに発生します。パーサーはタイプを確認せずにルートiノードを無条件にディレクトリとして扱い、シンボリックリンクに埋め込まれたターゲット（小さいdi_size）がある場合、ディレクトリデータバッファの長さがゼロになり、最初の読み取り時にヌルポインタ参照が発生しました。この脆弱性はバージョン6.0.1698.0で修正されました。

NanaZipはオープンソースのファイルアーカイブソフトウェアです。バージョン5.0.1252.0から6.0.1698.0未満の間に、NanaZipのUFS/UFS2ファイルシステムイメージパーサーに整数のゼロ除算の脆弱性が存在していました。この脆弱性は、スーパーブロックのフィールドfs_ipg（シリンダグループあたりのinode数）がゼロに設定された細工されたUFSイメージを開いたときに発生します。パーサーはこの攻撃者制御下の値を検証せずに除数として使用するため、即座にハードウェアトラップが発生し、プロセスがクラッシュします。この脆弱性はバージョン6.0.1698.0で修正されました。

NanaZipはオープンソースのファイルアーカイブです。バージョン5.0.1252.0から6.0.1698.0未満の間、NanaZipのlittlefsファイルシステムイメージパーサーにサービス拒否（DoS）脆弱性が存在します。ハンドラーのOpenメソッドは、実際のファイルサイズや上限値を検証せず、攻撃者が制御するスーパーブロックからBlockCountを直接読み取ります。その後、BlockCount回反復し、各反復でファイルパスエントリを割り当てます。BlockCountが0xFFFFFFFFに設定された細工された44バイトのlittlefsイメージは約40億回のヒープ割り当てを引き起こし、利用可能なメモリを枯渇させます。この脆弱性はバージョン6.0.1698.0で修正されました。

AnythingLLMは、コンテンツの断片を任意のLLMがチャット中に参照として使用できるコンテキストに変換するアプリケーションです。バージョン1.12.1より前のAnythingLLMにおいて、GET /api/workspace/:slug/tts/:chatIdは、同じワークスペース内の別のユーザーのチャット応答のテキスト読み上げ音声を返してしまいます。これはルートがワークスペースのメンバーシップを検証するものの、対象のチャット行の所有権を強制しないためです。結果として、認証されたユーザーは、chatIdが既知または推測できる場合に他のユーザーのプライベートなアシスタント応答を音声形式でアクセスすることが可能です。これはTTSエンドポイント経由で公開されたプライベートチャット応答コンテンツに影響を及ぼす安全でない直接オブジェクト参照（IDOR）の問題を構成します。この問題はバージョン1.12.1で修正されました。

FiberはGo用のウェブフレームワークです。バージョン2.52.12および3.1.0より前のバージョンには、Go Fiberにクロスサイトスクリプティングの脆弱性が存在しました。攻撃者がAccept: text/htmlを任意のリクエストに指定することで、影響を受けたデータをAutoFormat()機能に渡すハンドラを通じて、攻撃者が任意のHTML/JavaScriptを注入できる可能性があります。開発者はAutoFormat()を呼び出すことでコンテンツネゴシエーションを選択しますが、特定のリクエストに対して生のHTML出力を選択していません。しかし、Fiberは攻撃者がコントロールするAcceptヘッダーからhtmlの分岐を選択します。html分岐は、メソッド名（AutoFormat）および対称的な構造が「安全でフォーマットに依存しない応答」を積極的に示している中で唯一の例外となっています。この脆弱性はバージョン2.52.12および3.1.0で修正されました。

Nettyは非同期でイベント駆動型のネットワークアプリケーションフレームワークです。4.2.13.Finalおよび4.1.133.Final以前のバージョンでは、Nettyのチャンクサイズパーサがint型を静かにオーバーフローさせ、リクエストスマグリング攻撃を可能にしていました。この脆弱性は4.2.13.Finalおよび4.1.133.Finalで修正されました。

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で修正されました。