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

node-tarはNode.js向けのtarアーカイブ操作ライブラリです。バージョン7.5.19より前のnode-tarでは、src/extract.tsなどの展開および解析パスにおいて、展開後の総データ量、エントリ数、または展開比率に対する厳格な上限を設けていませんでした。そのため、小さく巧妙に作成されたgzipボムによってディスク容量とCPUが枯渇する可能性がありました。この問題はバージョン7.5.19で修正されています。

node-tarはNode.js向けのtarアーカイブ操作ライブラリです。7.5.18より前のバージョンでは、tar.replaceがチェックサムが有効なtarヘッダーで負のbase-256エンコードされたエントリサイズを受け入れてしまい、アーカイブスキャナが同じヘッダーを繰り返し解析し続けて処理が進まなくなる問題がありました。この問題はバージョン7.5.18で修正されました。

protobufjsはprotobuf定義をJavaScript（JS）関数にコンパイルします。7.6.5および8.6.6より前のバージョンでは、protobufjsはスキーマトークンを進めて=トークンに到達するまでオプション名を解析しましたが、入力の終わりを確認しませんでした。そのため、オプション宣言を開いた状態で途中で終了するように作成された悪意のある.protoスキーマが原因で、parse、Root.load、またはRoot.loadSyncが無限ループに陥る可能性がありました。この問題はバージョン7.6.5および8.6.6で修正されています。

Immutable.jsは多くの永続的なイミュータブルデータ構造を提供しています。バージョン4.3.9および5.1.8より前のList#set、List#setSize、List#setIn、List#updateIn、および関数型のset、setIn、updateInは、src/List.jsのsetListBounds内で2 ** 30から2 ** 31の範囲のインデックスやサイズを誤処理します。これにより、空のListが捕捉不可能な無限ループに陥ったり、要素を持つListがプロセスが中断されるまで制限なくメモリを割り当てたり、setSizeが大きな値を静かにオーバーフローさせる問題が発生します。この問題はバージョン4.3.9および5.1.8で修正されています。

Immutable.jsは多くの永続的な不変データ構造を提供しています。バージョン4.3.9および5.1.8より前のImmutable.MapおよびImmutable.Setは、同じ32ビットハッシュを共有するキーをHashCollisionNodeの衝突バケットに保持し、それを線形にスキャンします。このため、Immutable.Map(obj)、Immutable.fromJS(obj)、state.merge(userObject)、またはmergeDeepなどを通じてMapに挿入されるキーを攻撃者が制御できる場合には、多数の衝突するキーを作成し、挿入および検索処理のパフォーマンスを劣化させて過剰なCPU使用を引き起こすことが可能です。この問題はバージョン4.3.9および5.1.8で修正されています。

Zeek 8.0.9より前のバージョンには、FTPアナライザに制御されていないメモリ消費の脆弱性があります。この脆弱性によって、認証されていないリモート攻撃者が、AUTH GSSAPIを交渉する特別に細工されたFTP制御セッションを送信し、その後に大きなADAT制御行を続けて送ることでプロセスを終了させることが可能です。攻撃者は、NVT_Analyzerコンポーネントに最大行長チェックが欠如している点を悪用し、攻撃者が制御するADATトークンのbase64デコード時に内部バッファを無制限に倍増させ続けるため、結果としてZeekセンサーのサービス拒否を引き起こします。

Zeek 8.0.9より前のバージョンには、Kerberosプロトコルアナライザーにヌルポインタデリファレンスの脆弱性が存在します。この脆弱性により、認証されていないリモート攻撃者が、エラーコード25（KDC_ERR_PREAUTH_REQUIRED）を含むKRB_ERRORメッセージを細工して送信し、padata-typeが2、3、11、または19のPA-DATA要素を含ませることでセンサーをクラッシュさせることが可能です。攻撃者は、proc_padata()が誤った解析パスによって選択された初期化されていないpa_data_elementフィールドをデリファレンスしてしまうパーサーとアナライザの状態の不一致を悪用し、資格情報や事前認証なしに単一のUDPまたはTCPパケットをポート88に送信することでクラッシュを引き起こします。

libXfont2のバージョン2.0.8以前のBitmapScaleBitmapsにおけるヒープバッファオーバーフローは、32ビットサイズのオーバーフローが原因であり、Xサーバーにアクセス可能な攻撃者がXサーバー内でコードを実行するために悪用する可能性があります。

