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

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.*ヘッダーをプロデューサーに渡す前に除去してください。

Apache CamelのDNSコンポーネントにおける不適切な入力検証およびサーバーサイドリクエストフォージェリ（SSRF）の脆弱性について説明します。camel-dnsプロデューサは、DNS操作のパラメータ（クエリするリゾルバ、名前またはドメイン、レコードタイプとクラス、検索語）をExchangeメッセージヘッダから読み取ります。これらの定数値（DnsConstants.DNS_SERVER、DNS_NAME、DNS_DOMAIN、DNS_TYPE、DNS_CLASS、TERM）は、それぞれ文字列のdns.server、dns.name、dns.domain、dns.type、dns.class、およびtermに対応しています。これらの名前はCamelまたはcamel接頭辞で始まらないため、HTTP境界上でCamelヘッダ名前空間のみをブロックするHttpHeaderFilterStrategyは、これらのヘッダをインバウンドHTTPリクエストから直接Exchangeに通過させてしまいます。HTTPコンシューマ（例：platform-http）をdns:プロデューサにブリッジするルートでは、任意のHTTPクライアントがdns.serverヘッダを設定し、攻撃者が制御するDNSサーバーを指すSimpleResolverをdigプロデューサに構築させることが可能です。これにより、DNS経由のサーバーサイドリクエストフォージェリが発生し、攻撃者は問い合わせられた名前を観察したり、改ざんされた応答を返したりできます。また、dns.nameやdns.domainヘッダを設定して任意の内部ホスト名を解決し、それらの存在を開示（内部ネットワーク偵察）することも可能です。ブリッジされたコンシューマが認証されていない場合は認証情報が不要となります。この問題は以下の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へのアップグレードを推奨します。アップグレード後は、dns.*やtermの生ヘッダ名ではなく、CamelDnsServer、CamelDnsName、CamelDnsDomain、CamelDnsType、CamelDnsClass、CamelDnsTermを使用してDNS操作を行うルートを構成してください。すぐにアップグレードできない環境では、dns:プロデューサの前に信頼できない入力からdns.*およびtermヘッダを削除し、信頼できるソースからDNSサーバーと検索パラメータをルート内で設定することを推奨します。

TraefikはHTTPリバースプロキシおよびロードバランサーです。v2.11.51、v3.6.22、およびv3.7.6以前のバージョンでは、TraefikのBasicAuth、DigestAuth、およびForwardAuthミドルウェアは、自身の値を書き込む前に正規の大文字小文字のヘッダーを削除しますが、多くのバックエンドがダッシュ形式と同様に正規化するアンダースコアを含む変種のヘッダー名については考慮していません。攻撃者が保護されたルートに到達可能な場合、アンダースコア変種のヘッダーを注入してTraefikの削除をすり抜け、バックエンドに到達させることができます。または、認証されていないForwardAuthのauthResponseHeadersパスにおいて、Traefikが設定しようとした値の代わりにこのヘッダーを用いてアイデンティティや認可コンテキストを偽装することが可能です。この問題はv2.11.51、v3.6.22、およびv3.7.6のバージョンで修正されています。

Crawl4AIはオープンソースのLLM対応ウェブクローラーおよびスクレイパーです。バージョン0.9.0以前では、クローラーがダウンロードしたファイルを保存するときに、保存先のファイル名が攻撃者の影響を受ける入力から取得され、ダウンロードディレクトリに隔離せず結合されていました。絶対パスやディレクトリトラバーサルを含むファイル名がダウンロードディレクトリから逸脱し、攻撃者が制御する内容で任意のファイルへの書き込みが可能でした。HTTPクローラーのパスはレスポンスのContent-Dispositionヘッダーのファイル名を使用し、ブラウザクローラーのパスはダウンロードの推奨ファイル名を使用します。書き込まれるバイトが攻撃者に制御されるため、この問題によりリモートコード実行が発生する可能性があります。この問題はバージョン0.9.0で修正されています。

