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

Coderは、組織がTerraformを通じてリモート開発環境をプロビジョニングできるようにするツールです。バージョン2.24.5、2.29.13、2.30.8、2.31.12、2.32.2、および2.33.3より前のバージョンには、Azureインスタンス識別エンドポイント（`POST /api/v2/workspaceagents/azure-instance-identity`）を介した認証されていないセミブラインドなサーバーサイドリクエストフォージェリ（SSRF）の脆弱性が存在します。外部の攻撃者は、細工されたPKCS#7署名を送信することで、Coderサーバーに任意の内部または外部ホストに対してHTTP GETリクエストを発行させることが可能です。サーバーはターゲットのレスポンスボディを返しませんが、APIレスポンス内のエラーメッセージによって、ターゲットが到達可能かどうかおよび発生した障害の内容を判別できます。バージョン2.24.5、2.29.13、2.30.8、2.31.12、2.32.2、および2.33.3ではこの問題が修正されています。回避策として、AzureのID認証機構を使用していない場合は、対応するエンドポイント（`/api/v2/workspaceagents/azure-instance-identity`）へのアクセスをingressファイアウォールやプロキシのACLで制限してください。

OP-TEEは、Arm Cortex-Aコア上で動作する非セキュアなLinuxカーネルの補助として設計されたトラステッド・エクゼキューション・環境（TEE）であり、TrustZone技術を利用しています。バージョン3.20.0から4.11.0より前のバージョンにおいて、OP-TEEのサブキーのロールバック保護に脆弱性が存在します。これは、サブキーのバージョン管理データがトラステッドアプリケーション（TA）の読み込み処理中に伝播されないためであり、その結果、取り消された古いサブキーを使用できてしまいます。`core/crypto/signed_hdr.c`の`shdr_load_pub_key()`関数はサブキーヘッダーを解析しますが、`subkey_version`をランタイムの`shdr_pub_key`構造体に割り当てていません。そのため、`key-＞version`フィールドはヘッダーで指定されたバージョンに関係なく常にゼロのままです。さらに、`core/kernel/ree_fs_ta.c`の`ree_fs_ta_open()`が`check_update_version()`を呼び出す際に、このゼロのバージョンがロールバックデータベースに渡されます。データベースは記録すべき非ゼロのバージョンを受け取らないため更新されず、ロールバックチェックが事実上無効となってしまい、ダウングレードされたサブキーのチェーンで署名されたTAの読み込みに成功してしまいます。この脆弱性は、サブキーベースの署名チェーンを用いてTA認証を行うOP-TEEのメインライン構成に影響を及ぼします。バージョン4.11.0で修正パッチが含まれており、既知の回避策は存在しません。

Microsoft Edge（Chromiumベース）における重要な情報のユーザーインターフェース（UI）の誤表示により、不正な攻撃者がネットワーク上でなりすましを行うことが可能となります。

Microsoft Edge（Chromiumベース）になりすましの脆弱性があります。

Apache Camel ElasticSearch Rest Clientの不適切な入力検証およびユーザー制御キーによる認可バイパスの脆弱性についてご説明します。camel-elasticsearch-rest-clientコンポーネントは、その動作を制御するために複数のExchangeヘッダー（SEARCH_QUERY（高度なクエリボディ）、OPERATION（実行するElasticsearch操作）、INDEX_NAME、INDEX_SETTINGS、ID）を読み取ります。これらのヘッダー定数の文字列値はElasticSearchRestClientConstantに定義されており、他のすべてのCamelコンポーネントが使用する「Camel」接頭辞付きの名前（例：CamelSqlQuery、CamelMongoDbCriteria、CamelCqlQuery）ではなく、単なる接頭辞なしの名前（'SEARCH_QUERY'、'OPERATION'、'INDEX_NAME'、'INDEX_SETTINGS'、'ID'）となっています。Camelの受信HTTPヘッダーフィルターであるHttpHeaderFilterStrategyは、「Camel」または「camel」で始まるヘッダー名のみをブロックします。Elasticsearchのヘッダー名はその接頭辞を持たないため、受信フィルターを通過してしまいます。Camelルートがelasticsearch-rest-clientプロデューサの前にHTTPエントリポイント（例：platform-http）を公開している場合、信頼されていないHTTPクライアントはこれらのヘッダーを直接リクエストに設定し、ルート作成者が構成したクエリや操作を上書きできてしまいます。例えば、インデックス内のすべてのドキュメントの読み取り（match_allクエリを伴うSEARCH_QUERY）、ドキュメントの削除（OPERATIONをDeleteに設定しIDを指定）、選択されたフィールドの持ち出しなどが可能です。認証情報は不要であり、プロデューサはこれらヘッダーを無条件に読み取っています。この問題はApache Camelの以下のバージョンに影響します：4.3.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-elasticsearch-rest-clientのExchangeヘッダー定数の文字列値（ID、SEARCH_QUERY、INDEX_SETTINGS、INDEX_NAME、OPERATION）に「Camel」接頭辞（CamelElasticsearchId、CamelElasticsearchSearchQuery、CamelElasticsearchIndexSettings、CamelElasticsearchIndexName、CamelElasticsearchOperation）を付加し、HttpHeaderFilterStrategyの受信フィルタでブロックされるようにしました。Javaのフィールド名は変更していません。すぐにアップグレードできない環境では、elasticsearch-rest-clientエンドポイントの前で、信頼されていない受信メッセージから影響を受けるヘッダー（'SEARCH_QUERY'、'OPERATION'、'INDEX_NAME'、'INDEX_SETTINGS'、'ID'）を削除するか、これらの名前をブロックするカスタムのHeaderFilterStrategyを適用してください。