libXfont2のComputeScaledProperties()において、2.0.8より前のバージョンでPCFファイルを解析する際にプロパティバッファのサイズチェックが欠如しているため、ヒープバッファオーバーフローが発生します。この脆弱性は、認証されたXクライアントを使用する攻撃者によって、Xサーバー内でコードを実行される可能性があります。

Apache Camel Luceneコンポーネントにおける、不適切な入力検証およびユーザー制御キーを介した認可バイパスの脆弱性です。camel-luceneプロデューサはExchangeヘッダー（LuceneConstants.HEADER_QUERY）から検索フレーズを読み取りますが、その値はプレーン文字列のQUERY（およびHEADER_RETURN_LUCENE_DOCSに対してはRETURN_LUCENE_DOCS）です。これらの名前はCamel / camelプレフィックスで始まらないため、HTTP境界でCamelヘッダ名前空間のみをブロックするHttpHeaderFilterStrategyは、これらをインバウンドHTTPリクエストからそのままExchangeに通過させてしまいます。HTTPコンシューマー（例えばplatform-http）の背後にLuceneクエリ操作を公開するルートでは、任意のHTTPクライアントがQUERYヘッダーを設定し、その値で全文検索インデックスに対してクエリを実行でき、ルートが実行しようとしていたクエリを上書き可能です。インデックスされている内容によっては、リクエストがアクセスすべきでないドキュメントの読み取り（例：すべてにマッチするクエリが全インデックスを返す、またはルートが意図するユーザーごとのフィルターが置き換えられる）や、高価な正規表現クエリによる大幅なCPUリソース消費を引き起こします。HTTPコンシューマーが認証されていない場合、資格情報は不要です。本脆弱性は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へのアップグレードを推奨します。アップグレード後、QUERY / RETURN_LUCENE_DOCSの生のヘッダー名でクエリを設定しているルートは、代わりにCamelLuceneQuery（およびCamelLuceneReturnLuceneDocs）を使用する必要があります。すぐにアップグレードできない環境では、Luceneプロデューサの前で攻撃者が制御可能なヘッダーを除去し、信頼できるソースからクエリを設定してください（例：ルートの開始時にremoveHeader('QUERY')とremoveHeader('RETURN_LUCENE_DOCS')を実行した後、setHeader('QUERY', constant(...))を設定すること）。

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 PQCコンポーネントにおける信頼されていないデータの逆シリアライズ脆弱性について説明します。camel-pqcコンポーネントは、プラガブルなKeyLifecycleManager実装を通じてポスト量子鍵メタデータ（KeyMetadata）を永続化します。HashicorpVaultKeyLifecycleManagerおよびAwsSecretsManagerKeyLifecycleManagerは、構成されたシークレットバックエンドからメタデータをBase64でラップされた値として読み戻しますが、その際にjava.io.ObjectInputStream.readObject()を生のまま使用し、ObjectInputFilterやクラス許可リストを設定していません。KeyMetadataへのキャストはreadObject()の戻り後に行われるため、細工されたオブジェクト内のreadObject()実行中の副作用は型チェックより先に発生します。同様の制御されていない古いマイグレーションの読み込みはFileBasedKeyLifecycleManager（保存されているKeyPairおよびKeyMetadataのため）にも残っています。これらの値を保持するオペレーター管理のバックエンド（HashiCorp VaultのKVパスやAWS Secrets Managerのシークレット）に書き込み権限を持つ主体は、細工されたシリアライズ済オブジェクトを保存でき、通常の鍵ライフサイクル操作中にそのオブジェクトが逆シリアライズされて、鍵管理を行うアプリケーションのコンテキストでコード実行に至る可能性があります。本問題はCVE-2026-40048（CAMEL-23200）に対する不完全な修正の続きであり、FileBasedKeyLifecycleManagerをJSON / PKCS#8 / X.509フォーマットでメタデータを保存するように変更しましたが、ObjectInputFilterの追加は行わず、VaultおよびAWSの関連マネージャーをカバーしておらず、FileBasedKeyLifecycleManager自身の古いマイグレーション逆シリアライズは未だに制御されていません。本件はApache Camelのバージョン4.18.0から4.18.3未満、および4.19.0から4.21.0未満に影響します。ユーザーには問題を修正したバージョン4.21.0へのアップグレードを推奨します。4.18.xのLTSリリースを使用している場合は4.18.3へのアップグレードが推奨されます。即時アップグレードが困難な環境では、鍵バックエンドへの書き込みアクセスを制限し、アプリケーション自身のIDだけがcamel-pqcシークレットを書き込めるように最小権限のHashiCorp Vaultポリシーおよびsecretsmanager:PutSecretValue IAM権限を設定し、PQC鍵マテリアルを信頼度の低い主体が書き込めるデータと分離されたバックエンドに保持することが推奨されます。

