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

n8nのバージョン2.28.0未満には、不適切な認可の脆弱性が存在し、認証済みユーザーが他のプロジェクトのフォルダにワークフローを割り当てられる状態です。攻撃者は、ワークフロー作成時に細工されたリクエストペイロードを送信することで、プロジェクトおよびフォルダの認可境界を回避でき、対象プロジェクトのフォルダ構造に論理的整合性の違反を引き起こす可能性があります。

MAX32xxx USBデバイスコントローラドライバ（drivers/usb/udc/udc_max32.c、互換性 adi_max32_usbhs）では、OUTおよびIN転送完了ハンドラ内でエンドポイントバッファをNULLチェックせずに参照していました。udc_event_xfer_out_done()は、buf = udc_buf_get(ep_cfg)の直後にnet_buf_add(buf, ep_request-＞actlen)を呼び出していますが、udc_buf_get()はエンドポイントFIFOが空の場合にNULLを返します。転送完了イベントは割り込みコンテキストからキューイングされ、ドライバスレッドによって非同期に処理されます。キューイングと処理の間に、エンドポイントFIFOはホスト制御の制御フローによって消費される可能性があります。特に、udc_setup_received()は新しいSETUPパケットが到着するたびにEP0のOUT/IN FIFOを消費し、dequeue/disable/purgeのパスでも同様に消費します。したがって、USBホストが進行中のEP0コントロール転送を新たなSETUPパケットで中止する（USBの合法的な動作）と、空のFIFOに対して古いXFER_OUT_DONEイベントが処理され、net_buf_add(NULL, ...)が呼ばれます。これはほぼNULLポインタ参照を引き起こしてデバイスをクラッシュさせる結果となります。認証は不要であり、攻撃者はデバイスに接続されているUSBホスト（物理的なバスアクセス）です。影響はサービス拒否（デバイスクラッシュ）をもたらします。この欠陥はMAX32 UDCドライバが追加され、Zephyr v4.4.0で出荷された際に導入されました。修正では、OUT完了およびIN完了ハンドラの両方でNULLバッファチェックを追加し、早期にUDC_EVT_ERROR/-ENOBUFSを返すようにしています。

ZephyrのDNSリゾルバは、dns_resolve_name_internal()（subsys/net/lib/dns/resolve.c）内でmemcmp(strrchr(query, '.'), ".local", 7)を用いてmDNS（.local）クエリを検出していますが、これは常に接尾辞ポインタから固定の7バイトを読み取ります。解析対象のホスト名の最終ラベルが7バイト未満の場合（例：.org、.com、.net、.ioで終わる名前や末尾にドットがある場合）、比較は文字列のヌル終端子の1〜2バイト先まで読み取ってしまいます。ホスト名（query）は標準のgetaddrinfo()/dns_get_addr_info()/dns_resolve_name()経路を通じて渡される呼び出し元指定の名前であり、オペレーターやリモート入力（設定のサーバ名、解析されたURL、アプリケーション向けインターフェース）によって影響を受ける可能性があります。スラックのない厳密にサイズ指定されたバッファ（例えば、k_usermode_string_alloc_copyで正確にstrlen+1バイト分コピーされたユーザースペースのgetaddrinfo呼び出し）を用いる場合、このオーバーリードは割り当て境界を越えます。その境界がマップされていない場合（ガードページ、MPU下のメモリドメイン境界、またはアドレスサニタイザ）、オーバーリードはフォルトを引き起こし、サービス拒否を招く可能性があります。読み取られたオーバーリードのバイトは返されないため、情報漏洩は発生しません。この脆弱性はCONFIG_MDNS_RESOLVERが有効な場合にのみコンパイルされ、v1.10.0以降に存在し、固定長memcmpをヌル終端安全なstrcmp(ptr, ".local")に置き換えることで修正されています。

悪意のあるウェブページは、同期的なJavaScriptダイアログをキューに入れることで保留中のナビゲーションを中断し、ブラウザのUIがアドレスバーに目的地のオリジンを表示し続ける一方で、攻撃者が操作するコンテンツをレンダリングし続ける可能性があります。この脆弱性はFirefox for iOS 152.3で修正されました。

PCVueプロジェクトのユーザーディレクトリに組み込みユーザーの認証情報が安全でない方法で保存されており、バージョン17.0.0より前のすべてのバージョンに影響があります。ローカルの攻撃者がユーザーの認証情報を取得する可能性があります。Active Directoryアカウントはこの脆弱性の影響を受けません。

PcVueプロジェクトの組み込みユーザーディレクトリに保存されているユーザーアカウントの設定を保護するために使用されている暗号化アルゴリズムは、バージョン17.0.0より前のすべてのバージョンにおいて、要求される保護レベルに対して十分に強力ではありません。ローカルの攻撃者は既存の設定を改ざんし、最終的にPcVueアプリケーションに特権アクセスを獲得する可能性があります。

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