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

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.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.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）を保護することを推奨します。

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 に誤った認可の脆弱性があります。リモートアクセスを持つ低権限の攻撃者がこの脆弱性を悪用すると、不正アクセスが発生する恐れがあります。

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のバージョン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ノードは影響を受けません。

nltk/nltk バージョン 3.9.3 以前では、5つの Stanford インターフェイスクラス（StanfordPOSTagger、StanfordNERTagger、StanfordParser、StanfordDependencyParser、および StanfordNeuralDependencyParser）が信頼されていない JAR のコード実行に対して脆弱です。これらのクラスはユーザーが制御可能な JAR パスを受け入れ、`java()` 関数を通じて実行しますが、この関数は整合性検証を行わずに `subprocess.Popen()` を呼び出します。この脆弱性は、SHA256検証の追加によって StanfordSegmenter で修正された CVE-2026-0848 と同一のものです。しかし、この修正はこれらの追加クラスには適用されておらず、信頼されていない JAR ファイルを読み込む際に任意コードが実行されるリスクが残っています。

Devolutions Server 2026.2.9.0において、必須多要素認証ポリシーが不適切に適用される問題により、有効なユーザー資格情報を持つ攻撃者がMFA（多要素認証）必須ポリシーを回避し、多要素認証を完了せずに認証を行うことが可能となります。この問題は、DVLSが無効なデフォルトMFA値に遭遇した場合に発生します。

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 に格納型クロスサイトスクリプティングの脆弱性が存在します。認証されていない攻撃者がリモートアクセスを介してこの脆弱性を悪用する可能性があります。悪用された場合、情報漏洩やセッションの乗っ取り、またはクライアントサイドリクエストフォージェリが発生する恐れがあります。

Apache OpenNLP の SvmDoccatModel における信頼されていない Java デシリアライズの脆弱性影響を受けるバージョン: 3.0.0-M4 未満（libsvm ドキュメントカテゴリモジュール；OPENNLP-1808 で導入され、3.x 系列にのみ存在します）説明: SvmDoccatModel.deserialize(InputStream) は攻撃者が制御する java.io.ObjectInputStream を読み込み、ObjectInputFilter が設定されていない状態で readObject() を呼び出します。ObjectInputStream はストリーム内で参照されるすべてのクラスのオブジェクトを、SvmDoccatModel にキャストする前に具現化します。そのため、readObject() の後のキャストは、外部のオブジェクトグラフが完全にデシリアライズされた後に実行されます。もし利用者のクラスパスに Java のデシリアライズ用ガジェットチェーンが存在する場合、deserialize() に渡された細工されたペイロードによって JVM 上で任意のコードが実行される恐れがあります。Apache OpenNLP 自体は既知のガジェットチェーンを含んでいませんが、脆弱なトランジティブ依存関係と共に libsvm モジュールを組み込んだ下流のアプリケーションには現実的なリスクがあります。このメソッドは public かつ static であるため、呼び出し元は直接信頼されていないストリームを渡すことが可能です。実質的な影響としては、信頼されていないまたは半信頼の出所から読み込まれた SvmDoccatModel インスタンスに対してリモートコード実行が可能になることです。緩和策: 3.x 系列の利用者は 3.0.0-M4 へアップグレードしてください。すぐにアップグレードできない場合は、すべてのシリアライズされた SvmDoccatModel ストリームを信頼されていない入力として扱い、その出所が検証されていない限り、エンドユーザーから提供されたストリームや第三者のソースから取得したストリームに対して SvmDoccatModel.deserialize() を呼び出すことを避けてください。

CoderはTerraformを介して組織がリモート開発環境をプロビジョニングできるようにします。バージョン2.29.7および2.30.2より前のバージョンでは、`dotfiles`レジストリモジュールが無検証のユーザー入力をシェルコマンドに渡しており、プロビジョニングされたワークスペース内で任意のコードを実行できました。細工された`dotfiles_uri`の値（例えば、`$(...)`のようなシェルコマンド置換を含むもの）を提供した任意のユーザーは、自身のワークスペースでコマンドを実行することが可能でした。Create Workspaceページの`mode=auto`ディープリンクは、これをワンクリック攻撃に拡大させました。攻撃者は`param.dotfiles_uri`を事前に入力したURLを作成し、ユーザーの明示的な確認なしに、攻撃者が制御する値でワークスペースを静かにプロビジョニングできる状態でした。バージョン2.29.7および2.30.2では、dotfilesモジュールに特別な文字を含むURIやユーザー名を拒否する入力検証が追加され、不安全な`eval`や`sh -c`の使用は削除されました。これにより、コマンドインジェクションは発生源で除去されました。