Apache Camel Neo4Jコンポーネントにおけるデータクエリロジック内の特殊要素の不適切な中和による脆弱性です。camel-neo4j プロデューサーは、CamelNeo4jMatchProperties マップからマッチ取得および削除操作の Cypher WHERE 句を構築します。CVE-2025-66169 ではプロパティ値をクエリパラメータ（$paramN）としてバインドすることで Cypher インジェクションに対応しましたが、このマップの JSON キーであるプロパティ名は Neo4jProducer.retrieveNodes() と deleteNode() において依然として検証なしにクエリ文字列に連結されていました。そのため、Cypher 構文を含むプロパティ名が実行されるクエリの構造を変更してしまいます。ルートが信頼されていない入力を CamelNeo4jMatchProperties マップにマッピングする場合（例えば、リクエストボディをマッチマップとして渡す場合や、受信した Camel* ヘッダーをフィルター処理しないコンシューマからの場合）、JSON キー名を制御できる攻撃者は任意の Cypher を注入し、Neo4j データベース内の任意のノードやリレーションシップを読み取り、変更、削除することができます。CamelNeo4jMatchProperties ヘッダー自体は Camel プレフィックス付きで HTTP ヘッダーフィルターストラテジーによりフィルターされるため、単純な HTTP クライアントが直接設定することはできません。しかし、この問題は不信なデータをそのヘッダーに意図的または偶発的に運ぶルートを介して到達可能です。この問題は Apache Camel のバージョン 4.10.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 へのアップグレードが推奨されます。すぐにアップグレードできない場合は、信頼されていない入力から CamelNeo4jMatchProperties マップを生成しないでください。プロパティ名を Neo4j プロデューサーに渡す前に検証または許可リスト化（例：^[A-Za-z_][A-Za-z0-9_]*$ に対する検証）し、そのようなルートにデータを供給するコンシューマは受信した Camel* / camel* ヘッダーをフィルターして外部送信者からのマッチヘッダーの供給を防いでください。

Apache Camel CXF SOAPコンポーネントにおける不適切な入力検証および意図しないプロキシまたは仲介者（「混乱した代理」）の脆弱性について説明します。camel-cxfのプロデューサーは、バックエンドサービスで呼び出すSOAP操作をoperationName（およびoperationNamespace）というExchangeヘッダーから選択します。これらの定数値（CxfConstants.OPERATION_NAME / OPERATION_NAMESPACE）は、プレーンな文字列であるoperationName / operationNamespaceとして定義されています。これらの名前はCamel / camelというプレフィックスで始まっていないため、HTTP境界上でCamelヘッダ名前空間のみをブロックするHttpHeaderFilterStrategyは、それらをインバウンドHTTPリクエストからExchangeにそのまま通過させてしまいます。そのため、HTTPコンシューマー（例：platform-http）からcxf:プロデューサーへのルートにおいて、任意のHTTPクライアントがoperationNameヘッダーを設定し、CxfProducerがルートの意図とは異なるWSDL操作を解決し呼び出すことが可能となります。例えば、読み取り操作を破壊的な操作に置き換えるなど、バックエンドSOAPサービスに対して混乱した代理のリダイレクトが発生します。この定数は共有されるcamel-cxf-commonモジュールで定義されているため、同様にプレフィックスのない名前はcamel-cxfrsにも適用されます。ブリッジするコンシューマーが認証されていない場合は資格情報を必要としません。この問題は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へのアップグレードを推奨します。アップグレード後は、操作選択ヘッダーの名前がCamelCxfOperationName / CamelCxfOperationNamespaceに変更され、トランスポート境界でフィルタリングされるようになります。クロストランスポートキャリアヘッダーパターンの詳細については、4.21のアップグレードガイドをご参照ください。すぐにアップグレードできない環境では、信頼できない入力からCXF操作を選択しないように注意してください。cxf:プロデューサーの前で、信頼できない入力経路からoperationNameおよびoperationNamespaceヘッダーを除去し、ルート内の信頼できるソースから操作を設定してください。