Crawl4AIはオープンソースのLLM対応ウェブクローラーおよびスクレイパーです。バージョン0.9.0以前では、Docker APIサーバーがリクエストで提供されたbrowser_config.extra_argsを受け入れており、これがChromiumの起動引数に渡されていました。攻撃者はChromiumのスイッチを注入し、--no-zygoteと共に子プロセスの起動コマンドを置き換えることで、Chromiumがコンテナの実行時ユーザー権限で攻撃者制御下のコマンドをフォークまたは実行する可能性がありました。Docker APIはデフォルトで認証が無効になっているため、単一のリクエストで任意のコマンドを実行できました。この脆弱性はバージョン0.9.0で修正されました。

Microsoft Edge（Chromiumベース）における不適切な認可の脆弱性により、ネットワーク経由で不正な攻撃者がセキュリティ機能をバイパスできる可能性があります。

curlのクッキー解析ロジックに欠陥があるため、悪意のあるHTTPサーバーがパブリックサフィックスリストのチェックを回避して「スーパークッキー」を設定できるようになります。これにより、攻撃者が制御するオリジンがクッキーを注入し、その後curlがそのクッキーを範囲指定して関連のない第三者ドメインに送信してしまう可能性があります。

SASL認証を扱うcurlのロジックは、ポインタをクリアせずにGSASLコンテキストを*二度*クリーンアップしてしまい、同じポインタを二回`free()`してしまう可能性があります。

curl に `.netrc` ファイルを使用して認証情報を取得するよう指示し、かつパスワードなしのユーザー名を含む URL（例: `https://user@example.com/`）を指定した場合、curl はそのホストに対して `.netrc` ファイルに存在する別のユーザーのパスワードを誤って取得して使用する可能性があります。これは、指定されたユーザーと一致するエントリが存在しない場合に発生します。

環境変数によるプロキシ設定で制御される連続転送のためにlibcurlハンドルを再利用する際、libcurlはリクエスト間でプロキシ認証状態をクリアしません。具体的には、最初の転送がDigest認証を使って`proxyA`に対して認証を行った場合、その後の`proxyB`経由の転送で、本来`proxyA`専用であるはずの`Proxy-Authorization:`ヘッダーが誤って漏洩してしまいます。

libcurlには、プロキシ認証情報のクリアを指示されたにもかかわらずそれを行わず、古い認証情報が残ってしまい、それらを知らない状態で使用すべきでない後続の転送に使われてしまうという欠陥がありました。

ArcGIS Serverには制限されていないファイルアップロードの脆弱性があります。認証されていない攻撃者が特別に作成されたファイルを影響を受けるエンドポイントにアップロードすることで、この問題を悪用できます。悪用に成功すると、任意のファイルをアップロードできる恐れがあります。

libcurlには、アプリケーションが`CURLOPT_STREAM_DEPENDS`または`CURLOPT_STREAM_DEPENDS_E`を使用してHTTP/2ストリーム依存ツリーを設定し、その後`curl_easy_reset()`を呼び出し、最後に`curl_easy_cleanup()`でハンドルを終了する際に、Use-After-Freeの脆弱性が存在します。この最終的なクリーンアップ段階で、libcurlはリセット操作中にすでに解放された内部構造体にアクセスし、変更を試みます。

libcurlは以前使用した接続を接続プールに保持し、後続の転送で設定が一致する接続を再利用します。デフォルトのネイティブCAトラストを最初に使用するイージーハンドルは、アプリケーションが同じハンドルを後の転送でカスタムCAマテリアルに切り替えた後も、ネイティブプラットフォームストアの信頼を継続します。

