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

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 において、不適切なパス名制限（制限されたディレクトリへの「パストラバーサル」）の脆弱性が存在しています。認証されていない遠隔の攻撃者がこの脆弱性を悪用する可能性があり、このことによりシステムへの不正アクセスが発生する恐れがあります。この脆弱性は攻撃者がシステムの完全な制御を奪うことができるため、重大な深刻度に分類されています。したがって、Dell は顧客に対してできるだけ早急にアップグレードすることを推奨しています。

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 において、不適切な認証の脆弱性が存在します。リモートアクセス権を持つ認証されていない攻撃者がこの脆弱性を悪用する可能性があり、不正アクセスが発生する恐れがあります。本脆弱性は攻撃者にシステムの完全な制御を許すものであるため、重大度はクリティカルと評価されています。したがって、Dell はお客様に対し、可能な限り早急にアップグレードしていただくことを推奨します。

Apache Camel の Keycloak コンポーネントにおける不適切な認証、重要機能に対する認証の欠如、および安全に失敗しない（「Failing Open」）脆弱性です。camel-keycloak の KeycloakSecurityPolicy は、KeycloakSecurityProcessor.beforeProcess() を実行してルートを保護します。このメソッドは連続して3つのチェックを行います。まずアクセストークンを持たないリクエストを拒否し、次に requiredRoles が空でない場合にのみロールを検証し、さらに requiredPermissions が空でない場合にのみ権限を検証します。ベアラーアクセストークンの実際の暗号学的検証（ローカルJWTの場合は署名、発行者、有効期限の確認、トークンイントロスペクションの場合は有効状態と発行者の確認）は、これらのロールおよび権限のチェック内でのみ行われます。KeycloakSecurityPolicy は requiredRoles および requiredPermissions を空のまま（ドキュメント上の「基本設定」）にデフォルト設定しているため、そのように設定されたルートではロールと権限のチェックがスキップされ、したがってアクセストークンの検証が一切行われません。トークンの存在チェックは、トークンが欠落している場合に拒否しますが、不正なトークンは受け入れてしまいます。Authorization: Bearer ヘッダーに任意の非ヌル値、たとえば任意の文字列や偽造された署名なしJWTであってもポリシーが許可し、そのリクエストは署名、発行者、有効期限のチェックなしに保護されたルートに到達し、Keycloak への問い合わせも行われません。トークンは allowTokenFromHeader がデフォルトで true であるため、受信リクエストヘッダーから読み取られます。ルートをこのポリシーで保護する一般的な理由は、そのルートがサーバー側の処理を行うためですが、このバイパスにより、その処理へ認証されていないアクセスが発生します。保護されたルートがコード実行可能なプロデューサに転送する場合、認証なしのリモートコード実行が生じる可能性があります。この欠陥は CVE-2026-23552 とは独立しており、CVE-2026-23552 では発行者クレームに関わる問題が検証ルーチン内にチェックを追加することで解決されましたが、本件ではそもそも検証ルーチンに到達しないため、欠陥が残っています。この問題は Apache Camel のバージョン 4.15.0 から 4.18.3（未満）、および 4.19.0 から 4.21.0（未満）に影響します。ユーザーには本問題を修正したバージョン 4.21.0 へのアップグレードを推奨します。4.18.x 系列の利用者には 4.18.3 へのアップグレードを推奨します。すぐにアップグレードできない環境の場合は、すべての KeycloakSecurityPolicy に対し空でない requiredRoles または requiredPermissions を設定してトークン検証経路を確実に実行させること、トークンをリクエストヘッダーから受け取らない場合は allowTokenFromHeader を false に設定すること、またはポリシー適用前にフレームワーク層でトークン検証を行うことを推奨します。

`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 内部ヘッダーを除去すべきです。

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鍵素材を信頼度の低い主体が書き込み可能なデータから分離したシークレットに保管することが推奨されます。

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

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 セキュリティ重大度：クリティカルです）