日本公的データラボ脆弱性情報（JVN）
脆弱性情報（JVN）検索・一覧
JVN（IPA／JPCERT/CC 提供）の脆弱性情報 289,756 件を、製品・ベンダ・脆弱性タイプ（CWE）で 全文検索し、深刻度（CVSS）で絞り込めます。発表日の新しい順。各タイトルから詳細（CVSS内訳・関連脆弱性）へ。
直近1年 の検索結果：721–760 件目を表示（ページ 19）
深刻度は CVSS（共通脆弱性評価システム・0〜10 のスコア）に基づく区分：Critical 9.0以上／High 7.0〜8.9／Medium 4.0〜6.9／Low 0.1〜3.9。
Dell PowerProtect Data Domain のバージョン 7.7.1.0 から 8.7、LTS2026 リリースのバージョン 8.6.1.0 から 8.6.1.10、LTS2025 リリースのバージョン 8.3.1.0 から 8.3.1.30、LTS2024 リリースのバージョン 7.13.1.0 から 7.13.1.70 において、不適切なパス名制限（制限されたディレクトリへの「パストラバーサル」）の脆弱性が存在しています。認証されていない遠隔の攻撃者がこの脆弱性を悪用する可能性があり、このことによりシステムへの不正アクセスが発生する恐れがあります。この脆弱性は攻撃者がシステムの完全な制御を奪うことができるため、重大な深刻度に分類されています。したがって、Dell は顧客に対してできるだけ早急にアップグレードすることを推奨しています。
Dell PowerProtect Data Domain のバージョン 7.7.1.0 から 8.7、および LTS2026 リリースのバージョン 8.6.1.0 から 8.6.1.10、LTS2025 リリースのバージョン 8.3.1.0 から 8.3.1.30、LTS2024 リリースのバージョン 7.13.1.0 から 7.13.1.70 に整数オーバーフローまたはラップアラウンドの脆弱性が存在します。認証されていないリモートアクセス可能な攻撃者がこの脆弱性を悪用する可能性があり、その結果、サービス拒否（DoS）攻撃を引き起こす恐れがあります。
Dell PowerProtect Data Domain のバージョン 7.7.1.0 から 8.7、LTS2026 リリースバージョン 8.6.1.0 から 8.6.1.10、LTS2025 リリースバージョン 8.3.1.0 から 8.3.1.30、LTS2024 リリースバージョン 7.13.1.0 から 7.13.1.70 において、不適切な認証の脆弱性が存在します。リモートアクセス権を持つ認証されていない攻撃者がこの脆弱性を悪用する可能性があり、不正アクセスが発生する恐れがあります。本脆弱性は攻撃者にシステムの完全な制御を許すものであるため、重大度はクリティカルと評価されています。したがって、Dell はお客様に対し、可能な限り早急にアップグレードしていただくことを推奨します。
Apache Camel の Keycloak コンポーネントにおける不適切な認証、重要機能に対する認証の欠如、および安全に失敗しない（「Failing Open」）脆弱性です。camel-keycloak の KeycloakSecurityPolicy は、KeycloakSecurityProcessor.beforeProcess() を実行してルートを保護します。このメソッドは連続して3つのチェックを行います。まずアクセストークンを持たないリクエストを拒否し、次に requiredRoles が空でない場合にのみロールを検証し、さらに requiredPermissions が空でない場合にのみ権限を検証します。ベアラーアクセストークンの実際の暗号学的検証（ローカルJWTの場合は署名、発行者、有効期限の確認、トークンイントロスペクションの場合は有効状態と発行者の確認）は、これらのロールおよび権限のチェック内でのみ行われます。KeycloakSecurityPolicy は requiredRoles および requiredPermissions を空のまま（ドキュメント上の「基本設定」）にデフォルト設定しているため、そのように設定されたルートではロールと権限のチェックがスキップされ、したがってアクセストークンの検証が一切行われません。トークンの存在チェックは、トークンが欠落している場合に拒否しますが、不正なトークンは受け入れてしまいます。Authorization: Bearer ヘッダーに任意の非ヌル値、たとえば任意の文字列や偽造された署名なしJWTであってもポリシーが許可し、そのリクエストは署名、発行者、有効期限のチェックなしに保護されたルートに到達し、Keycloak への問い合わせも行われません。トークンは allowTokenFromHeader がデフォルトで true であるため、受信リクエストヘッダーから読み取られます。ルートをこのポリシーで保護する一般的な理由は、そのルートがサーバー側の処理を行うためですが、このバイパスにより、その処理へ認証されていないアクセスが発生します。保護されたルートがコード実行可能なプロデューサに転送する場合、認証なしのリモートコード実行が生じる可能性があります。この欠陥は CVE-2026-23552 とは独立しており、CVE-2026-23552 では発行者クレームに関わる問題が検証ルーチン内にチェックを追加することで解決されましたが、本件ではそもそも検証ルーチンに到達しないため、欠陥が残っています。この問題は Apache Camel のバージョン 4.15.0 から 4.18.3（未満）、および 4.19.0 から 4.21.0（未満）に影響します。ユーザーには本問題を修正したバージョン 4.21.0 へのアップグレードを推奨します。4.18.x 系列の利用者には 4.18.3 へのアップグレードを推奨します。すぐにアップグレードできない環境の場合は、すべての KeycloakSecurityPolicy に対し空でない requiredRoles または requiredPermissions を設定してトークン検証経路を確実に実行させること、トークンをリクエストヘッダーから受け取らない場合は allowTokenFromHeader を false に設定すること、またはポリシー適用前にフレームワーク層でトークン検証を行うことを推奨します。
Coderは、Terraformを通じて組織がリモート開発環境をプロビジョニングできるようにします。バージョン2.29.7、2.32.7、2.33.8、および2.34.2より前のバージョンでは、CoderのOIDCログインに2つの欠陥があり、これが連鎖してアカウント乗っ取りにつながる問題がありました。メールベースのユーザーマッチングは、既存の異なるIdPサブジェクトへのリンクをチェックせずにメールによるリンクにフォールバックしており、`email_verified`クレームは存在してかつブール値の`false`の場合のみ強制されていたため、欠如しているか非ブール値のクレームは検証済みとみなされていました。バージョン2.29.7、2.32.7、2.33.8、および2.34.2の修正では、メールフォールバックを初回およびレガシーリンクに制限し、クレームが欠如しているか予期しない型の場合は`email_verified`をデフォルトでfalseに設定しています。回避策としては、OIDCプロバイダーを設定して自己登録を禁止するか、トークン発行前にメール検証を要求することを推奨します。
Coderは組織がTerraformを通じてリモート開発環境をプロビジョニングできるようにします。バージョン2.29.7、2.32.7、2.33.8、および2.34.2以前のCoderでは、OIDCコールバックにおいて`email_verified`を直接Goの`bool`型としてアサーションしていました。IdPがこのクレームを非ブール値（例えば文字列の"false"）として返したり、省略した場合、アサーションはフェイルオープン（fail open）となり、メールが確認済みとして扱われました。これにより、無条件のメールベースのアカウントフォールバックと組み合わさってアカウント乗っ取りが可能になっていました。バージョン2.29.7、2.32.7、2.33.8、および2.34.2での修正では、`email_verified`をbool型、文字列型、数値型のいずれに対してもフェイルクローズ方式で強制変換し、一致するユーザーがすでに異なるリンク済みIdPのサブジェクトを持っている場合にはメールフォールバックをブロックします。回避策としては、IdPが`email_verified`をネイティブなJSONブール値で返すようにしてください。メールフォールバックのリンクに関する問題は設定で回避できないため、アップグレードが必要です。
CoderはTerraformを通じてリモート開発環境のプロビジョニングを組織に提供します。バージョン2.29.7、2.32.7、2.33.8、および2.34.2以前では、`PUT /api/v2/users/{user}/password`エンドポイントは`ActionUpdatePersonal`のみを認可し、`user-admin`が`owner`アカウントのパスワードをリセットすることを防止していませんでした。また、管理者が他のユーザーのパスワードをリセットする際に現在のパスワードを要求していませんでした。この脆弱性を悪用するには特権のある`user-admin`ロールが必要なため、実際のリスクは`user-admin`ロールをあまり信頼されていないオペレーターに付与している環境に限定されます。バージョン2.29.7、2.32.7、2.33.8、および2.34.2での修正により、`owner`ロールを持つアカウントのパスワードを非オーナーのユーザーがリセットできなくなりました。回避策としては、`user-admin`ロールを信頼できる管理者に限定してください。
Coderは、組織がTerraformを介してリモート開発環境をプロビジョニングできるようにします。バージョン2.17.0から、2.29.7、2.32.7、2.33.8、および2.34.2より前のバージョンにおいて、`POST /api/v2/files`はzipアップロードをメモリ内で`CreateTarFromZip`を介してtarに変換します。この処理では各エントリごとのサイズ制限を課していましたが、展開後の合計出力サイズについては制限がなく、無制限のメモリバッファに書き込んでいました。悪用には認証済みのファイルアップロード権限が必要であり、影響は可用性（サービス拒否）に限定されます。2.29.7、2.32.7、2.33.8、および2.34.2のバージョンでの修正では、予測されるエントリサイズの合計を検証するメタデータ事前チェックを行い、展開中に合計制限を強制するストリーミングライターを追加しています。対策としては、ファイルアップロード権限を信頼できるユーザーに制限するか、`coderd`の前にリクエストボディサイズ制限を行うリバースプロキシを配置することを推奨します。
Coderは組織がTerraformを通じてリモート開発環境をプロビジョニングできるようにするツールです。バージョン2.24.0から2.29.7、2.32.7、2.33.8、2.34.2の前のバージョンにおいて、`provisionersdk/proto/dataupload.go`内の`NewDataBuilder`は、`DataUpload`メッセージからクライアントが提供する`FileSize`を上限チェックなしで使用してバイトスライスを割り当てていました。DRPCの通信上限は4 MiBですが、`FileSize`の値自体には制限がありませんでした。バージョン2.29.7、2.32.7、2.33.8、2.34.2の修正では、割り当て前に`FileSize`を上限値（`MaxFileSize = 100 MiB`）と照合して検証しています。回避策としては、プロビジョナーデーモンのserveエンドポイントへのアクセスを信頼できるプロビジョナーデーモンサービスアカウントに制限することを推奨します。
Coderは組織がTerraformを通じてリモート開発環境をプロビジョニングできるようにします。バージョン2.29.7、2.32.7、2.33.8、および2.34.2以前では、`coder config-ssh`がサーバーから提供されたSSH設定（`HostnameSuffix`、`SSHConfigOptions`）をユーザーの`~/.ssh/config`に埋め込み、改行を消毒せず、ディレクティブの制限も行わずに書き込んでいました。そのため、悪意あるまたは侵害されたCoderサーバーが任意のSSH設定を注入できる可能性がありました。実際の悪用には、悪意あるまたは侵害されたデプロイメント、マンインザミドルの立場、または`HostnameSuffix`および`SSHConfigOptions`設定への管理者アクセスによってサーバー提供値を制御することが必要です。バージョン2.29.7、2.32.7、2.33.8、および2.34.2での修正では、`HostnameSuffix`および`SSHConfigOptions`を厳格な文字セットに対して検証し、改行やその他の制御文字を拒否します。回避策としては、変更を適用する前に`coder config-ssh --dry-run`の出力を確認してください。
CoderはTerraformを通じて組織がリモート開発環境をプロビジョニングできるようにします。バージョン2.29.7、2.32.7、2.33.8、および2.34.2より前のバージョンでは、テイルネットコーディネーターはエージェントの`Addresses`が認証されたUUIDに由来するかどうかを検証しますが、`AllowedIPs`については同様の検証を行っていません。コーディネーターはエージェントから提供された`AllowedIPs`をそのままトンネルピアに転送し、それらをWireGuardピア設定にインストールします。バージョン2.29.7、2.32.7、2.33.8、および2.34.2の修正により、各`AllowedIPs`プレフィックスを`Addresses`と同様に認証エージェントのUUIDに対して検証するようになりました。回避策としては、予期しない`AllowedIPs`プレフィックスを広告するエージェントがいないか、コーディネーターのログを監視することを推奨します。
CoderはTerraformを通じてリモート開発環境のプロビジョニングを組織に提供します。バージョン2.29.7、2.32.7、2.33.8、および2.34.2以前では、`UpsertWorkspaceApp`がプライマリキーの競合時に既存のアプリの`agent_id`を上書きし、`insertAgentApp`はプロビジョナーの`CompleteJob`ペイロードからアプリIDを検証せずに受け入れていました。この`CompleteJob`は`dbauthz.AsProvisionerd`の権限で実行されるため、認可レイヤーがクロスワークスペースのアップサートをブロックしません。悪用にはテンプレート作成者または外部プロビジョナーオペレーターとしての昇格権限が必要です。バージョン2.29.7、2.32.7、2.33.8、および2.34.2の修正では、指定されたIDに一致する既存の`workspace_apps`の行が構築中のワークスペースに属していることを検証し、クロスワークスペースのエージェント再割り当てを拒否します。既知の回避策は存在しません。
CoderはTerraformを介してリモート開発環境をプロビジョニングすることを組織に許可します。バージョン2.29.7、2.32.7、2.33.8、およびそれ以前の2.34.2では、ワークスペースアプリプロキシがターゲットアプリを`httpapi.RequestHost()`から解決しており、これは実際の`Host`ヘッダーよりも`X-Forwarded-Host`ヘッダーを優先します。ルーティング前に`X-Forwarded-Host`を削除するミドルウェアは存在せず、このヘッダーはブラウザで禁止されていないため、クライアントサイドのJavaScriptが`fetch()`呼び出しで設定可能です。実際の悪用には、サブドメインアプリルーティング（ワイルドカードホスト名）が有効であること、攻撃者の共有アプリを訪問する被害者がいること、そして上流プロキシが`X-Forwarded-Host`を削除しないデプロイメントであることが必要です。バージョン2.29.7、2.32.7、2.33.8、および2.34.2の修正では、`X-Forwarded-Host`を構成済みの信頼できるプロキシからのもののみ信頼し、それ以外の場合は検証済みのリクエストホストからルーティングホストを解決します。回避策としては、信頼されていないリクエストに対して`X-Forwarded-Host`を削除または上書きする上流のリバースプロキシを配置してください。
Coderは、Terraformを介してリモート開発環境をプロビジョニングすることを組織に許可します。バージョン2.29.7、2.32.7、2.33.8、および2.34.2以前のバージョンでは、`coder open app` コマンドがスキームやホストを検証せずに外部のworkspace-app URLを開きます。外部アプリのURLに`$SESSION_TOKEN`プレースホルダーが含まれている場合、CLIはユーザーの実際のセッショントークンに置き換えてOSのオープンハンドラにURLを渡します。実際の悪用には、攻撃者が制御する外部アプリ定義を持つワークスペースに対して被害者が`coder open app`を実行する必要があります。外部アプリURLを制御できるのは悪意のあるテンプレート作成者だけです。バージョン2.29.7、2.32.7、2.33.8、および2.34.2での修正により、CLIにURLスキームの許可リストを適用し、`$SESSION_TOKEN`の置換をウェブフロントエンドなどの信頼できる宛先に限定しています。回避策としては、信頼できないワークスペースに対して`coder open app`を実行しないようにしてください。
CoderはTerraformを介してリモート開発環境をプロビジョニングすることを組織に許可します。バージョン2.29.7、2.32.7、2.33.8、および2.34.2より前のバージョンでは、`CreateSubAgent` RPCがテンプレートの`MaxPortSharingLevel`に対して要求されたアプリ共有レベルを検証せずにワークスペースアプリを永続化していました。このため、ワークスペース所有者は管理者が設定した最大値を超えて共有レベルを設定できました。悪用するためには、攻撃者が制御するワークスペースにサブエージェントアプリを登録する必要があります。バージョン2.29.7、2.32.7、2.33.8、および2.34.2の修正では、サブエージェントアプリの共有レベルをテンプレートの`MaxPortSharingLevel`に制限しています。回避策として、ワイルドカードアプホスト名（`CODER_WILDCARD_ACCESS_URL`）を無効化し、サブドメインベースのアプリルーティングをブロックしてください。
Coderは、組織がTerraformを介してリモート開発環境をプロビジョニングできるようにします。バージョン2.29.7、2.32.7、2.33.8、および2.34.2以前では、devcontainerのrecreateエンドポイントはワークスペースに対して`ActionRead`のみをチェックするルートミドルウェアに依存しており、兄弟のdeleteエンドポイントとは異なり、破壊的な再構築を開始する前に`ActionUpdate`のチェックを行っていませんでした。悪用するには、対象のワークスペースにアクセス権を持つ既存の低権限ロールが必要です。バージョン2.29.7、2.32.7、2.33.8、および2.34.2での修正により、deleteエンドポイントと同様に、エージェントがダイヤルされる前に明示的な`ActionUpdate`認可チェックが追加されました。既知の回避策は存在しません。
CoderはTerraformを介して組織がリモート開発環境をプロビジョニングできるようにします。バージョン2.33.0から2.33.8および2.34.2の前のバージョンでは、AI Bridgeプロバイダのハンドラがリクエストボディの最大サイズを指定せずに`io.ReadAll`で読み取っていたため、AI Bridgeへのアクセス権を持つ認証ユーザが任意の大きさのボディを送信し、メモリを枯渇させる可能性がありました。悪用にはAI Bridgeエンドポイントへの認証アクセスが必要であり、影響は可用性（サービス拒否）に限定されます。バージョン2.33.8および2.34.2でこの問題は修正されています。既知の回避策はありません。
Coder は、Terraform を介して組織がリモート開発環境をプロビジョニングできるようにします。バージョン 2.30.0 から 2.32.7、2.33.8、および 2.34.2 より前のバージョンでは、AI Bridge プロキシエンドポイントが `coderd/aibridgedserver` 内の `Server.IsAuthorized` を通じて認証を行います。これはキーの形式、有効期限、秘密情報、削除済みまたはシステムユーザーかどうかを検証しますが、アカウントが停止されているかどうかは確認しません。停止は既存の API キーを無効にしません。そのため、停止されたユーザーの未期限切れトークンは有効なままです。実際の影響は、停止されたユーザーのすでに発行済みの API キーが削除されるまでに限定されます。バージョン 2.32.7、2.33.8、および 2.34.2 でこの問題は修正されています。回避策として、停止時に `DELETE /api/v2/users/{user}/keys` を使い、ユーザーの API キーを削除してください。
CoderはTerraformを介してリモート開発環境をプロビジョニングすることを組織に許可します。バージョン2.30.0から2.32.7、2.33.8、および2.34.2の前のバージョンでは、AI Bridge Proxy（`aibridgeproxyd`）がgoproxyサーバーを作成し、そのデフォルトのトランスポート設定は`InsecureSkipVerify: true`であり、上流プロキシが構成されている場合にのみ安全なトランスポートを割り当てていました。デフォルトの設定（上流プロキシなし）では、CoderアクセスURLへのアウトバウンドHTTPS接続が任意のTLS証明書を受け入れていました。実際の悪用には、AI Bridge ProxyとCoderサーバー間でのオンパス（中間者攻撃）ポジションを確保する必要があります。ループバック上で同一ロケーションに配置されている環境では、実質的に影響を受けません。バージョン2.32.7、2.33.8、および2.34.2での修正によって、システムのルートCAを使用したTLS 1.2以上の安全なトランスポートが無条件に適用されるようになりました。回避策として、CoderアクセスURLが信頼された証明書を使用していることを確認し、AI Bridge ProxyとCoderサーバー間のネットワーク経路（例：ループバックまたはmTLS）を保護することを推奨します。
CoderはTerraformを介してリモート開発環境を組織に提供することを可能にします。バージョン2.29.17、2.32.7、2.33.8、および2.34.2より前のバージョンでは、`AgentLogLine`ダッシュボードコンポーネントが`escapeXML: true`を指定せずに`ansi-to-html`をインスタンス化し、その結果を`dangerouslySetInnerHTML`を通じて挿入していたため、ワークスペースのエージェントログラインに埋め込まれたHTMLがライブマークアップとしてレンダリングされていました。サーバー側のサニタイズ処理はHTMLのメタキャラクターを無効化していませんでした。悪用するには、被害者が攻撃者が制御するエージェントログをダッシュボードで閲覧する必要があります。バージョン2.29.17、2.32.7、2.33.8、および2.34.2の修正では、`escapeXML: true`を有効化し、HTMLメタキャラクターをDOM挿入前にエスケープするようにしました。既知の回避策はありません。
CoderはTerraformを介してリモート開発環境をプロビジョニングすることを組織に許可します。バージョン2.29.17、2.32.7、2.33.8、および2.34.2以前では、Coderのサブドメインベースのワークスペースアプリプロキシにおいて、同一所有者のCORSチェックが回避される可能性がありました。ワークスペース名のサブドメインセグメントがUUIDとして解析された場合、URLのユーザー名が実際の所有者と一致しているか確認せずにIDでワークスペースが解決され、一方でCORSミドルウェアはホスト名内の未検証のユーザー名を信頼していました。実際の悪用には、サブドメインアプリルーティング（ワイルドカードホスト名）が有効であり、被害者が認証されている状態で攻撃者が作成したアプリURLを訪問する必要があります。バージョン2.29.17、2.32.7、2.33.8、および2.34.2の修正では、サブドメインのユーザー名を解決されたワークスペースの実際の所有者と照合し、同一所有者のCORS判定を権威ある所有者のアイデンティティに基づいて行うようにしました。既知の回避策は存在しません。
Apache CamelのAtmosphere Websocketコンポーネントには、不適切な入力検証、認可されていないアクターへの機密情報の露出、およびサーバーサイドリクエストフォージェリ（SSRF）の脆弱性が存在します。camel-atmosphere-websocketのコンシューマは、受信したWebSocketのクエリパラメータに対してHeaderFilterStrategyを適用せずにCamel Exchangeのヘッダーマップにマッピングしています（WebsocketConsumer.sendEventNotification()はWebsocketConsumer.service()で収集されたクエリ文字列マップを反復処理し、各エントリをExchangeにコピーしています）。Camelのヘッダネームスペースをブロックする仕組みがなかったため、WebSocketエンドポイントに接続するクライアントは、クエリパラメータとして単に指定するだけでCamel内部の制御ヘッダー（CamelHttpUri（Exchange.HTTP_URI）など）を設定できました。WebSocketコンシューマが下流のHTTPプロデューサに接続されているルートでは、注入されたCamelHttpUriがサーバー側のHTTPリクエストを攻撃者が選択した宛先へリダイレクトします（サーバーサイドリクエストフォージェリ。例えば内部サービスやクラウドのメタデータエンドポイント）。さらに、HTTPプロデューサは生成された（攻撃者制御下の）URI上のCamelプロパティプレースホルダーを解決するため、注入値中の環境変数参照やアプリケーションプロパティ、Vault参照なども実際の値に解決して送信され、環境変数、アプリケーション設定およびVaultシークレットが漏洩します。WebSocketエンドポイントが認証なしで公開されている場合は、認証されていないリモート攻撃者がこれを利用できます。本問題は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へのアップグレードを推奨します。修正内容としては、HTTP/servletスタックから継承しているHeaderFilterStrategyをコンシューマに適用し、受信時にCamelヘッダネームスペースを大文字小文字を区別せずにフィルター処理することで、外部から提供されたCamel*またはcamel*ヘッダーがExchangeにコピーされないようにしています。直ちにアップグレードできない環境では、下流のプロデューサに到達する前に受信メッセージからCamel制御ヘッダーを削除する（例：ルートの先頭でremoveHeaders('Camel*')やremoveHeaders('camel*')を実行する）、WebSocketエンドポイントで認証を必須とする、不信なコンシューマから直接HTTPプロデューサに接続し、メッセージヘッダーで制御されるターゲットURIを持つ構成を避けることが推奨されます。
Apache CamelのIggyコンポーネントには、不適切な入力検証により権限のない攻撃者に機密情報が露呈し、サーバーサイドリクエストフォージェリ（SSRF）の脆弱性があります。camel-iggyコンシューマは、受信したIggyメッセージのユーザーヘッダーにHeaderFilterStrategyを適用せずにCamel Exchangeのヘッダーマップにマッピングしていました（IggyFetchRecordsはメッセージのユーザーヘッダーをそのままExchangeにコピーしていました）。Camelヘッダーの名前空間をブロックする仕組みがなかったため、Iggyの消費されるストリームやトピックにアクセス可能な攻撃者は、メッセージのユーザーヘッダーとしてCamel内部制御ヘッダー（たとえばCamelHttpUri（Exchange.HTTP_URI））を設定できました。Iggyコンシューマが下流のHTTPプロデューサーにデータを渡すルートでは、注入されたCamelHttpUriによってサーバーサイドのHTTPリクエストが攻撃者の指定した宛先（たとえば内部サービスやクラウドのメタデータエンドポイント）にリダイレクトされる（サーバーサイドリクエストフォージェリ）危険があります。さらに、HTTPプロデューサーは生成された（攻撃者により制御された）URI上のCamelプロパティプレースホルダを解決し、プレースホルダ内の環境変数参照、アプリケーションプロパティ、ボールト参照などを実際の値に解決して攻撃者に送信するため、環境変数やアプリケーションプロパティ、ボールトシークレットが漏洩します。本脆弱性はApache Camelのバージョン4.17.0から4.18.3未満および4.19.0から4.21.0未満に影響します。ユーザーには本問題を修正したバージョン4.21.0へのアップグレードを推奨します。4.18.x系の場合は4.18.3へのアップグレードを推奨します。修正により専用のIggyHeaderFilterStrategy（およびheaderFilterStrategyエンドポイントオプション）が追加され、Camelヘッダー名前空間を大文字小文字を区別せずにインバウンドマッピングでフィルタリングするようになったため、外部から供給されたCamel*またはcamel*ヘッダーはExchangeにコピーされなくなりました。直ちにアップグレードできない展開環境では、下流のプロデューサーに届く前にCamel制御ヘッダーをインバウンドメッセージから削除する（例：ルートの開始部分でremoveHeaders('Camel*')およびremoveHeaders('camel*')を実行すること）、Iggyストリーム／トピックへのパブリッシュ権限を制限すること、および信頼できないコンシューマを直接HTTPプロデューサーに橋渡ししてメッセージヘッダーでターゲットURIを操作できる状態を避けることが推奨されます。
Dell PowerProtect Data Domain のバージョン 7.7.1.0 から 8.6、および LTS2026 リリース バージョン 8.6.1.0 から 8.6.1.10、LTS2025 リリース バージョン 8.3.1.0 から 8.3.1.30、LTS2024 リリース バージョン 7.13.1.0 から 7.13.1.70 に誤った認可の脆弱性があります。リモートアクセスを持つ低権限の攻撃者がこの脆弱性を悪用すると、不正アクセスが発生する恐れがあります。
Apache Camel Undertowコンポーネントにおける機密情報を含むエラーメッセージ生成の脆弱性について説明します。camel-undertowのHTTPサーバーコンシューマーは、ルート処理でエラーが発生した際にクライアントへ返す内容を制御するmuteExceptionオプションを提供しています。このオプションのデフォルト値はfalseですが、他のCamel HTTPサーバーコンポーネント（camel-http、camel-jetty、camel-servlet、camel-platform-http）はtrueをデフォルトとしています。muteException=falseの場合、ルート処理中に例外が発生すると、コンシューマーはHTTPレスポンスボディに空文字を返すのではなく、text/plain形式で完全なThrowableスタックトレースを書き込みます。認証されていないクライアントがエンドポイントに到達し、処理エラー（例えば不正なリクエストボディや無効なパラメータの送信、あるいはルート内部での失敗を引き起こすもの）を発生させると、完全なJavaスタックトレースが返されます。そのようなスタックトレースには、例外メッセージに埋め込まれた資格情報、内部ホスト名やIPアドレス、ファイルシステムパス、依存関係やバージョン情報、データベース名やクラス名、アプリケーションの内部構造などの機密情報が含まれることがあり、攻撃者はこれを悪用してさらなる攻撃を計画する可能性があります。さらに、Rest DSLコンシューマーではmuteExceptionオプションが全く尊重されず、RestUndertowHttpBindingがハードコーディングでfalseに設定されているため、muteException=trueの設定があってもスタックトレースが返されていました。本問題は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-undertowコンシューマーでmuteException=trueを明示的に設定してください（例：undertow:http://0.0.0.0:8080/api?muteException=true、またはグローバル設定としてcamel.component.undertow.mute-exception=trueプロパティ）。これにより、処理エラー時にスタックトレースをクライアントへ返さないようにできます。ただし、影響を受けるリリースでは、この回避策はRest DSLコンシューマーには適用されず、修正が適用されるまでバインディングがmuteExceptionオプションを無視し続ける点にご注意ください。
n8n 2.8.0未満のバージョンには、認証されたユーザーがOAuth2クレデンシャルの認可URLフィールドに悪意のあるJavaScriptのURLを注入できる資格情報管理フローにクロスサイトスクリプティングの脆弱性が存在します。攻撃者は悪意のあるクレデンシャルを作成し、被害者をOAuth認可ボタンのクリックへと誘導することで、被害者の権限でブラウザセッション内において任意のスクリプトを実行させることができます。
n8nのバージョン1.123.18および2.6.2以前では、ZendeskTriggerノードのZendeskウェブフックにおけるHMAC-SHA256署名の検証が失敗します。ウェブフックのURLを知っている攻撃者は、署名されていないPOSTリクエストを送信し、任意の悪意あるデータを使ってワークフローをトリガーすることが可能です。
n8nのバージョン1.123.55未満、2.25.7、2.26.2には、ワークフロー:readスコープを使用して状態変更アクションを認可する三つの変更可能な評価テスト実行エンドポイントに認可の脆弱性があります。本来はアクションに適したworkflow:executeスコープを使用すべきです。Advanced Permissions（Enterprise/Cloud）を使用し、プロジェクトとビューアロールを設定している環境では、project:viewerロールを持つ認証済みユーザーが、読み取り権限のみのワークフローに対して新しい評価テスト実行を開始したり、進行中の実行をキャンセルしたり、実行履歴を削除したりすることが可能です。
n8nのバージョン1.123.55未満、2.25.7、および2.26.2には、POST /workflows/{workflowId}/test-runs/newエンドポイントに認可バイパスの脆弱性が存在します。このエンドポイントは、workflow:executeではなくworkflow:readスコープを使用してアクセスの認可を行っています。読み取り専用アクセス権を持つ認証済みユーザーが、この脆弱性を悪用することで、実際の評価テスト実行をトリガーできます。その結果、内部ワークフロールンナーを介してワークフローが実行され、意図しない外部APIコールやデータの変更、さらに接続された下流システムにおけるその他の副作用を引き起こす可能性があります。この問題は主に、RBACプロジェクトロールがworkflow:executeを付与せずにworkflow:readのみを付与したEvaluations機能を使用しているインスタンスに影響します。
n8nのバージョン2.25.7未満および2.26.xの2.26.2未満には、Public APIの実行再試行エンドポイントに認可バイパスの脆弱性があります。このエンドポイントは、workflow:executeスコープの代わりにworkflow:readスコープを使用してアクセスを許可しています。共有ワークフローに対して読み取り専用アクセス権を持つ認証ユーザーは、Public APIを使用してそのワークフローの実行を再試行できるため、読み取りアクセスと実行アクセス間の意図された権限境界を回避できます。この脆弱性は、ワークフローが他のユーザーやプロジェクト間で共有されているインスタンスに影響を及ぼします。
n8nのバージョン2.28.0未満には、不適切な認可の脆弱性が存在し、認証済みユーザーが他のプロジェクトのフォルダにワークフローを割り当てられる状態です。攻撃者は、ワークフロー作成時に細工されたリクエストペイロードを送信することで、プロジェクトおよびフォルダの認可境界を回避でき、対象プロジェクトのフォルダ構造に論理的整合性の違反を引き起こす可能性があります。
n8nのバージョン1.123.61より前、2.xの2.27.4より前、および2.28.xの2.28.1より前には、レガシーMySQL v1ノードのexecuteQuery操作にSQLインジェクションの脆弱性が存在します。この操作は、評価済みの{{ ... }}式の値をパラメータ化せずにそのまま生のSQL文字列に置換します。ワークフローがこの操作を式由来の値で使用し、外部から到達可能なトリガー（Webhookノードなど）に接続している場合、攻撃者が制御する入力がこれらの式に到達してSQLインジェクションを引き起こす可能性があります。これにより、設定されたMySQL認証情報の権限で任意のSQLを実行できるようになります。パラメータ化クエリを使用するMySQL v2ノードは影響を受けません。
MAX32xxx USBデバイスコントローラドライバ（drivers/usb/udc/udc_max32.c、互換性 adi_max32_usbhs）では、OUTおよびIN転送完了ハンドラ内でエンドポイントバッファをNULLチェックせずに参照していました。udc_event_xfer_out_done()は、buf = udc_buf_get(ep_cfg)の直後にnet_buf_add(buf, ep_request-＞actlen)を呼び出していますが、udc_buf_get()はエンドポイントFIFOが空の場合にNULLを返します。転送完了イベントは割り込みコンテキストからキューイングされ、ドライバスレッドによって非同期に処理されます。キューイングと処理の間に、エンドポイントFIFOはホスト制御の制御フローによって消費される可能性があります。特に、udc_setup_received()は新しいSETUPパケットが到着するたびにEP0のOUT/IN FIFOを消費し、dequeue/disable/purgeのパスでも同様に消費します。したがって、USBホストが進行中のEP0コントロール転送を新たなSETUPパケットで中止する（USBの合法的な動作）と、空のFIFOに対して古いXFER_OUT_DONEイベントが処理され、net_buf_add(NULL, ...)が呼ばれます。これはほぼNULLポインタ参照を引き起こしてデバイスをクラッシュさせる結果となります。認証は不要であり、攻撃者はデバイスに接続されているUSBホスト（物理的なバスアクセス）です。影響はサービス拒否（デバイスクラッシュ）をもたらします。この欠陥はMAX32 UDCドライバが追加され、Zephyr v4.4.0で出荷された際に導入されました。修正では、OUT完了およびIN完了ハンドラの両方でNULLバッファチェックを追加し、早期にUDC_EVT_ERROR/-ENOBUFSを返すようにしています。
ZephyrのDNSリゾルバは、dns_resolve_name_internal()（subsys/net/lib/dns/resolve.c）内でmemcmp(strrchr(query, '.'), ".local", 7)を用いてmDNS（.local）クエリを検出していますが、これは常に接尾辞ポインタから固定の7バイトを読み取ります。解析対象のホスト名の最終ラベルが7バイト未満の場合（例：.org、.com、.net、.ioで終わる名前や末尾にドットがある場合）、比較は文字列のヌル終端子の1〜2バイト先まで読み取ってしまいます。ホスト名（query）は標準のgetaddrinfo()/dns_get_addr_info()/dns_resolve_name()経路を通じて渡される呼び出し元指定の名前であり、オペレーターやリモート入力（設定のサーバ名、解析されたURL、アプリケーション向けインターフェース）によって影響を受ける可能性があります。スラックのない厳密にサイズ指定されたバッファ（例えば、k_usermode_string_alloc_copyで正確にstrlen+1バイト分コピーされたユーザースペースのgetaddrinfo呼び出し）を用いる場合、このオーバーリードは割り当て境界を越えます。その境界がマップされていない場合（ガードページ、MPU下のメモリドメイン境界、またはアドレスサニタイザ）、オーバーリードはフォルトを引き起こし、サービス拒否を招く可能性があります。読み取られたオーバーリードのバイトは返されないため、情報漏洩は発生しません。この脆弱性はCONFIG_MDNS_RESOLVERが有効な場合にのみコンパイルされ、v1.10.0以降に存在し、固定長memcmpをヌル終端安全なstrcmp(ptr, ".local")に置き換えることで修正されています。
nltk/nltk バージョン 3.9.3 以前では、5つの Stanford インターフェイスクラス（StanfordPOSTagger、StanfordNERTagger、StanfordParser、StanfordDependencyParser、および StanfordNeuralDependencyParser）が信頼されていない JAR のコード実行に対して脆弱です。これらのクラスはユーザーが制御可能な JAR パスを受け入れ、`java()` 関数を通じて実行しますが、この関数は整合性検証を行わずに `subprocess.Popen()` を呼び出します。この脆弱性は、SHA256検証の追加によって StanfordSegmenter で修正された CVE-2026-0848 と同一のものです。しかし、この修正はこれらの追加クラスには適用されておらず、信頼されていない JAR ファイルを読み込む際に任意コードが実行されるリスクが残っています。
悪意のあるウェブページは、同期的なJavaScriptダイアログをキューに入れることで保留中のナビゲーションを中断し、ブラウザのUIがアドレスバーに目的地のオリジンを表示し続ける一方で、攻撃者が操作するコンテンツをレンダリングし続ける可能性があります。この脆弱性はFirefox for iOS 152.3で修正されました。
Devolutions Server 2026.2.9.0において、必須多要素認証ポリシーが不適切に適用される問題により、有効なユーザー資格情報を持つ攻撃者がMFA（多要素認証）必須ポリシーを回避し、多要素認証を完了せずに認証を行うことが可能となります。この問題は、DVLSが無効なデフォルトMFA値に遭遇した場合に発生します。
PCVueプロジェクトのユーザーディレクトリに組み込みユーザーの認証情報が安全でない方法で保存されており、バージョン17.0.0より前のすべてのバージョンに影響があります。ローカルの攻撃者がユーザーの認証情報を取得する可能性があります。Active Directoryアカウントはこの脆弱性の影響を受けません。
PcVueプロジェクトの組み込みユーザーディレクトリに保存されているユーザーアカウントの設定を保護するために使用されている暗号化アルゴリズムは、バージョン17.0.0より前のすべてのバージョンにおいて、要求される保護レベルに対して十分に強力ではありません。ローカルの攻撃者は既存の設定を改ざんし、最終的にPcVueアプリケーションに特権アクセスを獲得する可能性があります。
`BaseSerialization.deserialize()` のバグにより、Scheduler や APIサーバーがシリアライズされたDAGを読み込む際に、攻撃者が制御するクラスパスを制限なく `import_string()` できてしまいました。これにより、DAG作成者が悪意のあるトリガーをDAGに埋め込み、APIサーバーや Schedulerプロセス上でリモートコード実行が可能となり、DAG作成者のコードはこれらのプロセス内で決して実行されてはならないという Airflow のセキュリティ境界を越えてしまいました。ユーザーには `apache-airflow` 3.3.0 以降へのアップグレードを推奨します。多層防御策として、DAG作成者の信頼度が限定される環境では、`[core] allowed_deserialization_classes` の設定を狭い許可リストに制限することが推奨されます。
出典：JVN（Japan Vulnerability Notes・独立行政法人情報処理推進機構（IPA）／JPCERT コーディネーションセンター／jvn.jp）を加工して作成。 全文検索は当サイト収録分（全289,756件）を対象とし、発表日の新しい順に表示しています。 本情報の最新性・正確性・完全性は保証されません。詳細は各 JVN 詳細ページをご確認ください。 なお本情報は製品・ソフトウェアの脆弱性に関するものであり、特定の法人・製品ベンダの評価や信用性を示すものではありません。