Apache CamelのJIRAコンポーネントには、不適切な入力検証およびユーザー制御キーを通じた認可回避の脆弱性が存在します。camel-jiraプロデューサーは、操作パラメーター（Issue Key、Project Key、Transition ID、Summary、Type、Assignee、Components、Watchers、Link Type、Work-log Minutesなど）をExchangeメッセージのヘッダーから読み取ります。JiraConstantsで定義されたヘッダー定数（例：ISSUE_KEY＝IssueKey、ISSUE_PROJECT_KEY＝ProjectKey、ISSUE_TRANSITION_ID＝IssueTransitionId、LINK_TYPE＝linkType）は、Camelの接頭辞が付いていないプレーンな値を使用していました。これらの名前はCamelまたはcamelで始まらないため、HTTP境界でCamelヘッダー名前空間のみをブロックするHttpHeaderFilterStrategyによってインバウンドのHTTPリクエストから直接Exchangeへ通過してしまいます。HTTPコンシューマー（例：platform-http）をjira:プロデューサーにブリッジするルートでは、任意のHTTPクライアントがこれらのヘッダーを提供でき、その結果ルートが意図した値を上書きできます。これにより、エンドポイントのサービスアカウント資格情報を使って設定されたJIRAインスタンスに対し、任意の課題の削除や状態遷移（IssueKey / IssueTransitionId経由）、異なるプロジェクトでの課題作成（ProjectKey経由）、課題フィールドの変更、ウォッチャーの追加・削除、作業ログの記録などの操作を実行可能となります。これらの操作は、設定されたサービスアカウントの権限によって制限されています。ブリッジングされるコンシューマーが認証されていない場合には、攻撃者が資格情報なしで攻撃を行うことも可能です。この問題は以下の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へのアップグレードが推奨されます。アップグレード後、JIRA操作を生のヘッダー名でドライブするルートは、旧来の値の代わりにCamelJira*名（例：CamelJiraIssueKey）を使用する必要があります。即時のアップグレードが困難な場合は、信頼できない入力からjira:プロデューサーに渡す前に、camel-jiraの制御ヘッダー（IssueKey、ProjectKey、IssueTransitionIdなど関連ヘッダー）をルートの先頭で削除し、JIRA操作に必要なパラメーターを信頼されたソースから設定してください。

Apache CamelのIRCコンポーネントにおける「入力検証の不備」および「ダウンストリームコンポーネントで使用される出力内特殊要素の不適切な無害化（『インジェクション』）」の脆弱性です。camel-ircプロデューサーは、送信するIRCメッセージの宛先をExchangeヘッダーのirc.sendTo（定数IrcConstants.IRC_SEND_TO、値はirc.sendTo）から選択します。このヘッダーが存在する場合、エンドポイントで設定されたチャンネルリストを上書きし、メッセージは指定された宛先のみに送信されます。さらに、コンポーネントの制御用ヘッダー（irc.target、irc.messageType、irc.user.*、irc.num、irc.value）はプレフィックスなしの通常の値を使用しています。これらのヘッダー名はCamel / camelのプレフィックスで始まらないため、HTTP境界でCamelのヘッダ名前空間のみをブロックするHttpHeaderFilterStrategyにより、これらはインバウンドHTTPリクエストからそのままExchangeに通過します。HTTPコンシューマー（例：platform-http）からirc:プロデューサーへルートを橋渡しする場合は、任意のHTTPクライアントがirc.sendToヘッダーを設定でき、ルートが元々設定していたチャンネル宛てのメッセージを任意のIRCチャンネルやユーザーにリダイレクトすることが可能となります。これにより、メッセージ内容が攻撃者に選ばれたニックネームに漏洩したり、公開チャンネルへ流出したり、ボットから送信されたように見えるメッセージを届けられたりします。橋渡し先のコンシューマーが認証不要の場合、認証情報は必要ありません。この問題は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へのアップグレードが推奨されます。アップグレード後は、IRCヘッダーを生のヘッダー名で設定しているルートについては、古いirc.*の値ではなくCamelIrc*の名前（例：CamelIrcSendTo）を使用する必要があります。すぐにアップグレードできない環境では、irc:プロデューサーの前に信頼できない入力からのirc.*ヘッダーを除去する（例：ルート開始時にremoveHeaders('irc.*')を使用）とともに、IRC宛先は信頼できるソースから設定してください。