Apache Camelには信頼されていないデータの逆シリアル化に関する脆弱性があります。いくつかのApache Camelコンポーネントに標準搭載されている防御層としての逆シリアル化フィルタリング用ObjectInputFilterのデフォルトパターン（'java.**;javax.**;org.apache.camel.**;!*'、またはaggregation-repositoryコンポーネントでのjavax.**を含まないバリアント）は、再帰的な'java.**'のグロブを使用しており、hashCode/equals/readObjectメソッドがネットワークI/Oを行うクラス、特にjava.net.URLおよびjava.net.InetAddressを許可しています。攻撃者が影響を受けるCamelコンシューマにJavaシリアライズペイロードを届けられる場合、java.net.URLキーを含むHashMap（またはその要素のhashCodeを呼ぶコレクション）の逆シリアル化が行われると、JVMは逆シリアル化の副作用として攻撃者指定のホストにDNSクエリを発行します。クラスレベルのフィルタチェックは、結果として生成されるオブジェクトのクラス(HashMap)が許可リストに含まれているため通過します。このDNSクエリは攻撃者が制御するDNSサーバーで観測可能であり、アウトオブバンドのサイドチャネルを提供します。camel-jmsファミリーでの暴露度が最も高く、JmsBinding.extractBodyFromJmsがmapJmsMessage=true（デフォルト）の場合にObjectMessage.getObject()を無条件に呼び出すためです。影響を受けるコンポーネントにはcamel-jms、camel-sjms、camel-amqp、camel-mina、camel-netty、camel-netty-http、camel-vertx-http、camel-infinispan、およびaggregation repositoryコンポーネントのcamel-leveldb、camel-cassandraql、camel-consul、camel-sql（JDBC aggregation repository）が含まれます。この問題はApache Camelのバージョン4.14.0から4.14.8未満、4.15.0から4.18.3未満、4.19.0から4.21.0未満に影響します。ユーザーには、対応版であるCAMEL-23372修正を含む4.21.xラインの4.21.0、4.18.xラインの4.18.3、および4.14.xラインの4.14.8へのアップグレードを推奨します。すぐにアップグレードできない環境では、主要な緩和策としてJMSプロバイダ側の許可リスト（Apache ActiveMQ Artemisの'deserializationAllowList' / 'deserializationDenyList'、Apache ActiveMQ Classicの'org.apache.activemq.SERIALIZABLE_PACKAGES'）を構成し、さらにエンドポイントレベルの'deserializationFilter'オプションまたはJVM全体の'-Djdk.serialFilter'システムプロパティを用いて、明示的な拒否を含む'!java.net.**;java.**;javax.**;org.apache.camel.**;!*'（aggregation-repositoryコンポーネント用はjavax.**を含まない'!java.net.**;java.**;org.apache.camel.**;!*'）に上書きすることを推奨します。

