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

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で修正されています。

PillowはPythonの画像処理ライブラリです。バージョン12.3.0以前では、WindowsViewer.get_command()がファイルパスをエスケープせずにf文字列内に直接埋め込み、その結果をsubprocess.Popen(..., shell=True)に渡してcmd.exeのシェルコマンドを構築していました。これにより、ファイルパス内のシェルメタ文字を利用して任意のcmd.exeコマンドを注入される可能性がありました。この問題はバージョン12.3.0で修正されています。

Microsoft Edge（Chromiumベース）における不適切な同期による共有リソースの同時実行（「レースコンディション」）の脆弱性により、認可された攻撃者がローカル環境で情報を漏洩させることが可能になります。

Microsoft Edge（Chromiumベース）における機密情報の権限のない第三者への露出により、不正な攻撃者がネットワーク上でなりすましを行うことが可能となります。

Microsoft Edge（Chromiumベース）におけるサーバーサイドリクエストフォージェリ（SSRF）の脆弱性により、権限のない攻撃者がネットワーク上でなりすましを行うことが可能です。