特定のHTTPオリジン（`hostA`）に対して**Digest**認証を使用してlibcurlで転送を正常に行った後、同じハンドルを再利用して別のオリジン（`hostB``）に変更して2回目の転送を行うと、libcurlは本来`hostA`向けの`Authorization:`ヘッダーフィールドを誤って`hostB`に渡してしまいます。

Apache IoTDBにおける認証バイパス（なりすまし）の脆弱性です。特定のThrift RPCクエリハンドラでsessionIdパラメータの厳密な検証が欠如しています。攻撃者は偽造されたsessionIdを用いたリクエストを構築してopenSession認証を経ずに有効なクエリ結果を取得できます。これにより認証を回避でき、時系列データを不正に読み取ることが可能になります。この問題はApache IoTDBのバージョン1.3.3から2.0.8の前のバージョンに影響を及ぼします。ユーザーはこの問題を修正したバージョン2.0.8へアップグレードすることを推奨します。

Apache IoTDBのDataNode内部RPCインターフェースでは、Triggerインスタンスを作成する際にアップロードされたTrigger JARの名前を十分に検証せずにファイルパスの構築に使用しています。もしDataNodeの内部RPCポートが信頼できないネットワークに公開されている場合、攻撃者はJAR名にパストラバーサルの文字列を使って、意図したTriggerインストールディレクトリの外部にファイルを書き込む可能性があります。これにより、IoTDBプロセスの権限で任意のファイルを書き込める恐れがあります。この問題はApache IoTDBのバージョン1.3.3から2.0.8未満のバージョンに影響します。ユーザーは本問題を修正したバージョン2.0.8にアップグレードすることを推奨します。

BeyondTrust Remote Support の認証サブシステムには、重大な事前認証の脆弱性が存在します。認証リクエストの不適切な処理により、認証されていないリモート攻撃者がアクセス制御を回避し、特権を持つアカウントを含む機器へ不正にアクセスする可能性があります。悪用するには特定の認証設定が有効になっている必要があります。

BeyondTrust Remote SupportおよびPrivileged Remote Accessのウェブアプリケーションコンポーネントに、高重大度の脆弱性が存在しています。この脆弱性は特定の入力パラメータの処理に関連しています。ユーザーから提供された入力の検証が不十分であるため、限られた権限を持つ認証済み攻撃者が、自身の認可範囲を超えた意図しないリソースやデータにアクセス可能となります。悪用は特定の権限を持つアカウントに限定されています。

SUSE Rancher FleetのHelm Deployer（バージョン0.15の0.15.2未満、0.14の0.14.6未満、0.13の0.13.11未満、及び0.12の0.12.15未満）において、「valuesFrom」の参照の検証が欠如しているため、あるテナントの所有者が他のテナントのFleet認証情報にアクセスできる可能性があります。

Google Chrome 150.0.7871.46以前のANGLEにおいて、信頼されていない入力の検証が不十分であったため、リモートの攻撃者が細工されたHTMLページを利用してサンドボックスから脱出する可能性がありました。（Chromiumセキュリティの深刻度：高）」

Google Chrome 150.0.7871.46より前のバージョンのSkiaにおける整数オーバーフローにより、リモートの攻撃者が細工されたHTMLページを介してサンドボックスを脱出する可能性がありました。（Chromiumのセキュリティ重大度は中です）

Google Chrome 150.0.7871.46 未満のバージョンの ANGLE における use after free の脆弱性により、リモートの攻撃者が細工された HTML ページを介してサンドボックスから脱出を実行する可能性がありました。（Chromium セキュリティの重大度は「高」です）

Google Chrome 150.0.7871.46より前のバージョンのTintにおいて、境界外書き込みの脆弱性が存在しました。この脆弱性により、リモートの攻撃者が細工されたHTMLページを介してサンドボックスを脱出する可能性がありました。（Chromiumのセキュリティ深刻度：高）

Mac版Google Chromeのバージョン150.0.7871.46以前のANGLEにおける境界外書き込みの脆弱性により、リモートの攻撃者が細工されたHTMLページを介してサンドボックスから脱出する可能性がありました。（Chromiumセキュリティの深刻度：中）

Google Chrome 150.0.7871.46より前のバージョンのANGLEにおけるUse after freeの脆弱性により、リモートの攻撃者が特別に細工されたHTMLページを介してサンドボックスを脱出する攻撃を実行する可能性がありました。（Chromiumセキュリティ重大度：重大）

150.0.7871.46以前のGoogle ChromeのV8において初期化されていないメモリの使用により、リモートの攻撃者が細工されたHTMLページを介してサンドボックス内で任意のコードを実行できる可能性がありました。（Chromiumのセキュリティ重大度は低とされています）

150.0.7871.46より前のGoogle ChromeのANGLEにおける信頼されていない入力に対する検証が不十分であったため、リモートの攻撃者が細工されたHTMLページを介してサンドボックスを脱出する可能性がありました。（Chromiumセキュリティの深刻度は高です）

Google Chrome 150.0.7871.46より前のバージョンのDawnにおいて、境界外読み取りの脆弱性によりリモートの攻撃者が細工されたHTMLページを介してサンドボックスをエスケープできる可能性がありました。（Chromiumセキュリティの深刻度：低）

Google Chrome 150.0.7871.46 より前のバージョンの Dawn において、use after free の脆弱性が存在し、リモートの攻撃者が細工された HTML ページを介してサンドボックスを脱出する可能性がありました。（Chromium セキュリティ重大度：クリティカルです）

Google Chrome 150.0.7871.46より前のバージョンのSkiaにおけるUse after freeにより、リモートの攻撃者が細工されたHTMLページを介してサンドボックスを脱出する可能性がありました。（Chromiumのセキュリティ重要度は重大です）

Google Chrome 150.0.7871.46より前のバージョンのDawnにおいて、境界外の読み取りおよび書き込みの脆弱性が存在しました。この脆弱性により、リモートの攻撃者が細工されたHTMLページを介してサンドボックスを回避できる可能性がありました。（Chromiumセキュリティの重大度：重大です）

Google Chromeのバージョン150.0.7871.46より前に存在したTintの型混同の脆弱性により、リモート攻撃者が細工されたHTMLページを介してサンドボックスを脱出する可能性がありました。（Chromiumのセキュリティ重大度は高です）

Mac用Google Chromeのバージョン150.0.7871.46以前のDawnにはUse after freeの脆弱性が存在し、リモートの攻撃者が細工されたHTMLページを介してサンドボックスの脱出を行う可能性がありました。（Chromiumのセキュリティ深刻度は高と評価されています）

150.0.7871.46より前のGoogle ChromeのANGLEにおけるUse after freeにより、リモートの攻撃者が細工されたHTMLページを介してサンドボックスをエスケープする攻撃を実行する可能性がありました。（Chromiumのセキュリティ重大度は高です）

HoppscotchはAPI開発エコシステムです。バージョン2026.4.1以前のhoppscotch-backendのセルフホスト型展開において、認証されていないPOST /v1/onboarding/configエンドポイントにマスアサインメントの脆弱性があります。グローバルなNestJSのValidationPipeではwhitelist: trueが設定されておらず、SaveOnboardingConfigRequestに宣言されていないリクエストボディの余分なプロパティが除去されず、サービス層で正当なInfraConfigのエントリであるかのように処理されます。JWT_SECRETやSESSION_SECRETのようなキーは有効なInfraConfigEnum値であり、検証時に明示的に拒否されないため、認証されていない攻撃者がオンボーディング完了前（またはユーザーが存在しない状態）に新規インスタンスにアクセスできる場合、これらの値をデータベースに上書きすることが可能です。JWT_SECRETを書き換えると攻撃者はJWT署名キーを制御し、管理者を含む任意のユーザーのトークンを偽造できるため、サーバー全体を完全に乗っ取ることができます。この問題はhoppscotch 2026.5.0で修正されています。

containerdはオープンソースのコンテナランタイムです。バージョン2.3.2、2.2.5、および2.1.9より前のバージョンには、CRIチェックポイントインポートプロセスにおいて、チェックポイントイメージの設定内で指定されたイメージ参照を検証しない脆弱性があります。ポッドを作成する権限を持つ攻撃者は、細工されたチェックポイントイメージを使用してcontainerdに悪意のあるイメージをプルさせ、任意のローカルタグを割り当てることでノードのローカルイメージキャッシュを汚染できます。その後、同じノード上の他のポッドがIfNotPresent（またはNever）プルポリシーで汚染されたタグを使用しようとすると、正当なイメージの代わりに攻撃者の悪意のあるイメージが実行されてしまいます。これにより、影響を受けたポッドは侵害され、攻撃者が被害ポッドの権限で任意のコードを実行可能になる恐れがあります。この問題は、バージョン2.3.2、2.2.5、および2.1.9で修正されています。

containerdはオープンソースのコンテナランタイムです。バージョン2.3.2、2.2.5、2.1.9より前のバージョンでは、CRI実装が信頼できないチェックポイントイメージのメタデータ内にあるContainer Device Interface（CDI）注釈をコンテナの復元時に不適切に信頼していました。コンテナをチェックポイントから復元する際に、containerdはポッド作成時の仕様のみに依存せず、チェックポイントアーカイブからCDI関連の注釈を保持します。これにより、ポッド作成権限を持つユーザーが標準的なKubernetesのリソース割り当てやデバイスプラグインの適用を回避し、任意のCDI編集（デバイスノードやホストマウントなど）を復元されたコンテナに注入できるようになります。成功した攻撃には、ノードでCDIが有効化されており、要求されたデバイスに対応するホストCDI仕様が存在していることが必要です。CDIが無効化されている環境や敏感なデバイス仕様が存在しない環境は影響を受けません。この問題はバージョン2.3.2、2.2.5、2.1.9で修正されています。

UltraVNCリピーター1.8.2.2までのバージョンは、ハードコードされたデフォルトパスワードでHTTP管理サーバーを初期化します。repeater/webgui/settings.cの197行目では、settings2.txtが初回実行時に存在しない場合、リピーターは管理者パスワードとしてリテラル文字列「adminadmi2」を、strcpy_s(saved_password, 64, "adminadmi2")を通じて書き込みます。HTTPベーシック認証ハンドラwi_decode_auth()は、このパスワードをレート制限やロックアウトなしで確認します。リピーターのHTTPポート（デフォルトTCP 80）にアクセス可能なリモート攻撃者は、新規または未変更のインストールにおいて、この既知のデフォルト認証情報を用いて管理者として認証でき、許可・拒否ルールやセッション可視性を含むリピーターの構成を完全に制御できます。

@fastify/middie のバージョン9.1.0から9.3.2までは、ミドルウェアのパスと照合する前にパスパラメーター値内のエンコードされたスラッシュ %2F をデコードしますが、Fastifyの基盤となるルーターはルート検索時にエンコーディングを保持します。この2つのレイヤーが正規のリクエストパスについて不一致を起こすため、ミドルウェアはルートハンドラーがマッチするURLにマッチしません。パラメーター化されたパス上で認証、認可、レート制限、監査のためにミドルウェアを使用している場合、攻撃者はパラメーター位置にエンコードされたスラッシュを含む単一の細工されたURLを送信することで保護されたハンドラーにアクセスできます。このバイパスはHTTPメソッドに依存せず、認証や特別な前提条件を必要としません。パッチとしては、@fastify/middie を9.3.3にアップグレードしてください。回避策としては、セキュリティ判断のためにパラメーター化されたミドルウェアパスを避けるか、認証をルートハンドラーで行うか、ルーターによるリクエスト解決後に実行されるFastifyのフックで認証を強制してください。