全国公的データラボ脆弱性情報（JVN）
脆弱性情報（JVN）検索・一覧
JVN（IPA／JPCERT/CC 提供）の脆弱性情報 292,331 件を、製品・ベンダ・脆弱性タイプ（CWE）で 全文検索し、深刻度（CVSS）で絞り込めます。発表日の新しい順。各タイトルから詳細（CVSS内訳・関連脆弱性）へ。
種別 不適切な入力確認 直近1年 の検索結果：121–160 件目を表示（ページ 4）
深刻度は CVSS（共通脆弱性評価システム・0〜10 のスコア）に基づく区分：Critical 9.0以上／High 7.0〜8.9／Medium 4.0〜6.9／Low 0.1〜3.9。
環境変数の処理に問題が存在していました。この問題は検証の強化によって対処されました。この問題は macOS Sequoia 15.7.8、macOS Sonoma 14.8.8、macOS Tahoe 26.6 で修正されています。アプリケーションが予期しないシステムの終了を引き起こす可能性があります。
入力サニタイズの改善により、検証の問題が解決されました。この問題は、iOS 16.6、iPadOS 16.6、macOS Tahoe 16.6、tvOS 16.6、visionOS 16.6、watchOS 16.6で修正されています。悪意のある細工が施されたアプリがコード署名の強制を回避できる可能性があります。
Apache NimBLE の Mesh Proxy SAR 再構成における不適切な入力検証の脆弱性により、アプリケーションに破損したデータが渡され、メモリ負荷の増大や不安定な解析動作を引き起こす可能性があります。この問題は Apache NimBLE バージョン 1.9.0 までに影響があります。ユーザーは、この問題を修正したバージョン 1.10.0 にアップグレードすることを推奨します。
NLnet Labs の Unbound バージョン 1.23.0 から 1.25.1 まで（含む）において、「dns-error-reporting: yes」が設定されている場合、最後の上流レスポンスから EDNS Report-Channel オプション（コード 18）が読み取られ、そのオプションの長さがエージェントドメインの長さとして使用されます。エージェントドメインに対してドメイン名の検証が行われる際、返される長さは使用されず、もしエージェントドメインの後にゴミデータが続いている場合、それらのバイトは合成された「_er.」レポートクエリ名の末尾に移動されます。そのクエリ名は後にイテレータ内のサブクエリを通じて DNS エラーレポートの送信に使われます。Unbound が「find_closest_of_type()」中にそのクエリ名を走査しようとするとき、埋め込みルートで停止せずクエリ名の長さに基づいてラベルを切り取るため、1 バイト余分に走査します。そして、その最初のゴミバイトをラベル長として「dname_query_hash()」に渡し、スタック変数「labuf」を上書きします。攻撃者が制御する委任ゾーンからの通常の上流レスポンス 1 つだけで、デーモンを終了させることが可能です。
DOMに関する別の問題として、コピー＆ペーストおよびドラッグ＆ドロップのコンポーネントに脆弱性があります。この脆弱性はFirefox 153およびThunderbird 153で修正されました。
150.0.7871.182 より前の Google Chrome における Chromecast の信頼されていない入力の検証が不足していたため、ローカル攻撃者が悪意のあるネットワークトラフィックを介してサンドボックスをエスケープできる可能性がありました。（Chromium セキュリティの重大度は高です）
Google Chrome 150.0.7871.182より前のバージョンの拡張機能において、信頼されていない入力の検証が不足していたため、リモートの攻撃者が細工されたHTMLページを介してOmnibox（URLバー）の内容を偽装することが可能でした。（Chromiumのセキュリティ重大度は高です）
Google Chrome 150.0.7871.182より前のバージョンにおけるWebAudioの不適切な実装によって、リモートの攻撃者が細工されたHTMLページを通じてサンドボックス内で任意のコードを実行できる脆弱性が存在していました。（Chromiumセキュリティの重大度：高と評価されています）
Linux上のGoogle Chrome 150.0.7871.182未満のバージョンにおいて、証明書の信頼されていない入力の検証が不十分であったため、権限のあるネットワークに存在する攻撃者が悪意のあるネットワークトラフィックを介してドメインになりすますことが可能でした。（Chromiumセキュリティ重大度：高）」
SurrealDBのバージョン3.2.0より前のバージョンには、SurrealMLヘッダーパーサーにサービス拒否の脆弱性が存在しています。この脆弱性により、認証されたOwnerロールのユーザーが、不正な形式の.surmlファイルを/ml/importエンドポイントにアップロードすることでサーバーをクラッシュさせることができます。攻撃者は数値以外のinput-dimensionsやその他の不正なヘッダーフィールドを供給し、検証されていないunwrap呼び出しを誘発させることでパニックを引き起こし、サーバープロセス全体を中断させ、すべてのデータベースに対するサービスを拒否させます。
xrdpはオープンソースのRDPサーバーです。バージョン0.10.6およびそれ以前には、FIPS特有の受信パスにおいてヒープの範囲外読み取り脆弱性が存在していました。この脆弱性はxrdpのデフォルト設定には影響しません。脆弱性が悪用可能になるのは、セキュリティレイヤーがsecurity_layer=negotiateまたはsecurity_layer=rdpに設定され、かつxrdp.iniで暗号レベルがcrypt_level=fipsに変更された場合に限られます。この特定の非デフォルトモードでは、サーバーがFIPSパディング長フィールドの検証に失敗し、ポインタのアンダーフローおよび負の長さ計算が発生します。認証されていないリモート攻撃者は、細工されたFIPS保護PDUを送信することでこれを悪用し、ヒープの範囲外読み取りを引き起こしてプロセスクラッシュおよびサービス拒否（DoS）を招きます。しかし、xrdpはデフォルトで各接続ごとに新しいプロセスをフォークするため、範囲外読み取りによるプロセスクラッシュがxrdpサービス全体の停止につながる可能性は低いです。この問題はバージョン0.10.6.1で修正されました。
Squidはウェブ向けのキャッシュプロキシです。バージョン7.6以前では、cache digestの応答処理（src/peer_digest.ccのpeerDigestSwapInMask）における不適切な入力検証のバグにより、Squidにヒープベースのバッファオーバーフローの脆弱性が存在します。キャッシュダイジェストのオンザワイヤサイズが、ダイジェスト内で宣言されたmask_sizeより大きくなる可能性があり、そのため信頼されたピアが悪意を持って細工したcache_digestリクエストメッセージへの応答を送信すると、オーバーフローが発生する可能性があります。この攻撃は、--enable-cache-digestsオプション付きでコンパイルされ、かつcache_peer設定があるSquidインスタンスに限定されます。この問題はバージョン7.6で修正されています。
Symfony UXはSymfonyのためのJavaScriptエコシステムです。バージョン2.8.0から2.36.0および3.1.0までの間、#[LiveProp]がDateTimeInterface型で明示的なフォーマットが設定されていない場合、Symfony\UX\LiveComponent\LiveComponentHydrator::hydrateObjectValue()はnew $className($value)にフォールバックしていました。これにより、クライアントが提供した「now」や「tomorrow」、「+10 years」のような相対的な文字列が、フォーマットなしの書き込み可能な日付プロパティを通じて時刻に基づくビジネスロジックのチェックを回避し、不正に操作できる状態になっていました。この問題はバージョン2.36.0および3.1.0で修正されています。
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 セキュリティ重大度：中）
脆弱性情報（JVN） よくある質問
脆弱性を製品名やベンダ名で検索できますか？
はい。製品・ベンダ・脆弱性タイプ（CWE）で全文検索し、深刻度（CVSS）で絞り込めます。発表日の新しい順に表示します。
CVSS（深刻度）とは何ですか？
脆弱性の深刻さを0〜10で表す共通指標です。数値が大きいほど影響が大きく、緊急・重要・警告・注意などの区分で絞り込めます。
影響を受ける製品やベンダ企業は分かりますか？
各脆弱性の詳細ページで、影響を受ける製品・ベンダを確認できます。ベンダ名は法人検索と突き合わせて企業情報もたどれます。
情報の出典を教えてください。
JVN（IPA〔情報処理推進機構〕・JPCERT/CC 提供）の公開情報を収録しています。対応の要否は必ず各JVN詳細・公式情報でご確認ください。
出典：JVN（Japan Vulnerability Notes・独立行政法人情報処理推進機構（IPA）／JPCERT コーディネーションセンター／jvn.jp）を加工して作成。 全文検索は当サイト収録分（全292,331件）を対象とし、発表日の新しい順に表示しています。 本情報の最新性・正確性・完全性は保証されません。詳細は各 JVN 詳細ページをご確認ください。 なお本情報は製品・ソフトウェアの脆弱性に関するものであり、特定の法人・製品ベンダの評価や信用性を示すものではありません。