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

n8nのバージョン1.123.55未満、2.25.7、2.26.2には、ワークフロー:readスコープを使用して状態変更アクションを認可する三つの変更可能な評価テスト実行エンドポイントに認可の脆弱性があります。本来はアクションに適したworkflow:executeスコープを使用すべきです。Advanced Permissions（Enterprise/Cloud）を使用し、プロジェクトとビューアロールを設定している環境では、project:viewerロールを持つ認証済みユーザーが、読み取り権限のみのワークフローに対して新しい評価テスト実行を開始したり、進行中の実行をキャンセルしたり、実行履歴を削除したりすることが可能です。

n8nのバージョン2.25.7未満および2.26.xの2.26.2未満には、Public APIの実行再試行エンドポイントに認可バイパスの脆弱性があります。このエンドポイントは、workflow:executeスコープの代わりにworkflow:readスコープを使用してアクセスを許可しています。共有ワークフローに対して読み取り専用アクセス権を持つ認証ユーザーは、Public APIを使用してそのワークフローの実行を再試行できるため、読み取りアクセスと実行アクセス間の意図された権限境界を回避できます。この脆弱性は、ワークフローが他のユーザーやプロジェクト間で共有されているインスタンスに影響を及ぼします。

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

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）の脆弱性により、権限のない攻撃者がネットワーク上でなりすましを行うことが可能です。

Microsoft Edge（Chromiumベース）におけるウェブページ生成時の入力の不適切な無害化（クロスサイトスクリプティング）が原因で、未承認の攻撃者がネットワーク上でなりすますことが可能になります。

Android版Microsoft Edgeにおいて、絶対パス・トラバーサルの脆弱性により、未承認の攻撃者がローカル情報を開示できる可能性があります。

Hugoは静的サイトジェネレーターです。バージョン0.60.0から0.163.3までの間、Hugoのデフォルトのコードブロックレンダラーは、Markdownのコードフェンスの言語またはインフォストリングをHTMLエスケープせずに、codeタグのclass="language-..."およびdata-lang="..."のラッパーに書き込んでいました。引用符やスクリプトペイロードを含むフェンスのインフォストリングが属性から脱出し、ライブのスクリプト要素を注入してしまう問題がありました。この問題は0.163.3で修正されています。

Hugoは静的サイトジェネレーターです。v0.123.0からv0.163.0までのバージョンでは、Hugoの仮想ファイルシステムはマウント内のファイルがマウントツリーの外にアクセスできないように設計されていました。しかし、リグレッションによりRootMappingFs.statRootがLstatではなく、シンボリックリンクをたどるStatを呼び出してしまいました。そのため、シンボリックリンクがマウント外を指している場合に、直接os.ReadFileで「somefile」を読み込むと、そのリンク先の内容が返されてしまいました。これにより、テーマやローカルマウント内に仕掛けられたシンボリックリンクを介して、hugoを実行するユーザーがアクセス可能な任意のファイルを読み取ることができるようになっていました。この問題はv0.163.1で修正されています。

Hugoは静的サイトジェネレーターです。v0.162.0からv0.163.0までのバージョンでは、デフォルトのsecurity.http.urlsポリシーがループバック、内部、およびクラウドメタデータのIPv4リテラルへのリクエストを拒否していましたが、拒否ルールはドット10進表記のみにマッチしていました。そのため、整数、16進数、8進数などの同じアドレスの代替IPv4エンコーディングはポリシーを通過してしまっていました。テンプレートが信頼できない場合やデータ由来のURLをresources.GetRemoteに渡し、ホストプラットフォームがcgoシステムリゾルバーを使用する場合、これらのエンコーディングはブロックされたアドレスに解決され、ビルド時にサーバー側のループバックおよび内部サービス（ホストされた環境やCIビルドのクラウドメタデータエンドポイントを含む）へのリクエストが可能になります。同じチェックがリダイレクトでも再利用されるため、このギャップは各リダイレクトホップにも適用されます。この問題はv0.163.1で修正されています。

Microsoft Edge for Android における相対パストラバーサルにより、不正な攻撃者がローカルの情報を漏洩させる可能性がある問題です。

Android版Microsoft Edgeの不適切なアクセス制御により、未承認の攻撃者がネットワーク経由でセキュリティ機能を回避できる可能性があります。

libcurlは、特定の状況下で異なる「サービス」を使用するように設定されていても、Negotiate認証された接続を要求された際に誤った接続を再利用する可能性があります。libcurlは最近使用された接続のプールを保持しており、後続のリクエストが既存の接続を再利用することでオーバーヘッドを避けられるようにしています。接続を再利用する際には一連の条件を満たす必要がありますが、コードの論理的な誤りにより、アプリケーションから発行されたリクエストが異なるサービスで認証された同じサーバーへの既存の接続を誤って再利用してしまうことがあります。

webpack-dev-serverのバージョン5.2.5およびそれ以前のバージョンは、内部開発者向けの2つのエンドポイント、/webpack-dev-server/open-editorおよび/webpack-dev-server/invalidateを公開しており、これらはGETリクエストごとに状態を変更するアクションを実行しますが、リクエストが開発サーバ自身のページから発されたものであるかどうかの検証を行いません。開発サーバが稼働中に開発者が訪れる任意のウェブサイトは、交差オリジンでこれらのエンドポイントをトリガーでき、訪問以外の操作は不要です。攻撃者は、プロジェクトルート外のファイルを含め、任意の既存のローカルファイルを開発者のエディタで開くことが可能であり、繰り返しのリクエストによってエディタのプロセスが多数起動され、再コンパイルが強制されて開発者のマシンのパフォーマンスが低下する恐れがあります。修正方法は、webpack-dev-serverをバージョン5.2.6へアップグレードすることです。回避策はありません。

webpack-dev-server バージョン 5.2.5 以前では、認証されていないピアからの不正な Host ヘッダーを含む通常の HTTP リクエスト、または不正な Origin ヘッダーを含むデフォルトの /ws エンドポイントへの WebSocket アップグレード要求を受け取ると、Node.js プロセス全体が終了します。不正な値はホスト検証パスで未捕捉の例外を引き起こし、開発サーバーがクラッシュします。影響は開発サーバーの可用性に限定されており、データの漏洩やコード実行は発生しません。対策としては、webpack-dev-server をバージョン 5.2.6 にアップグレードしてください。回避策としては、開発サーバーをローカルホスト（デフォルト）にバインドし、信頼できないネットワークに公開しないでください。

radareorgのradare2（バージョン6.1.6まで）に脆弱性が判明しました。この脆弱性はファイルlibr/core/cmd_anal.incの関数core_anal_bytesに影響を与えます。この操作により整数オーバーフローが発生します。攻撃はローカル環境で実行される必要があります。この脆弱性のエクスプロイトは公開されており、悪用される可能性があります。この問題に対処するためには、パッチを適用することを推奨します。

検証チェック中にバッファへ予期しない追加書き込みが行われたため、JPEGコマンドの解析時にメモリ破損が発生します。

ユーザースペースの変更後に古いLEDカウント値が使用されるため、フラッシュコマンド処理時にメモリ破損が発生します。

入力バッチサイズおよびバッファプレーン数が最大許容値を超えた場合に、メモリが破損します。