Apache CamelのHazelcastコンポーネントに存在する信頼されていないデータの逆シリアライズ脆弱性について説明します。camel-hazelcastコンポーネントは、Javaの逆シリアライズフィルターを適用しないデフォルト設定でHazelcastインスタンスを作成・管理しています。Camelが自身でHazelcastの設定を構築する場合、つまりユーザーが提供するHazelcastInstance、hazelcastConfigUri、または参照されるConfig beanが存在しない場合には、HazelcastのJavaSerializationFilterConfigもCamel側のObjectInputFilterも設定されません。そのため、Hazelcastクラスタープロトコルを介して受信したオブジェクトは、Camelで処理される前にHazelcastのシリアライズレイヤー（ObjectInputStream.readObject）内で逆シリアライズされます。Hazelcastクラスタに参加またはアクセス可能な攻撃者は、細工されたシリアライズ済みJavaオブジェクトを公開することが可能であり、それがすべてのCamelノード上で逆シリアライズされることでリモートコード実行に至る可能性があります。この脆弱性はデフォルトで存在し、特別なエンドポイント設定を必要としません。hazelcast-topic、hazelcast-queue、hazelcast-seda、hazelcast-map、hazelcast-multimap、hazelcast-replicatedmap、hazelcast-list、hazelcast-setを使用する任意のルート、およびHazelcastAggregationRepositoryとHazelcastIdempotentRepositoryは、Camelのデフォルト設定によって管理されるインスタンスが作成される場合に影響を受けます。本問題は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が自身のデフォルト設定から作成するインスタンスに対してデフォルトのHazelcast JavaSerializationFilterConfigを適用し、クラス名プレフィックス「java.」、「javax.」、「org.apache.camel.」をホワイトリストに入れ、「java.net.」をブラックリストに設定しています。ただし、ユーザーが提供するConfigまたはHazelcastInstanceには影響を与えません。すぐにアップグレードできない環境では、Hazelcastインスタンス上で逆シリアライズフィルター（Hazelcast JavaSerializationFilterConfig、もしくはJVM全体のシステムプロパティ -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!*）を設定し、さらにHazelcastクラスタ認証およびTLSを有効化して、クラスタへアクセス可能なユーザーを制限してください。

Apache CamelおよびApache Camel JMSコンポーネントにおける信頼されていないデータのデシリアライズ脆弱性です。camel-jmsのJmsBinding.extractBodyFromJms()および同等のcamel-sjms内のJmsBindingは、mapJmsMessageオプションが有効（デフォルト）かつCamelがJMSコンシューマとして動作している場合に、受信したJMS ObjectMessageのペイロードをjakarta.jms.ObjectMessage.getObject()を通じてデシリアライズします。CVE-2026-40860の強化により、デシリアライズ後にクラスチェックが追加され、デフォルトの許可リスト java.**;javax.**;org.apache.camel.**;!* に含まれないクラスは拒否されます。しかし、org.apache.camel.support.DefaultExchangeHolder自体は許可リストに含まれるorg.apache.camel.**名前空間に存在するため、トップレベルのオブジェクトがDefaultExchangeHolderであるObjectMessageはこのチェックを通過します。受信側はtransferExchangeオプションの有効化を要求せずにDefaultExchangeHolder.unmarshal()を呼び出すため（非対称な信頼境界となっており、送信側はObjectMessageとtransferExchange処理を制御しているものの受信側はしていません）、保持者のすべての非nullフィールドをExchangeに書き込みます：メッセージボディ、INおよびOUTヘッダー、Exchangeのプロパティ、変数、Exchange ID、および例外です。攻撃者は影響を受けるCamelアプリケーションで消費されるキューやトピックにObjectMessageを送信できれば、任意のExchange状態をjava.langおよびjava.utilの普遍的に信頼された型のみを用いて（デシリアライズのガジェットチェーン不要で）注入し、ルーティング・ヘッダー、Exchangeプロパティ、エラー処理を操作できます。同様の取り扱いはcamel-sjms、camel-sjms2、およびJmsComponentとJmsBindingに基づくJMS系コンポーネント（camel-amqp、camel-activemq、camel-activemq6）にも適用されます。これはCVE-2026-40860の修正の回避であり、その欠陥ではありません。影響範囲はApache Camelのバージョン3.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-jms、camel-sjms、およびJMS系コンポーネントではJMS ObjectMessageの取り扱いはデフォルトで無効化されます（objectMessageEnabledという新しいオプションがコンポーネントおよびエンドポイントレベルでデフォルトfalseです）。したがって、DefaultExchangeHolderペイロードを含む受信ObjectMessageは、明示的にオプションを有効にしない限りデシリアライズされません。objectMessageEnabled=trueは、消費しているJMSデスティネーションが信頼されたプロデューサーのみから供給されている場合にのみ設定してください。すぐにアップグレードできない場合は、JMSブローカーの認可を用いてCamelが消費するキューやトピックへのパブリッシュアクセスを信頼できるプロデューサーに制限し、ObjectMessageボディをマッピングするJMSコンシューマを信頼されていないネットワークに公開しないことを推奨します。なお、JMSプロバイダーのデシリアライズ許可リストでは本特定の回避を軽減できません。なぜなら、悪意あるペイロードは普遍的に信頼されたクラスのみを使用しているためです。

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サーバーの認証を有効化して信頼されたクライアントのみが対象サブジェクトに公開できるようにすることを推奨します。

