日本公的データラボ脆弱性情報（JVN）
脆弱性情報（JVN）検索・一覧
JVN（IPA／JPCERT/CC 提供）の脆弱性情報 289,735 件を、製品・ベンダ・脆弱性タイプ（CWE）で 全文検索し、深刻度（CVSS）で絞り込めます。発表日の新しい順。各タイトルから詳細（CVSS内訳・関連脆弱性）へ。
681–720 件目を表示（ページ 18）
深刻度は CVSS（共通脆弱性評価システム・0〜10 のスコア）に基づく区分：Critical 9.0以上／High 7.0〜8.9／Medium 4.0〜6.9／Low 0.1〜3.9。
Coderは、組織がTerraformを介してリモート開発環境をプロビジョニングできるようにします。バージョン2.24.5、2.29.13、2.30.8、2.31.12、2.32.2、および2.33.3以前のバージョンでは、`azureidentity.Validate()`はPKCS#7署名者証明書が信頼されたAzure CAに連鎖していることを検証しますが、PKCS#7署名自体の検証は行いません。攻撃者は正当なAzure証明書を任意のコンテンツ（例：`{"vmId":"＜target＞"}`）と共に埋め込むことができ、改ざんされた`vmId`が受け入れられ、被害者のワークスペースエージェントにセッショントークンが返されます。認証は不要です。攻撃者は対象のVMの`vmId`（UUIDv4）を知っているだけでよく、これが実際的な制約となるため、通常は事前アクセスが必要となります。バージョン2.24.5、2.29.13、2.30.8、2.31.12、2.32.2、および2.33.3でこの問題は修正されています。回避策として、Azureテンプレートを`azure-instance-identity`ではなくトークン認証を使用するように再設定してください。
Apache Camel Mail コンポーネントにおける不適切な入力検証および認可されていない者への機密情報露出の脆弱性について説明します。camel-mail のプロデューサー（MailProducer.getSender）は、送信中の Exchange から mail.smtp. / mail.smtps. 名前空間のメッセージヘッダーをスキャンし、これらが存在すると、それらの値を JavaMail セッションプロパティとして適用し、エンドポイントの設定を上書きした JavaMail の送信者をメッセージごとに生成していました。この名前空間は Camel 内部専用であり、MailProducer のみが解釈しますが、HeaderFilterStrategy によってブロックされず、そのため値は任意の受信プロトコル（例：platform-http のクエリパラメータやリクエストヘッダー、あるいは JMS / Kafka の信頼されていないプロデューサーからのメッセージ）から由来し得ます。これらのヘッダーは、中間で removeHeaders による除去を経ることなく、smtp / smtps プロデューサーへとルートを介して流れます。影響の大きさはバージョンに依存します。4.19.0 より前のリリースでは、mail.smtp.host を設定すると SMTP 接続が攻撃者管理下のサーバーへリダイレクトされ、プロデューサーはエンドポイントに設定されたユーザー名とパスワードで認証するため、これらの資格情報が攻撃者に送信されてしまいます。4.19.0 以降では、プロデューサーはエンドポイント設定のホストに明示的に接続するため、影響はホストのリダイレクトではなく、通信のセキュリティ弱体化（例：mail.smtp.ssl.trust、mail.smtp.starttls.enable、mail.smtp.socks.host）や送信メッセージの傍受に限定されます。悪用には、名前空間を取り除かずに信頼できない入力を mail プロデューサーへ通すルートが必要です。本問題は 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 へのアップグレードを推奨しています。アップグレード後はメッセージごとの上書き機能がデフォルトで無効となるため、信頼できるエンドポイントに対してのみ useJavaMailSessionPropertiesFromHeaders=true を設定して有効化してください。すぐにアップグレードできない環境では、信頼されていない入力の侵入点と smtp / smtps プロデューサー間に removeHeaders('mail.smtp.*') および removeHeaders('mail.smtps.*') を挿入して名前空間を除去することが必要です。オプトイン有効化時でも、不信な入力を通すルートには名前空間の除去を必ず行うべきです。
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 プロデューサーにブリッジしない運用を推奨します。
DNG SDK バージョン 1.7.1 2536 およびそれ以前のバージョンは、NULL ポインタ参照の脆弱性の影響を受ける可能性があり、これによりアプリケーションがサービス拒否（DoS）状態になる恐れがあります。攻撃者はこの脆弱性を悪用してアプリケーションをクラッシュさせ、サービス拒否の状態を引き起こすことが可能です。この問題を悪用するには、被害者が悪意のあるファイルを開くというユーザー操作が必要です。
Apache AirflowのBulk Variables APIは、変数のキーを渡さずにレダクターを呼び出していたため、`*_password`、`*_token`、`*_secret`のようなシークレットが接尾辞となっているキー名に基づく`should_hide_value_for_key`チェックをJSONデコード可能な変数値に対して適用できませんでした。認証済みのUI/APIユーザーで、Bulk Variablesの読み取り権限を持つ者は、本来レダクションが必要なキーに対応するJSON変数のプレーンテキスト値を取得できてしまう可能性があります。この問題は、シークレット接尾辞のついたキー名を持つJSON型Airflow変数に機密情報を保存している環境に影響を与えます。ユーザーは`apache-airflow`の3.3.0以降（修正は3.2.2以降の`main`ブランチにて適用されており、3.2.x系にはバックポートされていません）へのアップグレードを推奨します。
Apache Camelにおける不適切な入力検証の脆弱性です。この問題はApache Camelのバージョン4.8.0から4.18.2、および4.19.0から4.20.0に影響します。ユーザーには、この問題を修正したバージョン4.18.3および4.21.0へアップグレードすることを推奨します。
Apache CamelのDAPRコンポーネントにおける不適切な入力検証により、意図しないプロキシまたは仲介者（「混乱した代理」）の脆弱性が存在します。camel-daprのDapr Pub/Subコンシューマー（DaprPubSubConsumer）は、受信したCloudEventの各フィールドから2つの値、Pub/Subコンポーネント名とトピックをCamelDaprPubSubNameおよびCamelDaprTopicのExchangeヘッダーにコピーしていました。これら2つのヘッダーはプロデューサ方向のルーティングヘッダーであり、ルートがDaprプロデューサを介して再公開を行う際に、DaprConfigurationOptionsProxyがこれらを読み取り、エンドポイントに設定された宛先よりも優先して利用します。その結果、1つのDapr Pub/Subトピックからメッセージを消費して別のトピックに再公開するルート（例：from('dapr-pubsub:p:t').to('dapr-pubsub:p:other')）において、サブスクライブされたトピックにメッセージを発行できるアクターは、CloudEventのpub/sub-nameとtopicを任意の値に設定可能であり、再公開されるメッセージを意図された宛先ではなく任意のDapr Pub/Subコンポーネントおよびトピックに送信させることができます。これにより、メッセージのリダイレクトや情報漏洩が発生し、ルートの意図したルーティングや基盤となるブローカーのトピックレベルアクセス制御を回避できる恐れがあります。悪用には、ルートがサブスクライブするトピックへの発行権限が必要であり、それ以外の認証やユーザー操作は不要です。この問題は、Apache Camelのバージョン4.12.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へのアップグレードを推奨します。すぐにアップグレードできない環境では、ルート内のDaprコンシューマーと任意のDaprプロデューサー間のExchangeからCamelDaprPubSubNameおよびCamelDaprTopicヘッダーを削除（例：removeHeaders('CamelDaprPubSubName', 'CamelDaprTopic')）し、信頼できるプロデューサーのみがサブスクライブしているDapr Pub/Subトピックに発行可能となるように制限してください。
apache-airflow 3.3.0より前のバージョンでは、1つのDagの読み取りが許可されたユーザーが、同じソースファイルに共存する他のDagのソースを開示できてしまう問題がありました。`GET /api/v2/dagSources/{dag_id}` およびUIの同等のDagソース表示は、呼び出し元が読み取りを許可されていないDagを省略することなく、ファイル全体のソースを返しており、Dagごとの読み取り認可を回避していました。複数のDagを単一ファイルに共存させているデプロイメントでは、Dagごとのアクセス制御によりソースの表示を制限している場合に影響を受けます。1ファイルあたり1つのDagのデプロイメントには影響がありません。apache-airflowを3.3.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以降にアップグレードすることを推奨します。
Apache CamelのNetty HTTPコンポーネントにおける、機密情報を含むエラーメッセージ生成の脆弱性です。camel-netty-httpのHTTPサーバーコンシューマは、ルート処理中にエラーが発生した場合にクライアントに返される内容を制御するmuteExceptionオプションを提供しています。このオプションはバックフィールドが初期化されていないプリミティブのboolean型（Javaのデフォルトでfalse）であったため、デフォルト値がfalseになっていました。一方で、他のCamel HTTPサーバーコンポーネント（camel-http / camel-jetty / camel-servlet / camel-platform-http）は、このオプションのデフォルト値をtrueに設定しています。muteException=falseの場合、リクエストがルート処理中に例外を引き起こすと、コンシューマは空のレスポンスボディを返す代わりに、HTTPレスポンスの本文にThrowableの完全なスタックトレースをtext/plain形式で（DefaultNettyHttpBinding経由で）書き込みます。認証されていない任意のクライアントがエンドポイントにアクセスし、例えば不正なリクエストボディや無効なパラメータを送信するなどして処理エラーを引き起こすと、完全なJavaのスタックトレースを受け取ってしまいます。このスタックトレースには、例外メッセージに埋め込まれた認証情報、内部ホスト名やIPアドレス、ファイルシステムのパス、依存関係やバージョンの詳細、データベース名やクラス名、さらにはアプリケーションの内部構造などの機密情報が含まれる可能性があり、攻撃者はこれを用いてさらなる攻撃を計画することが可能です。この問題は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-netty-httpコンシューマのmuteExceptionを明示的にtrueに設定してください（例：netty-http:http://0.0.0.0:8080/api?muteException=true またはグローバルに camel.component.netty-http.configuration.mute-exception=true プロパティを設定してください）。これにより、処理エラー時にスタックトレースがクライアントに返されなくなります。
Hugoは静的サイトジェネレーターです。バージョン0.123.0から0.161.1にかけて、リグレッションによりRootMappingFs.statRootがLstatではなくStat（シンボリックリンクをたどる）を使用するようになりました。そのため、マウント外を指すシンボリックリンクを直接resources.Getで取得すると、ターゲットの内容が返されてしまいました。これにより、ローカルマウント内に植えられたシンボリックリンク（例：vendoredなthemesやテーマ）がHugoユーザーにアクセス可能な任意のファイルを読み取れる状態になっていました。GitHubからのGoモジュールテーマ（シンボリックリンクは除去されます）やディレクトリウォークには影響がありませんでした。この問題はバージョン0.162.0で修正されました。
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 には、不適切なパス名の制限（パス・トラバーサル）脆弱性が存在します。この脆弱性を悪用すると、リモートからアクセス可能な高権限の攻撃者が認可されていないファイルを改ざんする可能性があります。
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判定を権威ある所有者のアイデンティティに基づいて行うようにしました。既知の回避策は存在しません。
出典：JVN（Japan Vulnerability Notes・独立行政法人情報処理推進機構（IPA）／JPCERT コーディネーションセンター／jvn.jp）を加工して作成。 全文検索は当サイト収録分（全289,735件）を対象とし、発表日の新しい順に表示しています。 本情報の最新性・正確性・完全性は保証されません。詳細は各 JVN 詳細ページをご確認ください。 なお本情報は製品・ソフトウェアの脆弱性に関するものであり、特定の法人・製品ベンダの評価や信用性を示すものではありません。