Apache Camel の Vertx Websocket コンポーネントには、不適切な入力検証、認可されていないアクターへの機密情報の漏洩、およびサーバーサイドリクエストフォージェリ（SSRF）脆弱性があります。camel-vertx-websocket コンシューマは、受信した WebSocket のクエリおよびパスパラメータを Camel Exchange ヘッダーマップに、HeaderFilterStrategy を適用せずにマッピングしていました（VertxWebsocketConsumer.populateExchangeHeaders()）。Camel ヘッダ名前空間に対して何もブロックされなかったため、WebSocket エンドポイントに接続したクライアントは、クエリパラメータとして指定するだけで Camel 内部制御ヘッダー（CamelHttpUri（Exchange.HTTP_URI）を含む）を設定できました。WebSocket コンシューマが下流の HTTP プロデューサーにデータを渡すルートにおいては、注入された CamelHttpUri によりサーバー側の HTTP リクエストが攻撃者の選択した宛先にリダイレクトされます（サーバーサイドリクエストフォージェリ。例：内部サービスやクラウドのメタデータエンドポイントへのリクエスト）。さらに、HTTP プロデューサーは結果として得られた（攻撃者が制御する）URI 上で Camel プロパティプレースホルダーを解決するため、注入された値内の環境変数参照、アプリケーションプロパティ、あるいはボールト参照のようなプレースホルダーも実際の値に解決され、攻撃者に環境変数、アプリケーションプロパティ、ボールトシークレットが漏洩します。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 へのアップグレードを推奨します。修正では、影響を受けるコンシューマに対して HeaderFilterStrategy を適用し、インバウンドマッピング時に大文字小文字を区別せずに Camel ヘッダ名前空間をフィルタリングすることで、外部から提供された Camel* / camel* ヘッダーが Exchange にコピーされないようにしています。すぐにアップグレードできない環境では、下流のプロデューサーに到達する前に受信メッセージから Camel 制御ヘッダーを除去する（例：ルートの開始時に removeHeaders('Camel*') と removeHeaders('camel*') を実行する）、WebSocket エンドポイントで認証を必須にする、そして信頼されていないコンシューマーを、直接メッセージヘッダーで制御されるターゲット URI を持つ HTTP プロデューサーにブリッジしない運用を推奨します。

Apache Camelにおける不適切な入力検証の脆弱性です。この問題はApache Camelのバージョン4.8.0から4.18.2、および4.19.0から4.20.0に影響します。ユーザーには、この問題を修正したバージョン4.18.3および4.21.0へアップグレードすることを推奨します。

Apache AirflowのGoogleプロバイダーオペレーターである`GCSToSFTPOperator`および`GCSTimeSpanFileTransformOperator`は、バケットのリスティングAPIから返されたGCSオブジェクト名を正規化や包含チェックを行わずに直接宛先ファイルシステムのパスに結合していました。ソースGCSバケットへの書き込み権限を持つユーザー（通常はDAG作成者とは異なる信頼主体、例えばパートナーのアップロード、取り込み専用サービスアカウント、公開データのバケット）は、名前に`..`セグメントを含むオブジェクトを作成することで、DAG実行時にダウンロードしたBlobを設定された宛先外（`GCSToSFTPOperator`のSFTPの`destination_path`や`GCSTimeSpanFileTransformOperator`のワーカーローカルの一時ディレクトリ）に書き込ませることが可能です。これにより、SFTPサーバーやワーカーホスト上の任意のファイルを上書きできてしまいます。本脆弱性は、より信頼度の低い主体による書き込みが可能なバケットから取り込みを行うデプロイメントに影響します。ユーザーは`apache-airflow-providers-google`をバージョン22.2.1以降にアップグレードすることを推奨します。

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 には、OS コマンドに使用される特殊文字の適切な無害化が行われていない（「OS コマンドインジェクション」）という脆弱性があります。リモートの高権限攻撃者がこの脆弱性を悪用すると、保護機構を回避できる恐れがあります。この脆弱性は、攻撃者が root 権限で任意のコマンドを実行できるため、重大な問題です。したがって、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）攻撃を引き起こす恐れがあります。

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プロバイダーのデシリアライズ許可リストでは本特定の回避を軽減できません。なぜなら、悪意あるペイロードは普遍的に信頼されたクラスのみを使用しているためです。