PillowはPythonの画像処理ライブラリです。バージョン12.3.0より前のPIL/PcfFontFile.pyの_load_bitmaps()は、PCFのMETRICSセクションからグリフの寸法を読み取り、それらを直接Image.frombytes()に渡していましたが、Image._decompression_bomb_check()を呼び出していなかったため、細工されたPCFフォントデータにより過剰なメモリ割り当てが発生する可能性がありました。この問題はバージョン12.3.0で修正されました。以上が今回の脆弱性に関する説明です。

PillowはPythonの画像処理ライブラリです。バージョン12.3.0以前のPIL/FontFile.pyのFontFile.compile()は、Image._decompression_bomb_check()を呼び出さずにImage.new("1", (xsize, ysize))でグリフごとの画像を結合したビットマップを組み立てていました。このため、フォントの変換や保存時に過剰なメモリ割り当てが発生する可能性がありました。この問題はバージョン12.3.0で修正されています。

vLLMは、大規模言語モデル（LLM）向けの高スループットかつメモリ効率の良い推論およびサービングエンジンです。バージョン0.24.0以前では、フロントエンドで合法とされる複数リクエストによる推測的デコーディングのワークロードが原因で、リジェクションサンプラーがモデルの語彙サイズの境界値と等しい復元トークンを生成してしまうことがありました。この値は、エンジンがリクエストの次のライブトークンを選択する際に-1（負の値）に変換され、ドラフターの入力IDに書き戻されます。その語彙外の値は後にモデルの埋め込みおよびアテンション経路で使用され、GPUデバイス側のアサーションによりエンジンワーカーがクラッシュしてしまいます。同じトリガーとなるリクエストシーケンスは、公開されているgRPCのGenerateおよびAbortエンドポイントを通じても到達可能なため、生成リクエストを送信できるリモートクライアントが共有されているエンジンワーカーをクラッシュさせ、同時に実行されているリクエストを中断し、ワーカーが再起動されるまで他のクライアントに対するサービス全体のサービス拒否（DoS）状態を引き起こしてしまいます。この問題はバージョン0.24.0で修正されました。

TraefikはオープンソースのHTTPリバースプロキシおよびロードバランサーです。v3.7.0からv3.7.6未満のバージョンにおいて、TraefikのKubernetes Gateway APIプロバイダーは、同じバックエンドService:portをターゲットとする2つのaccepted HTTPRouteを解決する際、それぞれ異なるbackendRefフィルターを同じ子サービスに設定していても、一方のルートのフィルターセットだけをバックエンドに到達するすべてのリクエストに適用してしまう可能性があります。tenant identity（テナントの識別）、認可コンテキスト、あるいはバックエンドが信頼する値などのセキュリティに敏感なヘッダーをbackendRefフィルターで設定しているGatewayのデプロイメントでは、同じバックエンドService:portを共有するaccepted HTTPRouteを作成できる攻撃者が、自身のルートのフィルターコンテキストを別のルートのリクエストに適用してしまいます。さらに、ReferenceGrantによりクロスネームスペースのターゲティングが許可されている場合には、名前空間を越えた影響が及ぶ可能性があります。この問題はv3.7.6で修正されています。

PillowはPythonの画像処理ライブラリです。バージョン12.3.0以前のPIL/BdfFontFile.pyのbdf_char()は、BDFフォントファイルからBBXの幅と高さのフィールドを読み込み、攻撃者が制御する寸法をImage.new()に渡していましたが、その際にImage._decompression_bomb_check()を呼び出さず、Pillowに記載されているデコンプレッションボム保護を回避し、過剰なメモリ割り当てを許可していました。この問題はバージョン12.3.0で修正されています。