Apache Camel Kafkaコンポーネントにおける、不適切な入力検証および下流コンポーネントで使用される出力中の特殊要素の不適切な無害化（インジェクション）による脆弱性です。camel-kafkaプロデューサーは、kafka.OVERRIDE_TOPIC Exchangeヘッダーからランタイムで設定されたターゲットトピックを上書きできます。KafkaProducer.evaluateTopic()は、エンドポイントに設定されたトピックよりもヘッダー値を優先して返します。KafkaConstantsのコントロールヘッダー定数（例えばOVERRIDE_TOPIC = kafka.OVERRIDE_TOPIC、OVERRIDE_TIMESTAMP = kafka.OVERRIDE_TIMESTAMP、PARTITION_KEY = kafka.PARTITION_KEY）は、Camelプレフィックスなしの単純な値を使用していました。camel-kafka独自のKafkaHeaderFilterStrategyはkafka.*名前空間をフィルターしますが、これはKafkaからExchangeへの直列化境界（KafkaレコードヘッダーのExchangeへの読み込みおよびExchangeヘッダーのKafkaレコードへの書き込み）にのみ適用されます。マルチコンポーネントルートで上流のコンシューマーから到着するヘッダーには適用されません。上流のHTTPコンシューマーはHttpHeaderFilterStrategyを使用しており、Camel/camel名前空間のみをブロックするため、kafka.*ヘッダーはフィルターされずに通過します。その結果、HTTPコンシューマー（例えばplatform-http）からkafka:プロデューサーへのブリッジとなるルート内では、任意のHTTPクライアントがkafka.OVERRIDE_TOPICヘッダーを設定し、メッセージを設定されたトピックではなく任意のKafkaトピックに公開させることが可能です。これにより、内部の機密トピックへリダイレクトしたり、重要な下流サービスが消費するトピックに攻撃者が作成したメッセージを注入したりする恐れがあります。関連するkafka.OVERRIDE_TIMESTAMPおよびkafka.PARTITION_KEYヘッダーも同様に注入されるため、メッセージの過去日時化や特定パーティションの指定が可能となります。ブリッジングコンシューマーが認証されていない場合は認証情報が不要です。本問題は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へのアップグレードを推奨します。アップグレード後は、Kafkaヘッダーを直接のヘッダー名で設定または読み取りするルートにおいて、旧来のkafka.*値ではなく、CamelKafka*名（例：CamelKafkaOverrideTopic、CamelKafkaTopic）を使用する必要があります。すぐにアップグレードできない場合は、kafka:プロデューサー前の信頼できない入口からkafka.*ヘッダーを除去してください（例：ルートの冒頭でremoveHeaders('kafka.*')を実行）。また、ターゲットトピックは信頼できるソースから設定することを推奨します。

Apache Camel Salesforceコンポーネントにおける、「ダウンストリームコンポーネントで使用される出力内の特殊要素の不適切な無害化（インジェクション）」および「ユーザー制御キーによる認可バイパス」の脆弱性についてご説明します。camel-salesforceプロデューサーは、その操作パラメータ（SOQLクエリ、SOSL検索、対象SObjectの名前とID、Apex RESTのURLおよびメソッド、Apexクエリパラメータ）をExchangeメッセージヘッダーから解決します。ヘッダーはエンドポイント設定値より優先して読み取られます（AbstractSalesforceProcessor.getParameter()はまずヘッダーを読み取り、フォールバックとしてエンドポイント設定を使用します）。SalesforceEndpointConfig内の制御ヘッダー定数（例：SOBJECT_QUERY = sObjectQuery、SOBJECT_SEARCH = sObjectSearch、SOBJECT_NAME = sObjectName、SOBJECT_ID = sObjectId、APEX_URL = apexUrl、APEX_METHOD = apexMethod、およびapexQueryParamプレフィックス）は、Camelのプレフィックスなしの単純な名前を使用しています。これらの名前はCamelまたはcamelというプレフィックスで始まらないため、HTTP境界でCamelヘッダー名前空間のみをブロックするHttpHeaderFilterStrategyは、これらのヘッダーをインバウンドHTTPリクエストからExchangeへ通過させてしまいます。HTTPコンシューマ（例：platform-http）をsalesforce: プロデューサーへブリッジするルートにおいては、任意のHTTPクライアントがこれらのヘッダーを設定し、ルートの意図した操作を上書き可能です。攻撃者は独自のSOQLクエリやSOSL検索を提供し、接続されたSalesforceユーザーがアクセス可能な任意のSObjectデータを読み取ったり、CRUD操作の対象SObject名やIDを上書きしたり、Apex REST呼び出し先のエンドポイントやHTTPメソッド（破壊的メソッドを含む）を変更してクエリパラメータを注入したりできます。これらの操作はすべて、通常広範な権限を持つSalesforce接続（統合）ユーザーの完全な権限で実行されます。ブリッジングコンシューマが認証不要の場合、攻撃者は資格情報なしで悪用することも可能です。この問題は、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へのアップグレードが推奨されます。アップグレード後は、Salesforce操作パラメータを生のヘッダー名で設定しているルートにおいて、旧来のsObject* / apex*値の代わりにCamelSalesforce*（例：CamelSalesforceSObjectQuery、CamelSalesforceApexUrl）を使用しなければなりません。エンドポイントオプションの綴りは変更ありません。すぐにアップグレードできない環境では、信頼できない入力からsalesforce: プロデューサーへ渡す前にSalesforce制御ヘッダー（例：removeHeaders('sObject*')およびremoveHeaders('apex*')をルートの開始時に実行）を削除し、クエリ、SObject、およびApexパラメータを信頼できるソースから設定してください。

