日本公的データラボ脆弱性情報（JVN）
脆弱性情報（JVN）検索・一覧
JVN（IPA／JPCERT/CC 提供）の脆弱性情報 289,680 件を、製品・ベンダ・脆弱性タイプ（CWE）で 全文検索し、深刻度（CVSS）で絞り込めます。発表日の新しい順。各タイトルから詳細（CVSS内訳・関連脆弱性）へ。
種別 不適切な入力確認 直近3年 の検索結果：1–40 件目を表示（ページ 1）
深刻度は CVSS（共通脆弱性評価システム・0〜10 のスコア）に基づく区分：Critical 9.0以上／High 7.0〜8.9／Medium 4.0〜6.9／Low 0.1〜3.9。
Open WebUIのバージョン0.9.5未満には、OAuth認証フローにおいて格納型クロスサイトスクリプティングの脆弱性があります。この脆弱性は、画像クレームのURLのMIMEタイプがContent-Typeヘッダーではなくファイル拡張子から推論されるため、SVGファイルがプロフィール画像バリデーターを回避してデータURIとして保存されてしまうことに起因しています。認証済みユーザーがプロフィール画像エンドポイントにアクセスすると、攻撃者制御下のSVGコンテンツがインライン配置され、かつデフォルトのセキュリティヘッダーが付与されない状態で配信されます。そのため、同一オリジン内でスクリプトが実行され、認証トークンの窃取やアカウントの乗っ取りが可能となります。
Linux上のGoogle Chromeバージョン150.0.7871.125以前において、Linuxツールキットテーマ処理で信頼されていない入力の検証不足が存在し、リモート攻撃者が細工されたHTMLページを介してレンダラープロセスを侵害し、サンドボックスを脱出する可能性がありました。（Chromiumセキュリティの重大度：高）
Windows版Google Chromeのバージョン150.0.7871.125以前のMediaにおいて、信頼されていない入力の検証が不十分であったため、レンダラープロセスを乗っ取ったリモート攻撃者が細工されたHTMLページを介してプロセスメモリから潜在的に機密性の高い情報を取得できる可能性がありました。（Chromiumセキュリティの重大度は高とされています）
Google Chrome 150.0.7871.125以前のNavigationにおける信頼できない入力の検証不足により、リモート攻撃者が細工されたHTMLページを介してレンダラープロセスを侵害し、ナビゲーション制限を回避できる問題です。（Chromiumセキュリティ重大度：中）
ColdFusion は、不適切な入力検証の脆弱性の影響を受けており、これにより現在のユーザーのコンテキストで任意のコードが実行される可能性があります。この問題を悪用するためにユーザーの操作は不要です。対象範囲が変更されました。
ColdFusionは、不適切な入力検証の脆弱性により、セキュリティ機能がバイパスされる可能性があります。権限の低い攻撃者がこの脆弱性を悪用すると、セキュリティ対策を回避して不正な読み取りアクセスを取得する可能性があります。この問題を悪用するためにユーザーの操作は不要です。影響範囲が変更されました。
Microsoft Office Excelのスタックベースのバッファオーバーフローにより、不正な攻撃者がローカル環境でコードを実行できる脆弱性です。
Eclipse KUKSA Databroker バージョン0.6.1において、kuksa.val.v2.VAL/PublishValueのgRPCハンドラはPublishValueRequest内のオプションフィールドであるdata_pointの存在を検証していません。リクエストに有効なsignal_idが含まれていてもdata_pointが省略されている場合、サーバはrequest.data_pointに対して直接unwrap()を呼び出し、Tokioのワーカースレッドでパニックを引き起こします。この問題は有効なJWTトークンを持つ任意のクライアントによって引き起こされる可能性があります。認証されていないまたは無効なトークンのリクエストは拒否され、脆弱な経路には到達しません。パニックによって個々のgRPC呼び出しはキャンセルされますが、Databrokerプロセス自体は終了せず、その後のリクエストにも引き続き対応します。
Eclipse Jettyにおいて、HTTP/1、HTTP/2、およびHTTP/3のリクエストに対して、リクエストの権限部分（ホストおよびポート）がHostヘッダー（存在する場合）に提供されたものと厳密に一致するかどうかのチェックが行われていませんでした。これは以前のHTTP RFC（例えばRFC 2616）では強制されていませんでしたが、最新のRFC（9110および9112）では強制されています。この不一致は、以下のような脆弱性を引き起こす可能性があります。 * URIの構築（例えばリダイレクトにおいて—ログインページで典型的です） * 仮想ホストの選択 * リバースプロキシの動作異常 * 誤解を招くログ記録 * その他の問題 最新のRFCでは、リクエストの権限部分とHostヘッダーが一致しなければならないと要求しているため、Jettyはこの不変条件を強制すべきです。
Palo Alto Networks PAN-OS ソフトウェアにおけるファイル削除の脆弱性により、ネットワークアクセスを持つ認証されていない攻撃者が管理用ウェブインターフェースから一時ディレクトリ内のファイルを削除することが可能になります。この問題によるセキュリティリスクは、推奨されるベストプラクティス運用ガイドライン（https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431）に従い、管理用ウェブインターフェースへのアクセスを信頼できる内部IPアドレスのみに制限することで最小化されています。この問題はPAシリーズおよびVMシリーズファイアウォール、ならびにPanorama（仮想およびMシリーズ）上のPAN-OSソフトウェアに適用されます。Cloud NGFWおよびPrisma Access はこの脆弱性の影響を受けません。
Android版Google Chromeのバージョン150.0.7871.115より前のWebAppInstallsにおける信頼されていない入力の検証不足により、ローカル攻撃者が巧妙に作成したHTMLページを介して同一生成元ポリシーを回避できる可能性がありました。（Chromiumセキュリティの重大度は高です）
Windows版Google Chrome 150.0.7871.115以前のCodecsにおける信頼されていない入力の検証不足により、レンダラープロセスを侵害したリモート攻撃者が細工されたHTMLページを介してサンドボックスから脱出できる可能性がありました。（Chromiumセキュリティの重大度：高）
150.0.7871.115より前のGoogle Chromeのパスワード管理における不十分なポリシー強制が原因で、リモートの攻撃者が細工されたHTMLページを介して同一生成元ポリシーを回避できる可能性がありました。（Chromiumセキュリティの深刻度は高いです）
150.0.7871.115 未満の Google Chrome のナビゲーションにおける不適切な実装が原因で、リモートの攻撃者が細工された HTML ページを使ってサイト分離を回避できる可能性がありました。（Chromium セキュリティの重大度は中です）
Apache Camelにおける不適切な入力検証の脆弱性です。この問題はApache Camelのバージョン4.14.7まで、4.15.0から4.18.2まで、4.19.0から4.20.0までに影響します。ユーザーには、この問題を修正したバージョン4.14.8、4.18.3、4.21.0へアップグレードすることを推奨します。
Apache Camelにおける不適切な入力検証の脆弱性が存在します。この問題はApache Camelの以下のバージョンに影響します：4.14.7まで、4.15.0から4.18.2まで、および4.19.0から4.20.0までです。ユーザーはこの問題を修正したバージョンである4.14.8、4.18.3、および4.21.0にアップグレードすることを推奨します。
Apache Camelにおける不適切な入力検証の脆弱性です。この問題はApache Camelのバージョン4.8.0から4.18.2、および4.19.0から4.20.0に影響します。ユーザーには、この問題を修正したバージョン4.18.3および4.21.0へアップグレードすることを推奨します。
Apache Camel Cometdコンポーネントにおける不適切な入力検証の脆弱性について説明します。camel-cometdコンポーネントは、Bayeux（CometD）から受信したメッセージヘッダーにHeaderFilterStrategyを適用せずにCamel Exchangeにマッピングします。CometdBinding.populateExchangeFromMessageは、CometDクライアントから提供されたext.CamelHeadersマップ全体を直接Camelメッセージ（message.setHeaders）にコピーするため、CamelHttpUri、CamelFileName、CamelJmsDestinationNameのようなCamel内部制御ヘッダーを含むあらゆるヘッダー名が変更されることなく受け入れられます。デフォルトでCometdComponentはBayeux SecurityPolicyをインストールしないため、Bayeuxハンドシェイクを完了できるクライアントは認証なしでこのメッセージを公開できます。その結果、攻撃者はルート内の下流プロデューサの動作に影響を与える任意のCamel制御ヘッダーを注入可能です（例：HTTPプロデューサのリダイレクト、ファイル名の変更、JMS宛先の上書き）。注入されたヘッダーは内部のdirect、seda、vmホップ間でも持続します。具体的な下流への影響はルートで使用されるプロデューサによって異なります。この問題はApache Camelのバージョン4.0.0から4.14.8未満、4.15.0から4.18.3未満、4.19.0から4.21.0未満に影響します。ユーザーには問題を修正したバージョン4.21.0へのアップグレードを推奨します。4.14.xのLTSリリース利用者は4.14.8へ、4.18.xリリース利用者は4.18.3へアップグレードすることを推奨します。修正はcamel-cometdバインディングにHeaderFilterStrategyを実装し（コード上の長期間のTODO）、インバウンドマッピングで大文字小文字を区別せずCamelヘッダー名前空間をフィルタリングすることで、クライアントから提供されるCamel* / camel*ヘッダーがExchangeにコピーされなくなるようにしています。即時アップグレードできない環境では、ルート開始時にremoveHeaders('Camel*')およびremoveHeaders('camel*')などを使用して、下流プロデューサに届く前に受信したCometDメッセージからCamel制御ヘッダーを除去し、さらにCometdComponentに明示的なBayeux SecurityPolicyを設定して認証済みクライアントのみがメッセージを公開できるようにしてください。
Apache Camel AWS2-SQS コンポーネントにおける不適切な入力検証の脆弱性について説明します。camel-aws2-sqs コンポーネントは、コンポーネント固有の HeaderFilterStrategy を通じてインバウンドメッセージ属性を Camel Exchange にマップしています。Sqs2HeaderFilterStrategy はアウトバウンドフィルター（setOutFilterPattern、Camel*、breadcrumbId、および org.apache.camel.* ヘッダーがブローカーへ書き込まれるのをブロックするもの）のみを設定しており、インバウンドフィルターは設定していませんでした。その結果、Sqs2Consumer が各 SQS の MessageAttribute を HeaderFilterStrategy.applyFilterToExternalHeaders 経由で Exchange にコピーする際に、DefaultHeaderFilterStrategy はインバウンドルールを適用せず、すべてのヘッダー名をフィルター対象外とみなし、CamelHttpUri、CamelFileName、CamelSqlQuery などの Camel 内部制御ヘッダーを変更せずに Camel メッセージにコピーしてしまいます。したがって、消費される SQS キューへメッセージを送信できる権限を持つ主体（例えばクロスアカウントの送信者や、sqs:SendMessage 権限を持つより権限の低い同アカウント内のコンポーネント）は、ルート内の下流のプロデューサの挙動に影響を与える任意の Camel 制御ヘッダーを設定できる可能性があります（例：HTTP プロデューサのリダイレクト、ファイル名の変更、クエリの上書き）。注入されたヘッダーは、内部の direct、seda、vm ホップ間でも持続します。具体的な下流への影響はルートが使用するプロデューサに依存します。本問題は Apache Camel のバージョン 4.0.0 から 4.14.8 未満、4.15.0 から 4.18.3 未満、および 4.19.0 から 4.21.0 未満のバージョンに影響します。ユーザーは問題を修正した 4.21.0 へのアップグレードを推奨します。4.14.x LTS リリースを使用している場合は 4.14.8 へのアップグレードを、4.18.x リリースを使用している場合は 4.18.3 へのアップグレードを推奨します。修正内容は、インバウンドマッピング時に大文字・小文字を問わず Camel ヘッダー名前空間をフィルタリングするインバウンド HeaderFilterStrategy ルールを Sqs2HeaderFilterStrategy に追加し、送信者が指定した Camel* および camel* ヘッダーが Exchange にコピーされないようにしたものです。すぐにアップグレードできない環境では、ルートの開始時に removeHeaders('Camel*') と removeHeaders('camel*') を使用してインバウンドメッセージから Camel 制御ヘッダーを除去し、さらに消費される SQS キューへ送信可能な主体を最小権限の sqs:SendMessage 権限で制限することを推奨します。
Apache Camel NATSコンポーネントにおける不適切な入力検証の脆弱性です。camel-natsコンポーネントは、受信したNATSメッセージのヘッダーをCamel Exchangeにマッピングしますが、headerFilterStrategyがinboundルールとして設定されていない場合、新規のDefaultHeaderFilterStrategy()がデフォルトで設定されていました（NatsConfiguration）。inFilter、inFilterPattern、inFilterStartsWithが設定されていない場合、DefaultHeaderFilterStrategy.applyFilterToExternalHeadersはすべてのヘッダー名に対してフィルタリングを行わないため、NatsConsumerはCamelHttpUri、CamelFileName、CamelSqlQueryなどのCamel内部制御ヘッダーを含むすべてのNATSメッセージヘッダーを変更せずにCamelメッセージへコピーしてしまいます。したがって、対象のNATSサブジェクトに対して公開可能なクライアントは、ルート内の下流のプロデューサの動作に影響を与える任意のCamel制御ヘッダーを注入できます（例：HTTPプロデューサのリダイレクト、ファイル名の変更、クエリの上書きなど）。注入されたヘッダーは、内部のdirect、seda、vm経由でも引き継がれます。具体的な影響は、ルートで使用されるプロデューサによって異なります。NATSメッセージヘッダーはNATS 2.2以降が必要であり、NATSサーバーが認証なしで構成された場合（NATSサーバーのデフォルト設定）、認証情報なしで問題に到達可能です。この問題はApache Camelの4.0.0から4.14.8未満、4.15.0から4.18.3未満、4.19.0から4.21.0未満のバージョンに影響します。ユーザーは、この問題が修正された4.21.0へアップグレードすることを推奨します。4.14.x LTSリリースストリームのユーザーは4.14.8へ、4.18.xリリースストリームのユーザーは4.18.3へアップグレードしてください。修正ではcamel-natsのデフォルトを専用のNatsHeaderFilterStrategyに変更し、受信マッピング時にCamelヘッダー名前空間を大文字・小文字を区別せずにフィルタリングすることで、クライアントから提供されたCamel* / camel*ヘッダーがExchangeにコピーされなくなります。すぐにアップグレードできない環境では、受信したNATSメッセージからCamel制御ヘッダーを下流のプロデューサに到達する前に削除すること（例：ルート開始時にremoveHeaders('Camel*')およびremoveHeaders('camel*')を実行）およびNATSサーバーの認証を有効化して信頼されたクライアントのみが対象サブジェクトに公開できるようにすることを推奨します。
vLLMは、大規模言語モデル（LLM）向けの高スループットかつメモリ効率の良い推論およびサービングエンジンです。バージョン0.24.0以前では、フロントエンドで合法とされる複数リクエストによる推測的デコーディングのワークロードが原因で、リジェクションサンプラーがモデルの語彙サイズの境界値と等しい復元トークンを生成してしまうことがありました。この値は、エンジンがリクエストの次のライブトークンを選択する際に-1（負の値）に変換され、ドラフターの入力IDに書き戻されます。その語彙外の値は後にモデルの埋め込みおよびアテンション経路で使用され、GPUデバイス側のアサーションによりエンジンワーカーがクラッシュしてしまいます。同じトリガーとなるリクエストシーケンスは、公開されているgRPCのGenerateおよびAbortエンドポイントを通じても到達可能なため、生成リクエストを送信できるリモートクライアントが共有されているエンジンワーカーをクラッシュさせ、同時に実行されているリクエストを中断し、ワーカーが再起動されるまで他のクライアントに対するサービス全体のサービス拒否（DoS）状態を引き起こしてしまいます。この問題はバージョン0.24.0で修正されました。
Microsoft Edge（Chromiumベース）における不適切な入力検証の脆弱性により、不正な攻撃者がネットワーク経由でコードを実行する可能性があります。
Google Chrome 150.0.7871.46以前のANGLEにおいて、信頼されていない入力の検証が不十分であったため、リモートの攻撃者が細工されたHTMLページを利用してサンドボックスから脱出する可能性がありました。（Chromiumセキュリティの深刻度：高）」
150.0.7871.46より前のAndroid版Google ChromeのANGLEにおいて、信頼されていない入力の検証が不十分であったため、レンダラープロセスを乗っ取ったリモート攻撃者が細工されたHTMLページを介してサンドボックスから脱出する可能性がありました。（Chromiumセキュリティ深刻度：高）
150.0.7871.46より前のGoogle ChromeのANGLEにおける信頼されていない入力に対する検証が不十分であったため、リモートの攻撃者が細工されたHTMLページを介してサンドボックスを脱出する可能性がありました。（Chromiumセキュリティの深刻度は高です）
Google Chrome 150.0.7871.46より前のバージョンに含まれるANGLEの信頼されていない入力に対する検証不十分の脆弱性により、レンダラープロセスを乗っ取ったリモート攻撃者が細工されたHTMLページを介してサンドボックスをエスケープできる可能性がありました。（Chromiumセキュリティの重大度：高）
150.0.7871.46 より前の Google Chrome の Skia における信頼されていない入力の検証不足により、リモート攻撃者が特殊に細工された HTML ページを介してレンダラープロセスを侵害し、プロセスメモリから潜在的に機密性の高い情報を取得することが可能でした。（Chromium セキュリティ重大度：中）
Android版Google Chromeのバージョン150.0.7871.46以前のDawnには、信頼されていない入力の検証が不十分な問題がありました。その結果、レンダラープロセスを侵害したリモート攻撃者が、細工されたHTMLページを利用してサンドボックスからの脱出を行う可能性がありました。（Chromiumセキュリティ重大度：高です）
Google Chrome 150.0.7871.46より前のバージョンのSkiaにおいて信頼されていない入力の検証が不足していたため、レンダラープロセスが侵害される可能性があり、リモート攻撃者が細工されたHTMLページを利用してサンドボックスをエスケープできる可能性がありました。（Chromiumセキュリティの重大度：高）
containerdはオープンソースのコンテナランタイムです。バージョン1.7.33、2.3.2、2.2.5、2.1.9、および2.0.10より前のバージョンでは、CRIプラグインがイメージの設定（DockerfileのLABEL命令）からコンテナへのラベルを検証なしで伝播させてしまいます。これにより、コンテナラベルを操作に利用するプラグインを介して、ホスト上で任意のコマンドが実行される可能性があります。この問題はバージョン1.7.33、2.3.2、2.2.5、2.1.9、および2.0.10で修正されています。
ネットワークにアクセスできる悪意のある攻撃者が、UniFi Network Applicationで発見された不適切な入力検証の脆弱性を悪用することで、アプリケーションに対してサービス拒否（DoS）攻撃を実行する可能性があります。
Kibanaにおける不適切な入力検証（CWE-20）は、入力データ操作（CAPEC-153）を介してサービス拒否を引き起こす可能性があります。認証済みユーザーが正しく検証されていない特別に細工されたFleetポリシー入力を送信すると、Fleetエージェント、サーバー、およびポリシー管理機能が利用不能になります。
iOS向けGoogle Chromeのバージョン150.0.7871.47以前において、Chrome for iOSは信頼できない入力の検証が不十分でした。そのため、リモートの攻撃者が特定のUIジェスチャーをユーザーに実行させることで、細工されたHTMLページを介して任意のスクリプトやHTML（UXSS）を注入できる可能性がありました。（Chromiumのセキュリティ深刻度は高です）
iOS版Google Chromeのバージョン150.0.7871.47より前のiOS用Chromeでは、ポリシーの適用が不十分であったため、レンダラープロセスを侵害したリモート攻撃者が細工されたHTMLページを通じてサンドボックスを脱出する可能性がありました。（Chromiumのセキュリティ重大度：高です）
iOS の Google Chrome 150.0.7871.47 未満のバージョンにおける WebAuthentication のサイドチャネルによる情報漏洩の脆弱性により、リモート攻撃者が細工された HTML ページを介してクロスオリジンのデータを漏洩させる可能性がありました。（Chromium セキュリティ深刻度：中）
iOS版Google Chromeのバージョン150.0.7871.47より前のOmniboxにおける信頼されていない入力の検証が不十分であったため、特定のUIジェスチャーをユーザーに行わせることで、リモートの攻撃者が悪意のあるネットワークトラフィックを通じてナビゲーション制限を回避できる可能性がありました。（Chromiumセキュリティの深刻度は中です）
150.0.7871.47 より前の Google Chrome のスペルチェックにおけるポリシー適用の不備により、リモート攻撃者がレンダラープロセスを侵害し、細工された HTML ページを介してプロセスメモリから潜在的に機密性の高い情報を取得できる状態となっていました。（Chromium セキュリティの重大度：中）
iOS向けGoogle Chrome、Chrome for iOSにおいて信頼されていない入力の検証不足が存在しました。この問題はバージョン150.0.7871.47以前の環境で発生し、遠隔の攻撃者がユーザーに特定のUIジェスチャーを行わせることで、細工されたHTMLページを介してナビゲーション制限を回避できる可能性がありました。（Chromiumセキュリティの深刻度は中です）
Windows上のGoogle Chrome 150.0.7871.47以前のバージョンにおいて、Mediaの信頼されていない入力を十分に検証しなかったために、レンダラープロセスが侵害される可能性がありました。リモート攻撃者は、特別に細工されたHTMLページを介してサンドボックスを回避できる可能性がありました。（Chromiumセキュリティの深刻度：中）
Google Chrome 150.0.7871.47より前のバージョンのDeviceBoundSessionCredentialsには信頼されていない入力の検証不足があり、リモート攻撃者が細工されたHTMLページを介して同一生成元ポリシーを回避できる可能性がありました。（Chromiumセキュリティ重大度：中）
出典：JVN（Japan Vulnerability Notes・独立行政法人情報処理推進機構（IPA）／JPCERT コーディネーションセンター／jvn.jp）を加工して作成。 全文検索は当サイト収録分（全289,680件）を対象とし、発表日の新しい順に表示しています。 本情報の最新性・正確性・完全性は保証されません。詳細は各 JVN 詳細ページをご確認ください。 なお本情報は製品・ソフトウェアの脆弱性に関するものであり、特定の法人・製品ベンダの評価や信用性を示すものではありません。