PillowはPythonの画像処理ライブラリです。バージョン12.3.0以前では、PIL/GdImageFile.pyのGdImageFile._open()がGD 2.xヘッダーから画像の寸法を読み取り、それらをImage._decompression_bomb_check()を呼び出さずにself._sizeに格納していました。その結果、細工された.gdファイルを読み込む際に過剰なCヒープの割り当てが引き起こされる可能性がありましたが、この問題はバージョン12.3.0で修正されています。

vLLMは、LLM向けの高スループットかつメモリ効率の良い推論およびサービングエンジンです。バージョン0.24.0以前では、structured_outputs.regex APIパラメータはユーザー提供の正規表現文字列をコンパイルタイムアウトなしで直接文法コンパイラのバックエンドに渡していました。xgrammarバックエンドでは文字列がガードなしで正規表現コンパイラに渡され、outlinesバックエンドではルックアラウンドや後方参照などの構造的な問題が検証ステップでブロックされますが、複雑性解析は行われていませんでした。そのため、ネストされた量指定子を含むパターンはすべてのチェックを通過し、指数関数的な状態空間の拡大を引き起こします。結果として、敵対的な正規表現を含む単一のリクエストが推論ワーカーを無期限にハングさせ、サービス拒否を引き起こす可能性がありました。この問題はバージョン0.24.0で修正されています。

Microsoft Edge（Chromiumベース）におけるヒープベースのバッファオーバーフローにより、不正な攻撃者がネットワーク経由でコードを実行できる可能性があります。

Crawl4AIはオープンソースのLLM対応ウェブクローラーおよびスクレイパーです。バージョン0.9.0以前では、Docker APIサーバーは非ストリーミングの/crawlパスに対してSSRF送信先チェックを適用していましたが、ストリーミングパスには適用していませんでした。handle_stream_crawl_requestはシードURLを送信先の検証なしに直接クローラーに渡していたため、認証されていないリモートクライアントがPOST /crawl/stream またはcrawler_config.stream=trueのPOST /crawlを内部、プライベート、またはリンクローカルアドレスを指すURLで呼び出すことが可能でした。その結果、サーバーはそのURLからデータを取得し、レスポンスボディをストリーミングで返していました。この問題はバージョン0.9.0で修正されました。

Microsoft Edge（Chromiumベース）における整数オーバーフローまたはラップアラウンドの脆弱性により、不正な攻撃者がネットワークを介してコードを実行する可能性があります。

Microsoft Edge（Chromiumベース）において、互換性のない型を使用すること（「型混乱」）によってリソースへアクセスされ、不正な攻撃者がネットワークを介してコードを実行できる可能性があります。

Microsoft Edge（Chromiumベース）におけるウェブページ生成時の入力の不適切な無害化（「クロスサイトスクリプティング」）により、不正な攻撃者がネットワーク上でなりすましを行うことが可能となります。

Microsoft Edge（Chromiumベース）における解放後使用（Use after free）の脆弱性により、未承認の攻撃者がネットワークを介してコードを実行できる可能性があります。

Microsoft Edge（Chromiumベース）におけるUse After Freeの脆弱性により、不正な攻撃者がネットワーク経由でコードを実行する可能性があります。

Microsoft Edge（Chromiumベース）における不適切な入力検証により、権限のない攻撃者がネットワーク経由でコードを実行できる可能性がある問題です。

Microsoft Edge（Chromiumベース）における使用後解放の脆弱性により、不正な攻撃者がネットワークを介してコードを実行できる可能性があります。

Microsoft Edge（Chromiumベース）における相対パスのトラバーサルにより、不正な攻撃者がネットワーク経由でコードを実行する可能性があります。

Microsoft Edge（Chromiumベース）におけるファイルアクセス前の不適切なリンク解決（「リンク追跡」）の脆弱性により、不正な攻撃者がネットワーク経由で情報を漏洩させる可能性があります。

Microsoft Edge（Chromiumベース）における解放後使用の脆弱性によって、認可されていない攻撃者がネットワークを介してコードを実行できる可能性があります。