日本公的データラボ脆弱性情報（JVN）
脆弱性情報（JVN）検索・一覧
JVN（IPA／JPCERT/CC 提供）の脆弱性情報 289,735 件を、製品・ベンダ・脆弱性タイプ（CWE）で 全文検索し、深刻度（CVSS）で絞り込めます。発表日の新しい順。各タイトルから詳細（CVSS内訳・関連脆弱性）へ。
721–760 件目を表示（ページ 19）
深刻度は CVSS（共通脆弱性評価システム・0〜10 のスコア）に基づく区分：Critical 9.0以上／High 7.0〜8.9／Medium 4.0〜6.9／Low 0.1〜3.9。
Apache CamelのAtmosphere Websocketコンポーネントには、不適切な入力検証、認可されていないアクターへの機密情報の露出、およびサーバーサイドリクエストフォージェリ（SSRF）の脆弱性が存在します。camel-atmosphere-websocketのコンシューマは、受信したWebSocketのクエリパラメータに対してHeaderFilterStrategyを適用せずにCamel Exchangeのヘッダーマップにマッピングしています（WebsocketConsumer.sendEventNotification()はWebsocketConsumer.service()で収集されたクエリ文字列マップを反復処理し、各エントリをExchangeにコピーしています）。Camelのヘッダネームスペースをブロックする仕組みがなかったため、WebSocketエンドポイントに接続するクライアントは、クエリパラメータとして単に指定するだけでCamel内部の制御ヘッダー（CamelHttpUri（Exchange.HTTP_URI）など）を設定できました。WebSocketコンシューマが下流のHTTPプロデューサに接続されているルートでは、注入されたCamelHttpUriがサーバー側のHTTPリクエストを攻撃者が選択した宛先へリダイレクトします（サーバーサイドリクエストフォージェリ。例えば内部サービスやクラウドのメタデータエンドポイント）。さらに、HTTPプロデューサは生成された（攻撃者制御下の）URI上のCamelプロパティプレースホルダーを解決するため、注入値中の環境変数参照やアプリケーションプロパティ、Vault参照なども実際の値に解決して送信され、環境変数、アプリケーション設定およびVaultシークレットが漏洩します。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へのアップグレードを推奨します。修正内容としては、HTTP/servletスタックから継承しているHeaderFilterStrategyをコンシューマに適用し、受信時にCamelヘッダネームスペースを大文字小文字を区別せずにフィルター処理することで、外部から提供されたCamel*またはcamel*ヘッダーがExchangeにコピーされないようにしています。直ちにアップグレードできない環境では、下流のプロデューサに到達する前に受信メッセージからCamel制御ヘッダーを削除する（例：ルートの先頭でremoveHeaders('Camel*')やremoveHeaders('camel*')を実行する）、WebSocketエンドポイントで認証を必須とする、不信なコンシューマから直接HTTPプロデューサに接続し、メッセージヘッダーで制御されるターゲットURIを持つ構成を避けることが推奨されます。
Apache CamelのIggyコンポーネントには、不適切な入力検証により権限のない攻撃者に機密情報が露呈し、サーバーサイドリクエストフォージェリ（SSRF）の脆弱性があります。camel-iggyコンシューマは、受信したIggyメッセージのユーザーヘッダーにHeaderFilterStrategyを適用せずにCamel Exchangeのヘッダーマップにマッピングしていました（IggyFetchRecordsはメッセージのユーザーヘッダーをそのままExchangeにコピーしていました）。Camelヘッダーの名前空間をブロックする仕組みがなかったため、Iggyの消費されるストリームやトピックにアクセス可能な攻撃者は、メッセージのユーザーヘッダーとしてCamel内部制御ヘッダー（たとえばCamelHttpUri（Exchange.HTTP_URI））を設定できました。Iggyコンシューマが下流のHTTPプロデューサーにデータを渡すルートでは、注入されたCamelHttpUriによってサーバーサイドのHTTPリクエストが攻撃者の指定した宛先（たとえば内部サービスやクラウドのメタデータエンドポイント）にリダイレクトされる（サーバーサイドリクエストフォージェリ）危険があります。さらに、HTTPプロデューサーは生成された（攻撃者により制御された）URI上のCamelプロパティプレースホルダを解決し、プレースホルダ内の環境変数参照、アプリケーションプロパティ、ボールト参照などを実際の値に解決して攻撃者に送信するため、環境変数やアプリケーションプロパティ、ボールトシークレットが漏洩します。本脆弱性はApache Camelのバージョン4.17.0から4.18.3未満および4.19.0から4.21.0未満に影響します。ユーザーには本問題を修正したバージョン4.21.0へのアップグレードを推奨します。4.18.x系の場合は4.18.3へのアップグレードを推奨します。修正により専用のIggyHeaderFilterStrategy（およびheaderFilterStrategyエンドポイントオプション）が追加され、Camelヘッダー名前空間を大文字小文字を区別せずにインバウンドマッピングでフィルタリングするようになったため、外部から供給されたCamel*またはcamel*ヘッダーはExchangeにコピーされなくなりました。直ちにアップグレードできない展開環境では、下流のプロデューサーに届く前にCamel制御ヘッダーをインバウンドメッセージから削除する（例：ルートの開始部分でremoveHeaders('Camel*')およびremoveHeaders('camel*')を実行すること）、Iggyストリーム／トピックへのパブリッシュ権限を制限すること、および信頼できないコンシューマを直接HTTPプロデューサーに橋渡ししてメッセージヘッダーでターゲットURIを操作できる状態を避けることが推奨されます。
Dell PowerProtect Data Domain のバージョン 7.7.1.0 から 8.6、および 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 に誤った認可の脆弱性があります。リモートアクセスを持つ低権限の攻撃者がこの脆弱性を悪用すると、不正アクセスが発生する恐れがあります。
Apache Camel Undertowコンポーネントにおける機密情報を含むエラーメッセージ生成の脆弱性について説明します。camel-undertowのHTTPサーバーコンシューマーは、ルート処理でエラーが発生した際にクライアントへ返す内容を制御するmuteExceptionオプションを提供しています。このオプションのデフォルト値はfalseですが、他のCamel HTTPサーバーコンポーネント（camel-http、camel-jetty、camel-servlet、camel-platform-http）はtrueをデフォルトとしています。muteException=falseの場合、ルート処理中に例外が発生すると、コンシューマーはHTTPレスポンスボディに空文字を返すのではなく、text/plain形式で完全なThrowableスタックトレースを書き込みます。認証されていないクライアントがエンドポイントに到達し、処理エラー（例えば不正なリクエストボディや無効なパラメータの送信、あるいはルート内部での失敗を引き起こすもの）を発生させると、完全なJavaスタックトレースが返されます。そのようなスタックトレースには、例外メッセージに埋め込まれた資格情報、内部ホスト名やIPアドレス、ファイルシステムパス、依存関係やバージョン情報、データベース名やクラス名、アプリケーションの内部構造などの機密情報が含まれることがあり、攻撃者はこれを悪用してさらなる攻撃を計画する可能性があります。さらに、Rest DSLコンシューマーではmuteExceptionオプションが全く尊重されず、RestUndertowHttpBindingがハードコーディングでfalseに設定されているため、muteException=trueの設定があってもスタックトレースが返されていました。本問題は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-undertowコンシューマーでmuteException=trueを明示的に設定してください（例：undertow:http://0.0.0.0:8080/api?muteException=true、またはグローバル設定としてcamel.component.undertow.mute-exception=trueプロパティ）。これにより、処理エラー時にスタックトレースをクライアントへ返さないようにできます。ただし、影響を受けるリリースでは、この回避策はRest DSLコンシューマーには適用されず、修正が適用されるまでバインディングがmuteExceptionオプションを無視し続ける点にご注意ください。
n8n 2.8.0未満のバージョンには、認証されたユーザーがOAuth2クレデンシャルの認可URLフィールドに悪意のあるJavaScriptのURLを注入できる資格情報管理フローにクロスサイトスクリプティングの脆弱性が存在します。攻撃者は悪意のあるクレデンシャルを作成し、被害者をOAuth認可ボタンのクリックへと誘導することで、被害者の権限でブラウザセッション内において任意のスクリプトを実行させることができます。
n8nのバージョン1.123.18および2.6.2以前では、ZendeskTriggerノードのZendeskウェブフックにおけるHMAC-SHA256署名の検証が失敗します。ウェブフックのURLを知っている攻撃者は、署名されていないPOSTリクエストを送信し、任意の悪意あるデータを使ってワークフローをトリガーすることが可能です。
n8nのバージョン1.123.55未満、2.25.7、2.26.2には、ワークフロー:readスコープを使用して状態変更アクションを認可する三つの変更可能な評価テスト実行エンドポイントに認可の脆弱性があります。本来はアクションに適したworkflow:executeスコープを使用すべきです。Advanced Permissions（Enterprise/Cloud）を使用し、プロジェクトとビューアロールを設定している環境では、project:viewerロールを持つ認証済みユーザーが、読み取り権限のみのワークフローに対して新しい評価テスト実行を開始したり、進行中の実行をキャンセルしたり、実行履歴を削除したりすることが可能です。
n8nのバージョン1.123.55未満、2.25.7、および2.26.2には、POST /workflows/{workflowId}/test-runs/newエンドポイントに認可バイパスの脆弱性が存在します。このエンドポイントは、workflow:executeではなくworkflow:readスコープを使用してアクセスの認可を行っています。読み取り専用アクセス権を持つ認証済みユーザーが、この脆弱性を悪用することで、実際の評価テスト実行をトリガーできます。その結果、内部ワークフロールンナーを介してワークフローが実行され、意図しない外部APIコールやデータの変更、さらに接続された下流システムにおけるその他の副作用を引き起こす可能性があります。この問題は主に、RBACプロジェクトロールがworkflow:executeを付与せずにworkflow:readのみを付与したEvaluations機能を使用しているインスタンスに影響します。
n8nのバージョン2.25.7未満および2.26.xの2.26.2未満には、Public APIの実行再試行エンドポイントに認可バイパスの脆弱性があります。このエンドポイントは、workflow:executeスコープの代わりにworkflow:readスコープを使用してアクセスを許可しています。共有ワークフローに対して読み取り専用アクセス権を持つ認証ユーザーは、Public APIを使用してそのワークフローの実行を再試行できるため、読み取りアクセスと実行アクセス間の意図された権限境界を回避できます。この脆弱性は、ワークフローが他のユーザーやプロジェクト間で共有されているインスタンスに影響を及ぼします。
n8nのバージョン2.28.0未満には、不適切な認可の脆弱性が存在し、認証済みユーザーが他のプロジェクトのフォルダにワークフローを割り当てられる状態です。攻撃者は、ワークフロー作成時に細工されたリクエストペイロードを送信することで、プロジェクトおよびフォルダの認可境界を回避でき、対象プロジェクトのフォルダ構造に論理的整合性の違反を引き起こす可能性があります。
n8nのバージョン1.123.61より前、2.xの2.27.4より前、および2.28.xの2.28.1より前には、レガシーMySQL v1ノードのexecuteQuery操作にSQLインジェクションの脆弱性が存在します。この操作は、評価済みの{{ ... }}式の値をパラメータ化せずにそのまま生のSQL文字列に置換します。ワークフローがこの操作を式由来の値で使用し、外部から到達可能なトリガー（Webhookノードなど）に接続している場合、攻撃者が制御する入力がこれらの式に到達してSQLインジェクションを引き起こす可能性があります。これにより、設定されたMySQL認証情報の権限で任意のSQLを実行できるようになります。パラメータ化クエリを使用するMySQL v2ノードは影響を受けません。
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")に置き換えることで修正されています。
nltk/nltk バージョン 3.9.3 以前では、5つの Stanford インターフェイスクラス（StanfordPOSTagger、StanfordNERTagger、StanfordParser、StanfordDependencyParser、および StanfordNeuralDependencyParser）が信頼されていない JAR のコード実行に対して脆弱です。これらのクラスはユーザーが制御可能な JAR パスを受け入れ、`java()` 関数を通じて実行しますが、この関数は整合性検証を行わずに `subprocess.Popen()` を呼び出します。この脆弱性は、SHA256検証の追加によって StanfordSegmenter で修正された CVE-2026-0848 と同一のものです。しかし、この修正はこれらの追加クラスには適用されておらず、信頼されていない JAR ファイルを読み込む際に任意コードが実行されるリスクが残っています。
悪意のあるウェブページは、同期的なJavaScriptダイアログをキューに入れることで保留中のナビゲーションを中断し、ブラウザのUIがアドレスバーに目的地のオリジンを表示し続ける一方で、攻撃者が操作するコンテンツをレンダリングし続ける可能性があります。この脆弱性はFirefox for iOS 152.3で修正されました。
Devolutions Server 2026.2.9.0において、必須多要素認証ポリシーが不適切に適用される問題により、有効なユーザー資格情報を持つ攻撃者がMFA（多要素認証）必須ポリシーを回避し、多要素認証を完了せずに認証を行うことが可能となります。この問題は、DVLSが無効なデフォルトMFA値に遭遇した場合に発生します。
PCVueプロジェクトのユーザーディレクトリに組み込みユーザーの認証情報が安全でない方法で保存されており、バージョン17.0.0より前のすべてのバージョンに影響があります。ローカルの攻撃者がユーザーの認証情報を取得する可能性があります。Active Directoryアカウントはこの脆弱性の影響を受けません。
PcVueプロジェクトの組み込みユーザーディレクトリに保存されているユーザーアカウントの設定を保護するために使用されている暗号化アルゴリズムは、バージョン17.0.0より前のすべてのバージョンにおいて、要求される保護レベルに対して十分に強力ではありません。ローカルの攻撃者は既存の設定を改ざんし、最終的にPcVueアプリケーションに特権アクセスを獲得する可能性があります。
`BaseSerialization.deserialize()` のバグにより、Scheduler や APIサーバーがシリアライズされたDAGを読み込む際に、攻撃者が制御するクラスパスを制限なく `import_string()` できてしまいました。これにより、DAG作成者が悪意のあるトリガーをDAGに埋め込み、APIサーバーや Schedulerプロセス上でリモートコード実行が可能となり、DAG作成者のコードはこれらのプロセス内で決して実行されてはならないという Airflow のセキュリティ境界を越えてしまいました。ユーザーには `apache-airflow` 3.3.0 以降へのアップグレードを推奨します。多層防御策として、DAG作成者の信頼度が限定される環境では、`[core] allowed_deserialization_classes` の設定を狭い許可リストに制限することが推奨されます。
Apache Camel の Docling コンポーネントにおいて、コマンド内の引数区切り文字の不適切な無害化（「引数インジェクション」）に関する脆弱性があります。camel-docling コンポーネントは、DoclingProducer 内で引数リストを組み立て、java.lang.ProcessBuilder を介して外部の `docling` コマンドラインツールを呼び出します。`CamelDoclingCustomArguments` エクスチェンジヘッダー（List＜String＞）を通じて渡されるカスタム CLI 引数は、この引数リストに十分な検証をせずに追加されていました。元の実装は、禁止フラグのデナイリストに依存し、リテラルの `../` シーケンスを含むパス値のみを拒否していました。その結果、外部から影響を受けたデータを `CamelDoclingCustomArguments` ヘッダー（または呼び出しに使用されるパスを含むヘッダー）に渡す Camel ルートは、プロデューサーがサブプロセスに未認識または意図しない `docling` CLI フラグを渡したり、リテラル `../` チェックで検出されない走査シーケンスにより意図しないディレクトリの外を指すパスのような引数値を供給したりする可能性があります。Camel 自体がこれらの値から `docling` 呼び出しを構築するため、コンポーネントがそれらを制限する責任があります。弱い検証のために CLI 引数インジェクションおよび外部ツールに渡される引数でのディレクトリトラバーサルが可能でした。呼び出しは ProcessBuilder のリスト形式を使用しているため、シェルは引数値を解釈せず、シェルのメタ文字による OS コマンドインジェクションは不可能です。修正により追加されたメタ文字拒否は多層防御の一環となっています。本問題は Apache Camel のバージョン 4.15.0 から 4.18.3 未満に影響します。ユーザーには、CAMEL-23212 の修正を含むリリースへのアップグレードを推奨します。メインラインでは Apache Camel 4.19.0 以降（4.20.0 などの後続リリース）に修正が含まれており、4.18.x LTS 系列のユーザーは 4.18.3 へのアップグレードが必要です。修正はデナイリストを、認識済み `docling` CLI フラグの厳格なホワイトリストに置き換え、未認識のフラグや出力ディレクトリ関連のプロデューサー管理フラグを拒否します。また、防御的に引数値のシェルメタ文字を拒否し、Path.normalize() でパスらしい値を正規化してから検証し、リテラルの `../` チェックをすり抜ける走査シーケンスを検出します。多層防御のために、ルート作成者は信頼できないメッセージ内容を `CamelDoclingCustomArguments` ヘッダーおよびパスを含むヘッダーにマッピングすることを避け、信頼できないプロデューサーから届いたメッセージから Camel 内部ヘッダーを除去すべきです。
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 に格納型クロスサイトスクリプティングの脆弱性が存在します。認証されていない攻撃者がリモートアクセスを介してこの脆弱性を悪用する可能性があります。悪用された場合、情報漏洩やセッションの乗っ取り、またはクライアントサイドリクエストフォージェリが発生する恐れがあります。
Apache OpenNLP の SvmDoccatModel における信頼されていない Java デシリアライズの脆弱性影響を受けるバージョン: 3.0.0-M4 未満（libsvm ドキュメントカテゴリモジュール；OPENNLP-1808 で導入され、3.x 系列にのみ存在します）説明: SvmDoccatModel.deserialize(InputStream) は攻撃者が制御する java.io.ObjectInputStream を読み込み、ObjectInputFilter が設定されていない状態で readObject() を呼び出します。ObjectInputStream はストリーム内で参照されるすべてのクラスのオブジェクトを、SvmDoccatModel にキャストする前に具現化します。そのため、readObject() の後のキャストは、外部のオブジェクトグラフが完全にデシリアライズされた後に実行されます。もし利用者のクラスパスに Java のデシリアライズ用ガジェットチェーンが存在する場合、deserialize() に渡された細工されたペイロードによって JVM 上で任意のコードが実行される恐れがあります。Apache OpenNLP 自体は既知のガジェットチェーンを含んでいませんが、脆弱なトランジティブ依存関係と共に libsvm モジュールを組み込んだ下流のアプリケーションには現実的なリスクがあります。このメソッドは public かつ static であるため、呼び出し元は直接信頼されていないストリームを渡すことが可能です。実質的な影響としては、信頼されていないまたは半信頼の出所から読み込まれた SvmDoccatModel インスタンスに対してリモートコード実行が可能になることです。緩和策: 3.x 系列の利用者は 3.0.0-M4 へアップグレードしてください。すぐにアップグレードできない場合は、すべてのシリアライズされた SvmDoccatModel ストリームを信頼されていない入力として扱い、その出所が検証されていない限り、エンドユーザーから提供されたストリームや第三者のソースから取得したストリームに対して SvmDoccatModel.deserialize() を呼び出すことを避けてください。
CoderはTerraformを介して組織がリモート開発環境をプロビジョニングできるようにします。バージョン2.29.7および2.30.2より前のバージョンでは、`dotfiles`レジストリモジュールが無検証のユーザー入力をシェルコマンドに渡しており、プロビジョニングされたワークスペース内で任意のコードを実行できました。細工された`dotfiles_uri`の値（例えば、`$(...)`のようなシェルコマンド置換を含むもの）を提供した任意のユーザーは、自身のワークスペースでコマンドを実行することが可能でした。Create Workspaceページの`mode=auto`ディープリンクは、これをワンクリック攻撃に拡大させました。攻撃者は`param.dotfiles_uri`を事前に入力したURLを作成し、ユーザーの明示的な確認なしに、攻撃者が制御する値でワークスペースを静かにプロビジョニングできる状態でした。バージョン2.29.7および2.30.2では、dotfilesモジュールに特別な文字を含むURIやユーザー名を拒否する入力検証が追加され、不安全な`eval`や`sh -c`の使用は削除されました。これにより、コマンドインジェクションは発生源で除去されました。
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で制限してください。
2026年07月07日（現地時間）、米国CISAがCISA ICS Advisory / ICS Medical Advisoryを公表しました。 新規：7件 ・ICSA-26-188-01: Hydro-Québec Le Circuit Electrique charging station backend ・ICSA-26-188-02: Hitachi Energy PROMOD V ・ICSA-26-188-03: Hitachi Energy e-mesh EMS ・ICSA-26-188-04: Siemens Mendix Studio Pro ・ICSA-26-188-05: Siemens SINEC OS ・ICSA-26-188-06: Labcenter Proteus 9 ・ICSA-26-188-07: Digi International PortServer TS, Digi One SP IA
Apache Camelには信頼されていないデータの逆シリアル化に関する脆弱性があります。いくつかのApache Camelコンポーネントに標準搭載されている防御層としての逆シリアル化フィルタリング用ObjectInputFilterのデフォルトパターン（'java.**;javax.**;org.apache.camel.**;!*'、またはaggregation-repositoryコンポーネントでのjavax.**を含まないバリアント）は、再帰的な'java.**'のグロブを使用しており、hashCode/equals/readObjectメソッドがネットワークI/Oを行うクラス、特にjava.net.URLおよびjava.net.InetAddressを許可しています。攻撃者が影響を受けるCamelコンシューマにJavaシリアライズペイロードを届けられる場合、java.net.URLキーを含むHashMap（またはその要素のhashCodeを呼ぶコレクション）の逆シリアル化が行われると、JVMは逆シリアル化の副作用として攻撃者指定のホストにDNSクエリを発行します。クラスレベルのフィルタチェックは、結果として生成されるオブジェクトのクラス(HashMap)が許可リストに含まれているため通過します。このDNSクエリは攻撃者が制御するDNSサーバーで観測可能であり、アウトオブバンドのサイドチャネルを提供します。camel-jmsファミリーでの暴露度が最も高く、JmsBinding.extractBodyFromJmsがmapJmsMessage=true（デフォルト）の場合にObjectMessage.getObject()を無条件に呼び出すためです。影響を受けるコンポーネントにはcamel-jms、camel-sjms、camel-amqp、camel-mina、camel-netty、camel-netty-http、camel-vertx-http、camel-infinispan、およびaggregation repositoryコンポーネントのcamel-leveldb、camel-cassandraql、camel-consul、camel-sql（JDBC aggregation repository）が含まれます。この問題はApache Camelのバージョン4.14.0から4.14.8未満、4.15.0から4.18.3未満、4.19.0から4.21.0未満に影響します。ユーザーには、対応版であるCAMEL-23372修正を含む4.21.xラインの4.21.0、4.18.xラインの4.18.3、および4.14.xラインの4.14.8へのアップグレードを推奨します。すぐにアップグレードできない環境では、主要な緩和策としてJMSプロバイダ側の許可リスト（Apache ActiveMQ Artemisの'deserializationAllowList' / 'deserializationDenyList'、Apache ActiveMQ Classicの'org.apache.activemq.SERIALIZABLE_PACKAGES'）を構成し、さらにエンドポイントレベルの'deserializationFilter'オプションまたはJVM全体の'-Djdk.serialFilter'システムプロパティを用いて、明示的な拒否を含む'!java.net.**;java.**;javax.**;org.apache.camel.**;!*'（aggregation-repositoryコンポーネント用はjavax.**を含まない'!java.net.**;java.**;org.apache.camel.**;!*'）に上書きすることを推奨します。
OP-TEEは、ArmのCortex-Aコア上で動作する非セキュアなLinuxカーネルの補完として設計された信頼実行環境（TEE）であり、TrustZone技術を利用しています。バージョン3.3.0から4.11.0未満の間、OP-TEEの共有メモリのクリーンアップロジックにリソースリークが存在していました。これは、`core/tee/entry_std.c`内の関数`cleanup_shm_refs()`が、パラメータ属性に必要なビットマスク（`OPTEE_MSG_ATTR_TYPE_MASK`）を適用しなかったためです。通常世界から呼び出される非連続メモリパラメータを処理する際に、システムは内部のswitch文で属性タイプの一致に失敗し、必要なmobj_put()呼び出しをスキップしてしまいます。これにより、`mobj_reg_shm`オブジェクトの参照リークが持続的に発生し、内部リスト上で参照カウントがぶら下がった状態になってしまいます。この問題は、非FF-A構成で非連続かつ非セキュアな共有メモリをサポートする環境に影響を及ぼします。時間の経過とともに、これらの累積したリークがセキュアワールドのヒープを徐々に消費し、信頼済みアプリケーションの処理能力を低下させ、最終的には回復のために再起動が必要となります。バージョン4.11.0にて修正パッチが含まれており、既知の回避策は存在しません。
Apache CamelのHazelcastコンポーネントに存在する信頼されていないデータの逆シリアライズ脆弱性について説明します。camel-hazelcastコンポーネントは、Javaの逆シリアライズフィルターを適用しないデフォルト設定でHazelcastインスタンスを作成・管理しています。Camelが自身でHazelcastの設定を構築する場合、つまりユーザーが提供するHazelcastInstance、hazelcastConfigUri、または参照されるConfig beanが存在しない場合には、HazelcastのJavaSerializationFilterConfigもCamel側のObjectInputFilterも設定されません。そのため、Hazelcastクラスタープロトコルを介して受信したオブジェクトは、Camelで処理される前にHazelcastのシリアライズレイヤー（ObjectInputStream.readObject）内で逆シリアライズされます。Hazelcastクラスタに参加またはアクセス可能な攻撃者は、細工されたシリアライズ済みJavaオブジェクトを公開することが可能であり、それがすべてのCamelノード上で逆シリアライズされることでリモートコード実行に至る可能性があります。この脆弱性はデフォルトで存在し、特別なエンドポイント設定を必要としません。hazelcast-topic、hazelcast-queue、hazelcast-seda、hazelcast-map、hazelcast-multimap、hazelcast-replicatedmap、hazelcast-list、hazelcast-setを使用する任意のルート、およびHazelcastAggregationRepositoryとHazelcastIdempotentRepositoryは、Camelのデフォルト設定によって管理されるインスタンスが作成される場合に影響を受けます。本問題は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が自身のデフォルト設定から作成するインスタンスに対してデフォルトのHazelcast JavaSerializationFilterConfigを適用し、クラス名プレフィックス「java.」、「javax.」、「org.apache.camel.」をホワイトリストに入れ、「java.net.」をブラックリストに設定しています。ただし、ユーザーが提供するConfigまたはHazelcastInstanceには影響を与えません。すぐにアップグレードできない環境では、Hazelcastインスタンス上で逆シリアライズフィルター（Hazelcast JavaSerializationFilterConfig、もしくはJVM全体のシステムプロパティ -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!*）を設定し、さらにHazelcastクラスタ認証およびTLSを有効化して、クラスタへアクセス可能なユーザーを制限してください。
Apache CamelおよびApache Camel JMSコンポーネントにおける信頼されていないデータのデシリアライズ脆弱性です。camel-jmsのJmsBinding.extractBodyFromJms()および同等のcamel-sjms内のJmsBindingは、mapJmsMessageオプションが有効（デフォルト）かつCamelがJMSコンシューマとして動作している場合に、受信したJMS ObjectMessageのペイロードをjakarta.jms.ObjectMessage.getObject()を通じてデシリアライズします。CVE-2026-40860の強化により、デシリアライズ後にクラスチェックが追加され、デフォルトの許可リスト java.**;javax.**;org.apache.camel.**;!* に含まれないクラスは拒否されます。しかし、org.apache.camel.support.DefaultExchangeHolder自体は許可リストに含まれるorg.apache.camel.**名前空間に存在するため、トップレベルのオブジェクトがDefaultExchangeHolderであるObjectMessageはこのチェックを通過します。受信側はtransferExchangeオプションの有効化を要求せずにDefaultExchangeHolder.unmarshal()を呼び出すため（非対称な信頼境界となっており、送信側はObjectMessageとtransferExchange処理を制御しているものの受信側はしていません）、保持者のすべての非nullフィールドをExchangeに書き込みます：メッセージボディ、INおよびOUTヘッダー、Exchangeのプロパティ、変数、Exchange ID、および例外です。攻撃者は影響を受けるCamelアプリケーションで消費されるキューやトピックにObjectMessageを送信できれば、任意のExchange状態をjava.langおよびjava.utilの普遍的に信頼された型のみを用いて（デシリアライズのガジェットチェーン不要で）注入し、ルーティング・ヘッダー、Exchangeプロパティ、エラー処理を操作できます。同様の取り扱いはcamel-sjms、camel-sjms2、およびJmsComponentとJmsBindingに基づくJMS系コンポーネント（camel-amqp、camel-activemq、camel-activemq6）にも適用されます。これはCVE-2026-40860の修正の回避であり、その欠陥ではありません。影響範囲はApache Camelのバージョン3.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-jms、camel-sjms、およびJMS系コンポーネントではJMS ObjectMessageの取り扱いはデフォルトで無効化されます（objectMessageEnabledという新しいオプションがコンポーネントおよびエンドポイントレベルでデフォルトfalseです）。したがって、DefaultExchangeHolderペイロードを含む受信ObjectMessageは、明示的にオプションを有効にしない限りデシリアライズされません。objectMessageEnabled=trueは、消費しているJMSデスティネーションが信頼されたプロデューサーのみから供給されている場合にのみ設定してください。すぐにアップグレードできない場合は、JMSブローカーの認可を用いてCamelが消費するキューやトピックへのパブリッシュアクセスを信頼できるプロデューサーに制限し、ObjectMessageボディをマッピングするJMSコンシューマを信頼されていないネットワークに公開しないことを推奨します。なお、JMSプロバイダーのデシリアライズ許可リストでは本特定の回避を軽減できません。なぜなら、悪意あるペイロードは普遍的に信頼されたクラスのみを使用しているためです。
Apache Camel PQCコンポーネントにおける信頼されていないデータのデシリアライズ脆弱性について説明します。camel-pqcコンポーネントは、プラガブルなKeyLifecycleManagerの実装を通じてポスト量子鍵メタデータ（KeyMetadata）を永続化しています。AwsSecretsManagerKeyLifecycleManager.deserializeMetadata()は、設定されたAWS Secrets ManagerのシークレットからそのメタデータをBase64デコードし、保存された値をjava.io.ObjectInputStream.readObject()でデシリアライズします。しかし、ObjectInputFilterやクラスの許可リストが存在せず、readObject()が返る前にKeyMetadataへのキャストは行われません。したがって、作成されたオブジェクトのreadObject()の副作用は型チェックより先に実行されます。このメタデータを保持するAWS Secrets Managerシークレットへの書き込み権限（対象シークレットに対するsecretsmanager:PutSecretValue）を持つ主体は、通常のキーライフサイクル操作中にデシリアライズされる細工されたシリアライズオブジェクトを保存でき、その結果、キー管理を行うアプリケーションのコンテキストでコードが実行される可能性があります。これは、CVE-2026-46590と同じ根本的欠陥に起因し、同じコードパスで発生しており、同じ修正によって対処されています。本CVEはHashiCorp Vaultおよびファイルベースの関連マネージャーも対象としており、両者ともCVE-2026-40048（CAMEL-23200）の不完全な修正に対する追補となっています。この問題はApache Camelのバージョン4.18.0以降4.18.3未満、4.19.0以降4.21.0未満に影響を与えます。ユーザーには、本問題を修正したバージョン4.21.0へのアップグレードを推奨します。また、4.18.xのLTSリリースシリーズを利用している場合は、4.18.3へのアップグレードが推奨されます。直ちにアップグレードできない環境では、camel-pqcの鍵メタデータを保持するAWS Secrets Managerのシークレットへの書き込みアクセスを、アプリケーション自身のIDのみがsecretsmanager:PutSecretValue権限を持つように制限し（最小権限のIAM設定を適用し）、PQC鍵素材を信頼度の低い主体が書き込み可能なデータから分離したシークレットに保管することが推奨されます。
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 Cometdコンポーネントにおける不適切な入力検証の脆弱性について説明します。camel-cometdコンポーネントは、Bayeux（CometD）から受信したメッセージヘッダーにHeaderFilterStrategyを適用せずにCamel Exchangeにマッピングします。CometdBinding.populateExchangeFromMessageは、CometDクライアントから提供されたext.CamelHeadersマップ全体を直接Camelメッセージ（message.setHeaders）にコピーするため、CamelHttpUri、CamelFileName、CamelJmsDestinationNameのようなCamel内部制御ヘッダーを含むあらゆるヘッダー名が変更されることなく受け入れられます。デフォルトでCometdComponentはBayeux SecurityPolicyをインストールしないため、Bayeuxハンドシェイクを完了できるクライアントは認証なしでこのメッセージを公開できます。その結果、攻撃者はルート内の下流プロデューサの動作に影響を与える任意のCamel制御ヘッダーを注入可能です（例：HTTPプロデューサのリダイレクト、ファイル名の変更、JMS宛先の上書き）。注入されたヘッダーは内部のdirect、seda、vmホップ間でも持続します。具体的な下流への影響はルートで使用されるプロデューサによって異なります。この問題は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-cometdバインディングにHeaderFilterStrategyを実装し（コード上の長期間のTODO）、インバウンドマッピングで大文字小文字を区別せずCamelヘッダー名前空間をフィルタリングすることで、クライアントから提供されるCamel* / camel*ヘッダーがExchangeにコピーされなくなるようにしています。即時アップグレードできない環境では、ルート開始時にremoveHeaders('Camel*')およびremoveHeaders('camel*')などを使用して、下流プロデューサに届く前に受信したCometDメッセージからCamel制御ヘッダーを除去し、さらにCometdComponentに明示的なBayeux SecurityPolicyを設定して認証済みクライアントのみがメッセージを公開できるようにしてください。
Apache CamelのKeycloakコンポーネントにおけるセッション有効期限が不十分である脆弱性です。camel-keycloakのセキュリティヘルパーであるKeycloakSecurityHelper.parseAndVerifyAccessTokenは、withChecks(...)メソッドを用いてKeycloakのTokenVerifierを構築しますが、設定されているのはsubject-existsチェックとrealm-URL（発行者）チェックのみです。TokenVerifier.withChecks(...)は初期状態で空のチェックリストにチェックを追加していく方式であり、withDefaultChecks()が呼ばれない限り上流のデフォルトチェックは適用されません。そのため、トークンのexp（有効期限）およびnbf（使用開始前）クレームを検証する組み込みのIS_ACTIVE述語が適用されません。結果として、このヘルパーはトークンの署名、subjectおよびissuerは検証しますが、トークンの有効期間を制御せず、有効期限切れまたはまだ有効でないアクセストークンを有効と認めてしまいます。したがって、このヘルパーを使用してインバウンドリクエストを認証するルートは、本来の有効期間外のアクセストークンを受け入れてしまう可能性があります。影響を受けるApache Camelのバージョンは4.18.0から4.18.3未満、4.19.0から4.21.0未満です。ユーザーにはこの問題を修正した4.21.0へのアップグレードを推奨します。4.18.x系のユーザーには4.18.3へのアップグレードを推奨します。修正により、KeycloakSecurityHelper.parseAndVerifyAccessTokenはTokenVerifier.IS_ACTIVEチェックを含むようになり、有効期限切れまたはまだ有効でないアクセストークンを拒否し、ヘルパーの挙動がKeycloakのデフォルトチェックセットと整合します。即時アップグレードが困難な環境では、ヘルパーの外側でトークンの有効期限を強制してください。例えば、ルート上でアクセストークンのexp/nbfクレームを検証し、Keycloakのアクセストークン有効期間を短く設定し、上流のゲートウェイやリソースサーバーでもトークンの有効期間検証を行うことを推奨します。
Apache Camel AWS2-SQS コンポーネントにおける不適切な入力検証の脆弱性について説明します。camel-aws2-sqs コンポーネントは、コンポーネント固有の HeaderFilterStrategy を通じてインバウンドメッセージ属性を Camel Exchange にマップしています。Sqs2HeaderFilterStrategy はアウトバウンドフィルター（setOutFilterPattern、Camel*、breadcrumbId、および org.apache.camel.* ヘッダーがブローカーへ書き込まれるのをブロックするもの）のみを設定しており、インバウンドフィルターは設定していませんでした。その結果、Sqs2Consumer が各 SQS の MessageAttribute を HeaderFilterStrategy.applyFilterToExternalHeaders 経由で Exchange にコピーする際に、DefaultHeaderFilterStrategy はインバウンドルールを適用せず、すべてのヘッダー名をフィルター対象外とみなし、CamelHttpUri、CamelFileName、CamelSqlQuery などの Camel 内部制御ヘッダーを変更せずに Camel メッセージにコピーしてしまいます。したがって、消費される SQS キューへメッセージを送信できる権限を持つ主体（例えばクロスアカウントの送信者や、sqs:SendMessage 権限を持つより権限の低い同アカウント内のコンポーネント）は、ルート内の下流のプロデューサの挙動に影響を与える任意の Camel 制御ヘッダーを設定できる可能性があります（例：HTTP プロデューサのリダイレクト、ファイル名の変更、クエリの上書き）。注入されたヘッダーは、内部の direct、seda、vm ホップ間でも持続します。具体的な下流への影響はルートが使用するプロデューサに依存します。本問題は 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 ヘッダー名前空間をフィルタリングするインバウンド HeaderFilterStrategy ルールを Sqs2HeaderFilterStrategy に追加し、送信者が指定した Camel* および camel* ヘッダーが Exchange にコピーされないようにしたものです。すぐにアップグレードできない環境では、ルートの開始時に removeHeaders('Camel*') と removeHeaders('camel*') を使用してインバウンドメッセージから Camel 制御ヘッダーを除去し、さらに消費される SQS キューへ送信可能な主体を最小権限の sqs:SendMessage 権限で制限することを推奨します。
Apache Camel NATSコンポーネントにおける不適切な入力検証の脆弱性です。camel-natsコンポーネントは、受信したNATSメッセージのヘッダーをCamel Exchangeにマッピングしますが、headerFilterStrategyがinboundルールとして設定されていない場合、新規のDefaultHeaderFilterStrategy()がデフォルトで設定されていました（NatsConfiguration）。inFilter、inFilterPattern、inFilterStartsWithが設定されていない場合、DefaultHeaderFilterStrategy.applyFilterToExternalHeadersはすべてのヘッダー名に対してフィルタリングを行わないため、NatsConsumerはCamelHttpUri、CamelFileName、CamelSqlQueryなどのCamel内部制御ヘッダーを含むすべてのNATSメッセージヘッダーを変更せずにCamelメッセージへコピーしてしまいます。したがって、対象のNATSサブジェクトに対して公開可能なクライアントは、ルート内の下流のプロデューサの動作に影響を与える任意のCamel制御ヘッダーを注入できます（例：HTTPプロデューサのリダイレクト、ファイル名の変更、クエリの上書きなど）。注入されたヘッダーは、内部のdirect、seda、vm経由でも引き継がれます。具体的な影響は、ルートで使用されるプロデューサによって異なります。NATSメッセージヘッダーはNATS 2.2以降が必要であり、NATSサーバーが認証なしで構成された場合（NATSサーバーのデフォルト設定）、認証情報なしで問題に到達可能です。この問題は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-natsのデフォルトを専用のNatsHeaderFilterStrategyに変更し、受信マッピング時にCamelヘッダー名前空間を大文字・小文字を区別せずにフィルタリングすることで、クライアントから提供されたCamel* / camel*ヘッダーがExchangeにコピーされなくなります。すぐにアップグレードできない環境では、受信したNATSメッセージからCamel制御ヘッダーを下流のプロデューサに到達する前に削除すること（例：ルート開始時にremoveHeaders('Camel*')およびremoveHeaders('camel*')を実行）およびNATSサーバーの認証を有効化して信頼されたクライアントのみが対象サブジェクトに公開できるようにすることを推奨します。
Apache CamelのSolrコンポーネントにおいて、下流コンポーネントで利用される出力中の特殊要素の不適切な無害化（「インジェクション」）、不適切な入力検証、サーバーサイドリクエストフォージェリ（SSRF）脆弱性が存在します。camel-solrプロデューサは、SolrParam.プレフィックスで始まるExchangeメッセージヘッダーをSolrリクエストのパラメータに、SolrField.プレフィックスで始まるヘッダーをインデックスされたSolrドキュメントのフィールドにコピーします。これらのプレフィックス定数（SolrConstants.HEADER_PARAM_PREFIX / HEADER_FIELD_PREFIX）はSolrParam. / SolrField.というプレーン文字列です。これらの名前はCamel / camelプレフィックスで始まらないため、HTTP境界でCamelヘッダ名前空間のみをブロックするHttpHeaderFilterStrategyは、これらをインバウンドHTTPリクエストからExchangeへ通過させてしまいます。HTTPコンシューマ（例：platform-http）をsolr:プロデューサに橋渡しするルートでは、任意のHTTPクライアントがSolrParam.*ヘッダーを設定して任意のSolrリクエストパラメータを注入できます。これにはシャードやstream.urlといったパラメータも含まれ、これによりSolrサーバが攻撃者指定のURL（内部サービスやクラウドメタデータエンドポイントなど）へサーバーサイドリクエストを発行させることが可能になります（サーバーサイドリクエストフォージェリ）。また、qtパラメータを使って管理用リクエストハンドラにアクセスできる場合もあります。同様にSolrField.*ヘッダーの設定により、インデックスされたドキュメントに任意のフィールドを注入可能です。認証されていないブリッジングコンシューマの場合は認証情報が不要です。影響を受けるバージョンは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へのアップグレードが推奨されます。アップグレード後は、Solrパラメータやフィールドを生のヘッダープレフィックスで設定するルートにおいて、SolrParam. / SolrField.の代わりにCamelSolrParam. / CamelSolrField.を使用する必要があります。すぐにアップグレードできない環境では、未信頼の入力からsolr:プロデューサに到達する前にSolrParam.*およびSolrField.*ヘッダーを削除し、信頼できるソースから必要なSolrパラメータとフィールドをルート内で設定してください。
Apache CamelのCamel Mongodb Gridfsコンポーネントにおいて、不適切な入力検証および不適切なアクセス制御の脆弱性が存在します。camel-mongodb-gridfsプロデューサーは、エンドポイントのoperationパラメーターが設定されていない場合（デフォルト）に、gridfs.operation Exchangeヘッダーから実行するGridFS操作を選択します。制御ヘッダーの定数（GridFsConstants.GRIDFS_OPERATION、GRIDFS_OBJECT_ID、GRIDFS_METADATA、GRIDFS_CHUNKSIZE、GRIDFS_FILE_ID_PRODUCED）は、それぞれ単純な文字列であるgridfs.operation、gridfs.objectid、gridfs.metadata、gridfs.chunksize、gridfs.fileidとなっていました。これらの名前はCamel/camelプレフィックスで始まらないため、HTTP境界上でCamelヘッダーの名前空間のみをブロックするHttpHeaderFilterStrategyは、これらのヘッダーを受信したHTTPリクエストからExchangeにそのまま通過させていました。HTTPコンシューマ（例：platform-http）をmongodb-gridfs:プロデューサーに明示的なoperationなしでブリッジするルートでは、任意のHTTPクライアントがgridfs.operationヘッダーを設定してルートの意図した操作を上書きできました。例えば、ファイルアップロードからremove（攻撃者提供のgridfs.objectidで指定されたファイルの削除）、listAll（バケット内の全ファイル列挙）、findOne（ファイル読み取り）への切り替えが可能であり、gridfs.metadata値をMongoDBドキュメントとして解析することでNoSQLオペレータインジェクションを可能にしました。ブリッジされるコンシューマが認証されていない場合、資格情報は必要ありません。この問題は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へのアップグレードを推奨します。アップグレード後は、GridFS操作やメタデータを生のヘッダー名で制御しているルートにおいて、gridfs.*の代わりにCamelGridFsOperation、CamelGridFsObjectId、CamelGridFsMetadata、CamelGridFsChunkSize、CamelGridFsFileIdを使用する必要があります。すぐにアップグレードできない場合は、mongodb-gridfs:エンドポイントで明示的なoperationを設定し、操作をヘッダーから取得しないようにし、信頼できない入口からのgridfs.*ヘッダーをプロデューサーに渡す前に除去してください。
出典：JVN（Japan Vulnerability Notes・独立行政法人情報処理推進機構（IPA）／JPCERT コーディネーションセンター／jvn.jp）を加工して作成。 全文検索は当サイト収録分（全289,735件）を対象とし、発表日の新しい順に表示しています。 本情報の最新性・正確性・完全性は保証されません。詳細は各 JVN 詳細ページをご確認ください。 なお本情報は製品・ソフトウェアの脆弱性に関するものであり、特定の法人・製品ベンダの評価や信用性を示すものではありません。