Hugoは静的サイトジェネレーターです。バージョン0.162.0以前のHugoは、いくつかのマークアップ形式のコンテンツファイルを受け入れていました。text/htmlメディアタイプにマッピングされたファイル（通常は/content配下の.htmlファイル、またはcontent.mediaType = "text/html"に設定されたコンテンツアダプターによって生成されたページ）は、その本文がレンダリングされたページにそのまま出力されていました。信頼できないソースからHTMLコンテンツを取り込むサイトでは、保存済みクロスサイトスクリプティング（XSS）が発生する可能性がありました。この脆弱性はバージョン0.162.0で修正されています。

Hugoは静的サイトジェネレーターです。バージョン0.91.0から0.162.0までの間、resources.GetRemoteは呼び出されたURLに対してsecurity.http.urlsを適用していましたが、HTTPの3xxリダイレクトでの中間URLの再検証を行っていませんでした。そのため、許可されたサーバー（またはそのDNSやレスポンスを制御する攻撃者）がリクエストをポリシーで禁止されているはずのホストにリダイレクトでき、Hugoはそのリダイレクト先のターゲットからデータを取得してしまいました。同様のバイパスにより、オペレーターが設定したホスト制限も解除されてしまいました。この脆弱性はバージョン0.162.0で修正されています。

TraefikはHTTPリバースプロキシおよびロードバランサーです。v2.11.51、v3.6.22、およびv3.7.6より前のバージョンでは、TraefikのForwardAuthミドルウェアは、trustForwardHeaderがfalseに設定されている場合でも、認証サービスに送信されるX-Forwarded-Portヘッダーを、サニタイズされた転送リクエストではなく元の受信リクエストから派生させていました。その結果、未認証のリモート攻撃者が平文のHTTP接続上でX-Forwarded-Proto: httpsヘッダーを注入し、TraefikにX-Forwarded-Port: 443を認証サービスに転送させることで、ポートベースの認可チェックを回避することが可能となっていました。この問題はv2.11.51、v3.6.22、およびv3.7.6で修正されています。

vLLMはLLMの推論とサービス提供のためのライブラリです。バージョン0.12.0から0.24.0未満の間に、純粋なプロンプトを送信し、M-RoPEを使用するモデルで/v1/completionsリクエストにペイロードを埋め込むと、EngineCoreがアサーションに失敗して致命的なクラッシュを引き起こし、サーバーアプリケーション全体がシャットダウンします。/v1/completionsリクエストを実行する権限を持つ任意のリモートユーザーがこのリクエストを行い、クラッシュを誘発することが可能です。この問題はバージョン0.24.0で修正されています。

vLLMは大規模言語モデルの推論およびサービングエンジンです。バージョン0.22.0から0.23.0において、/v1/audio/transcriptionsおよび/v1/audio/translationsルートはアップロードされた音声ファイルを完全にメモリに展開するためにrequest.file.read()を呼び出しますが、その後の音声からテキストへの前処理段階で、ドキュメントに記載されたVLLM_MAX_AUDIO_CLIP_FILESIZE_MB（デフォルト25MB）という圧縮アップロードサイズ制限をvLLMがチェックします。そのため、これらのルートにアクセス可能なAPI利用者はサイズ超過のマルチパートアップロードを送信でき、リクエストが大きすぎるとして拒否される前に、アップロードされたファイルサイズに比例したメモリをvLLMが割り当ててしまいます。その結果、リソース制限に応じてメモリ圧迫やプロセス終了を引き起こす可能性があります。この問題はバージョン0.24.0で修正されています。