エグゼクティブ サマリー

2025年3月、Apacheは、Apache Tomcatに影響を与える脆弱性としてCVE-2025-24813を公開しました。これは、ApacheのWebサーバーがJavaベースのWebアプリケーションを実行できるようにする、広く使われているプラットフォームです。この欠陥はApache Tomcatのバージョン9.0.0.M1から9.0.98、10.1.0.M1から10.1.34、および11.0.0.M1から11.0.2に影響するもので、リモートでコードが実行される恐れがあります。

同月、Apacheは、メッセージ ルーティングのミドルウェア フレームワークであるApache Camelに、さらに2つの脆弱性があることを明らかにしました。これらの脆弱性はCVE-2025-27636およびCVE-2025-29891であり、Apache Camelのバージョン4.10.0から4.10.1、4.8.0から4.8.4、および3.10.0から3.22.3に影響を及ぼすもので、同様にリモートでのコード実行を攻撃者に許すものです。

何百万人もの開発者がApache Foundationが提供するプラットフォームに依存しているため、これらの脆弱性は重大なものとされます。これらの脆弱性の悪用に成功すると、攻撃者はTomcat/Camelの権限で任意のコードを実行できるようになります。

Apacheはパッチをリリースし、調査員によってすぐに概念実証(PoC)エクスプロイトが公開されましたが、脆弱なサーバーに対するスキャンやプローブは、情報公開の直後から散見されるようになっています。弊社でもまた、これら3つの脆弱性によりリモートでコードが実行される可能性があることを確認しています。

パロアルトネットワークスは、2025年3月にこれらの脆弱性に関連する125,856件のプローブ/スキャン/エクスプロイトの試みをブロックしています。弊社では速やかに修正パッチの適用を実施することを推奨しています。

パロアルトネットワークスのお客様は、以下の製品とサービスをご利用いただくことでより強固な保護を構築いただけます。

情報漏えいの可能性がある場合、または緊急の案件がある場合は、Unit 42インシデント レスポンス チームまでご連絡ください。

Unit 42の関連トピック Vulnerabilities, CVE-2025-24813, CVE-2025-27636, CVE-2025-29891

CVE-2025-24813:Apache Tomcat

脆弱性の概要

CVE-2025-24813は、Apache TomcatのPartial PUT機能に脆弱性があり、攻撃者にディスク上のシリアライズされたセッション ファイルを上書きされ、任意のコードを実行される可能性があります。

この脆弱性はContent-Rangeヘッダを含むPartial PUTリクエストを、パッチを適用していないTomcatシステムが不適切に処理するため、TomcatがHTTPセッションデータを永続化するように設定されている場合に生じます。

Partial PUT

用語「Partial PUT」とは、リソースを完全に置き換えるのではなく、リソースの一部だけを更新するHTTP PUTリクエストを指します。サポートされている場合、部分PUTは通常HTTPリクエストのContent-Rangeヘッダーを使用して、リソースのどの部分を変更すべきかを指定します。

これにより、開発者はリソース セグメントをチャンク単位でアップロードまたは上書きすることができます。しかしながら、Partial PUTが適切に処理されない場合、ファイルの増分アップロードを実行したり、ファイルの特定の部分を上書きしたり、特定のセキュリティチェックを回避したりするために悪用される可能性があります。

Apache Tomcatのセッション永続化機能

Apache TomcatのHTTPセッション マネージャーには、セッションの永続化機能が備わっています。この機能は、サーバーのシャットダウン時にセッション データをファイルまたはデータベースに保存し、サーバーの再起動時にこのキャッシュデータを再読み込むものです。セッション データには、ユーザーのログイン ステータスやプリファレンスなどの情報が含まれており、この機能は、サーバーの再起動をまたいでユーザーのセッション データを保持するのに役立ちます。

Tomcatはこの保存されたセッション データを、シリアライズと呼ばれるプロセスを使ってバイト ストリームとしてエンコードして、シリアライズされたデータをローカル ファイル システムに保存します。そしてHttpSessionオブジェクトに格納されているすべてのセッション属性をシリアライズします。これにはWebアプリケーションがsession.setAttribute()を使って明示的にセッションに配置したデータも含まれます。この情報は通常、$TOMCAT_HOME/webapps/ROOT/のどこかに保存されています。

しかし、シリアライズされたセッション データは、TomcatのexecutePartialPut関数が使用するのと同じディレクトリに格納されます。ユーザーは、このディレクトリにあるセッションIDとキャッシュされたデータのファイル名を制御するためにHTTPリクエストを作ることができます。すなわち、攻撃者は意図的にセッションIDを設定することで、以前にキャッシュに保存された悪意のあるコードのキャッシュ ファイル名と一致させることが可能とされます。その結果、キャッシュされたファイルがデシリアライズされ、埋め込まれた悪意のあるコードのトリガーを許すことにつながります。

前提条件

Content-Rangeヘッダーは部分更新でよく使われています。このヘッダーは、リクエスト ボディがリソース全体ではなくリソースの一部を含んでいることを示します。HTTP PUTリクエストにContent-Rangeヘッダが含まれている場合、TomcatはPUT要求の内容(ボディ)をキャッシュの場所に保存します。次のコード スニペットは、Tomcatがコンテンツを含むHTTP PUTリクエストからのデータを保存することを示したものです。

この脆弱性を悪用するには、脆弱なTomcatの設定に次の2つの前提条件が必要であるとされています。

  1. TOMCAT_HOME/conf/web.xmlにあるTomcat設定ファイルの読み取り専用パラメータが無効になっている。無効化された読み取り専用パラメータを含むweb.xmlのセクションは以下の通りです。

脆弱性を利用する

弊社では2025年3月にCVE-2025-24813の悪用をテストしました。この脆弱性を悪用するのに2つのステップがあります。

  • まず、コンテンツ範囲と自分で定義したファイル名をURLに指定したHTTP PUTリクエストによって、ペイロードをファイルとして終了させ、ステージングします。このファイルには、後でデシリアライズするためにシリアライズされた悪意のあるコードが含まれています。
  • 次に、JSESSIONID= の直後にピリオドで始まる自己定義のファイル名で構成されるクッキーを含む追加の HTTP GET リクエストを送信することで、エクスプロイトを起動します。この場合、クッキーの行はクッキーを読み取ることになります。以下の図1が示すように、Cookie:「JSESSIONID=.[filename]となり、これがキャッシュのデシリアライズを引き起こし、悪意のあるコードを実行させます。
2ステップのサイバー攻撃プロセスを示すフローチャート。ステップ1では「Content-Range: bytes 0-5/100」で「PUT /filename.session」と書かれたHTTPリクエストがサーバーに送られる。ステップ2では、攻撃者は「GET /」とラベル付けされたHTTPリクエストに「Cookie:JSESSIONID=_filename」を付けたHTTPリクエストをサーバーに送る。矢印はステージとサーバー間の通信方向を示す。
図1.エクスプロイトの2つのステップ。

ステップ1: シリアライズされた悪意のあるコードをステージ化する

最初のステップは、シリアライズされた悪意のあるコードのファイルをHTTP PUTリクエストのボディとして送信することです。図2がPUTヘッダー行で示すように、URIのファイル名は.sessionで終わっているので、Apache Tomcatは悪意のあるコードをローカル ファイル システム上のセッション ファイルとしてキャッシュします。

図2は、gopan.sessionをファイル名とする最初のステップのPUTリクエストです。このトラフィックからのHTTP PUTリクエストのフォーマットは以下のようになります。

PUT /[filename].session HTTP/1.1

HTTP PUTリクエストのスクリーンショット。ヘッダーの一部とファイルの内容が示されている。ヘッダーには、ホスト、コネクション タイプ、およびコンテンツの長さに関する情報が含まれる。ハイライトされた部分は、ファイル名「gopan.session」がリクエストのコンテンツ ボディとして送られることを示している。
図2.ステップ1のペイロード。

ステップ2: エクスプロイトのトリガー

ステップ2は、エクスプロイトを起動し、悪意のあるコードを実行するために、フォローアップのHTTP GETリクエストを送信することです。図3は、前のステップで使われたJSESSIONIDクッキー値を持つHTTP GETリクエストを示したものです。このクッキーの形式は次のとおりです。

Cookie: JSESSIONID=.[filename]

HTTPリクエストとレスポンスを表示するコンピューター端末のスクリーンショット。レスポンスはHTTP 500エラーを示し、クッキー データの一部はファイル名「gopan」と「gopan-family」を参照している。
図3.脆弱性を悪用して、ステップ1で送信したペイロードを実行する。

このエクスプロイトのクッキーの値は、JSESSIONIDのファイル名の値の前にピリオド(.)が使われており、この先頭のピリオドによって、Tomcatはセッション ファイルを先頭のドットで保存するようになります。

ソースコード解析

TomcatがPUTボディをファイルにキャッシュする方法

図4が示すように、Tomcatはまず、設定ファイルでreadonlyフラグが有効になっているかどうかをチェックします。有効である場合、Tomcatは悪意のあるコードを含め、キャッシュにコードを書き込みません。

HttpServlet 操作間の相互作用の詳細を示すフローチャート。「doPut」はリクエストとレスポンスを処理することから始まり、「executePartialPut」または「write req, save file」の実行を決定する前に、実行可能性と範囲をチェックします。別のブランチでは、「replacePartialPut」が文字列リクエストを処理し、一時ファイルを作成。その後、ファイル オブジェクトを検証し、セッションをファイル オブジェクトに書き込んでいる。
図4.ステップ1:PUTからファイルを書き込む。
  • readonlyフラグが有効でない場合、TomcatはHTTPヘッダーのContent-Rangeフィールドもチェックします。
  • リクエストにContent-Rangeヘッダがない場合、Tomcatは処理を終了します。
  • リクエストにContent-Rangeヘッダーがある場合、TomcatはHTTP PUTリクエストからのセッション データ(この場合はgopan.session)を、図5に示すように2つの場所に保存します。
    • 最初のファイルは、$TOMCAT_HOME/webapps/ROOT/の下に、先頭のピリオドを除いた通常のキャッシュ ファイルとして保存されます。
    • 2番目は、作業ディレクトリの$TOMCAT_HOME/work/Catalina/localhost/ROOT/の下に、先頭にピリオドを付けた一時ファイルとして保存されます。
作業ディレクトリの下にファイルがあるApache TomcatのインストールをハイライトしたIDE内のディレクトリ構造のスクリーンショット。Tomcatインストールのルート ディレクトリ。ファイル名に先頭のピリオドがないセッション ファイルは、カレント キャッシュ ディレクトリの下に通常のファイルとして保存されます。ファイル名の先頭がピリオドのセッション ファイルは、作業ディレクトリの下に一時ファイルとして保存されます。
図5.キャッシュされたセッション ファイル。

重要な点は、Tomcatがセッションを復元するときに、同じ作業フォルダからキャッシュされたセッション ファイルもロードすることです。

図6と図7は、Tomcatがjava/org/apache/catalina/servlets/DefaultServlet.javaでセッションを復元するときに、キャッシュされたセッション ファイルをロードするために使用するデフォルトのJavaサーブレットのコード セグメントを示したものです。黄色のコメントは、コードによって実行されたアクションを表しています。

HTTPサーバーのリクエストとレスポンスの処理に関連するコードを表示するJavaプログラムのスクリーンショット。
図6.Tomcatで使われるApacheのデフォルトJavaサーブレットの最初のコード セグメントです。
シンタックス ハイライト付きのテキスト エディタで表示されたプログラミング コードの一部を示すスクリーンショット。
図7.Tomcatで使われるApacheのデフォルトJavaサーブレットの2番目のコード セグメント。
脆弱性がHTTPリクエストによってどのようにトリガーされるか

TomcatがセッションIDを持つHTTPリクエストを受信したとき、設定でセッションの永続化が有効になっていれば、そのセッションメモリ上に見つけようとします。Tomcatがメモリ上でセッションを見つけられない場合、保存されたキャッシュ ファイルからセッションを復元します。この時点で、Tomcatは図8に示すようにセッション ファイルをデシリアライズします。

セッション管理プロセスを表すフローチャート。findSession、swapIn、loadSessionFromStore、loadなどの関数と、セッションがメモリ内にあるかどうかのチェックに加え、ストアからのロード、コンテンツのデシリアライズなどのステップの詳細が含まれている。
図8.ステップ2:セッションIDからデシリアライズまで。

図8はTomcatのセッション管理の流れを示したものです。セッションを見つけ、ディスクからロードし、その内容をデシリアライズするコードは、以下のファイルに実装されています。

  • java/org/apache/catalina/session/PersistentManagerBase.java
  • java/org/apache/catalina/Store.java
  • java/org/apache/catalina/session/FileStore.java

図9は、java/org/apache/catalina/session/PersistentManagerBase.javaのコード セグメントで、セッション データがメモリ上にない場合、Tomcatにセッション データのファイルを見つけるように指示しているものです。

Javaによるコンピュータ コードのスクリーンショット。このコードには、findSessionと呼ばれるメソッドが含まれており、メモリ内でセッションが利用可能かどうかをチェックし、見つからない場合はファイルからセッションを取得することに関連するコードロジックの一部を説明するコメントが添えられている。
図9.PersistentManagerBase.javaのコード セグメントで、セッション データがメモリにない場合はファイルとして検索します。

図10と図11は、同じPersistentManagerBase.javaファイルのコード セグメントを示し、保存されたキャッシュ ファイルからセッション データをロードする方法を示したものです。

セッション管理と例外処理の構文を特徴とするコンピューター コードのスクリーンショット
図10:ファイルからセッションをロードするPersistentManagerBase.java のコード セグメント(1/2 )。
「loadSessionFromStore」という名前のメソッドを表示しているコード スニペットのスクリーンショット。このコードには、例外処理とエラー メッセージのロギングが含まれている。
図11.ファイルからセッションをロードするPersistentManagerBase.java のコード セグメント(2/2)

図11が示すように、store.load(id)はデシリアライゼーションを引き起こし、攻撃者が以前にファイルに埋め込んだ悪意のあるコードを呼び起こします。その結果、任意のコードが実行されます。

このソースコードを見直すと、まずTomcatがHTTP PUTリクエストからどのようにセッションデータを保存するかがわかります。このレビューでは、CVE-2025-24813脆弱性に対するエクスプロイト攻撃が、1回のフォローアップHTTP GETリクエストによってどのようにトリガーされるかについての洞察も提供しています。

しかし、Apacheのソフトウェアで悪用が試みられているのはTomcatだけではありません。また、Apache Camelの2つの脆弱性に対する悪用の試みも指摘されています。

CVE-2025-27636&CVE-2025-29891:Apache Camel

Apache Camelの概要

Apache Camelはオープンソースの統合フレームワークであり、開発者はこれを使用することで信頼性が高くスケーラブルな方法で異なるシステムを接続することができます。Camelを使用することで、開発者はさまざまなドメイン固有の言語でルーティングとメディエーションのルールを定義し、多様なシステムやアプリケーションを統合することができます。Apache Camelは幅広いプロトコルとテクノロジーをサポートしています。

ほとんどのCamelメッセージ ハンドラーはJavaパッケージとして提供されており、開発者は製品に含めるパッケージを選択できます。

エクスプロイトの詳細

暗号化の如何に関わらず、HTTPはインターネット上でデータを送信するための一般的な方法です。CamelはJettyNettyのような様々なHTTPコンポーネントを使用しますが、Camelは最終的に、解析されたHTTPメッセージをcamel-coreと呼ばれるコア コンポーネントにルーティングし、さらに処理を行います。

CamelとJettyやNettyのようなHTTPコンポーネント間のデータ交換を容易にするために、開発者はHTTPレスポンス コードのような重要なコンテキスト情報を格納する、キーと値のペアを使用する方法を考案しました。HTTPヘッダーは処理で使用されるため、CamelはHTTPヘッダーも同じキーと値のペア内に格納します。内部コンテキスト情報と外部データの競合を避けるため、Camelの開発者はすべての内部コンテキスト キーにCamelプレフィックスを追加し、外部ヘッダーが問題を引き起こすのを防ぐフィルタを実装しました(図12)。

HTTPヘッダーとCamelヘッダーというラベルの付いた2つのセクションを示す図で、それぞれUser-Agent、Host、Accept、CamelExecCommandExecutable、CamelHttpResponseCodeのような特定のヘッダー名の例を含んでいる。
図12.通常のHTTPヘッダーとApache Camel HTTPヘッダーの比較。

しかし、フィルターは大文字と小文字を区別して動作するため、攻撃者はヘッダーの大文字と小文字を変更することでフィルターをバイパスできる可能性があります。

ソースコード解析

デフォルトでは、Camelはデフォルトのヘッダー フィルター ハンドラーが登録されており、Camel、camel、org.apache.camelで始まるすべてのヘッダ行を無視するようにフィルターに要求します。このコードは、components/camel-http-base/src/main/java/org/apache/camel/http/base/HttpHeaderFilterStrategy.javaにあります(図13に該当するセグメントを示します)。

HttpHeaderFilterStrategyという名前のコード スニペットの画像で、HTTPヘッダーのフィルタリングに関連するメソッドを示している。コード コメントや、Camelケースやドメイン名を指定するフィルター条件などの要素を含む。
図13.特定のヘッダー行を無視するために作成されたHttpHeaderFilterStrategy.javaのコード セグメント。

CamelはHTTPリクエスト ヘッダーを列挙し、applyFilterToExternalHeaders関数を実行します。そして以下の図14が示すように、components/camel-http-common/src/main/java/org/apache/camel/http/common/DefaultHttpBinding.javaを使用してヘッダを内部マップに書き込みます。

サーブレット リクエストのHTTPヘッダーを読み取るコードを含む、コンピュータのコード スニペットのスクリーンショット(コメントと条件文が見える)。
図14.DefaultHttpBinding.javaのコード セグメント。

ヘッダー フィルタリング ロジックは、Camelの設定に基づいて異なるマッチングを行います。デフォルトでは、CamelはtryHeaderMatchを使用してヘッダーの先頭のみをチェックします。これは以下の図15が示すようにcore/camel-support/src/main/java/org/apache/camel/support/DefaultHeaderFilterStrategy.javaを介して行われます。

HTTPヘッダー フィルターを処理するコードのスクリーンショット。下線および赤い矢印がtryHeaderMatchを示している。
図15.TryHeaderMatchを示すDefaultHeaderFilterStrategy.javaのコード セグメント。

攻撃者がヘッダーCAmelExecCommandExecutableCAmelという単語の大文字のAを使ってオーバーライドし、開発者がcamel-execパッケージを使用していると仮定すると、camel-execはその値を読み込み、下の図16が示すように、components/camel-exec/src/main/java/org/apache/camel/component/exec/impl/DefaultExecBinding.javaを通して実行します。

コマンド実行に関連するメソッド実装とパラメータ処理を含むDefaultExecBindingクラスを特徴とするApache Camelプロジェクトのコードのスクリーンショット。
図16.DefaultExecBinding.javaのコード セグメント。

開発者がこのエンドポイントを良性の実行ファイルに設定した場合、攻撃者はリバースシェルを使ってエンドポイントを危険なコマンドに置き換えることができます。そしてリモートでコマンドを実行することで、リバースシェルを取得することに成功します。

遠隔測定

2025年3月中、弊社が実施した遠隔測定では、Tomcatの脆弱性CVE-2025-24813、およびCamelの脆弱性CVE-2025-27636、CVE-2025-29891について、70ヶ国以上から発信された125,856件のスキャン、プローブ、またはエクスプロイト攻撃が確認されました。図17のトリガー データの分析が示すように、この活動の頻度は、2025年3月中旬にこれらの悪用が発表された直後に急増し、最初の1週間でピークに達しています。

さらにデータより、自動化されたスキャナーとアクティブなエクスプロイトの両方が野放しになっていることが示唆されています。

トリガーの数を時系列で表した折れ線グラフ。グラフはX軸に2025-03-16から2025-03-30までの日付を示している。トリガー数は当初増加し、期間半ばでピークに達し、終了日まで減少を見せている。Unit 42とパロアルトネットワークスのロゴがロックされている。
図17.2025年3月に検出されたエクスプロイト活動。

エクスプロイト攻撃のペイロード

弊社ではこれらのスキャン、プローブ、およびエクスプロイト攻撃を試みるうえで攻撃者がこれまでに使用したペイロードをキャプチャしました。

図18は、Apache Tomcatの脆弱性CVE-2025-24813の悪用を試みるイニシャルHTTP PUTリクエストの例を示したものです。この種の活動は、サーバーがTomcatの脆弱なバージョンを実行しているかどうかを判断するためのスキャンまたはプローブです。

HTTPのPUTリクエストのスクリーンショットで、HashMapとURLクラスに関連するヘッダーとJavaコードの一部を示している。プライバシー保護のため、一部の情報は編集されています。
図18.CVE-2025-24813を悪用したHTTP PUTリクエスト。

成功した場合、図20のエクスプロイトによって、被害を受けたサーバーは帯域外アプリケーション セキュリティ テスト(OAST)サー バとの接触を試みます。

図19は、Apache Camelの脆弱性CVE-2025-27636を悪用したHTTPリクエストを示したものです。成功すれば、サーバーはechoコマンドを実行します。これは攻撃者がすでにアクセス権を持ち、echoコマンドの結果を見ることができる場合に、Apache Camelを実行しているサーバーをテストする方法です。

Host、User-Agentがcurl/7.61.1、Acceptがany typeに設定されたHTTP GETリクエストのスクリーンショット。一部の情報は編集されている。
図19.CVE-2025-27636に対するApache Camelからの HTTPリクエスト。

図20は、Apache Camelの脆弱性CVE-2025-29891を悪用したHTTPリクエストを示したものです。図20に示したApache Tomcatに対するエクスプロイト攻撃のように、このApache Camelのエクスプロイトは、脆弱なサーバーにOASTサーバーにコンタクトするように要求します。

URLの一部が 「http://」として表示されているGETとPOSTリクエストの例を示すスクリーンショット。情報の一部は消去されている。
図20.CVE-2025-29891に対するApache CamelからのHTTPリクエスト。

実際に発生したCVE-2025-24813のエクスプロイト

脆弱性カバレッジの公開後、Apache Tomcatの脆弱性CVE-2025-24813に対して、7,859 件のエクスプロイト攻撃が確認されています。

このセクションでは、セッション名の長さとContent-Rangeヘッダーの値という2つの観点から、この活動を分析します。

Tomcatセッション名の長さ

以前の分析で述べたように、CVE-2025-24813に対するエクスプロイトは、最初のHTTPリクエストで「.sesson」を付加した名前を使用します。この.sessionファイルには、エクスプロイトが成功した場合に脆弱なホストが実行するコードが含まれています。

これらのセッション名の接頭辞のほとんどは10文字未満であり、実施した遠隔測定から、図21が示すように、最も一般的な接頭辞はセッション名として6文字を使用していることが明らかになりました。

セッション名の文字数を示す棒グラフ。X軸はセッション名のカウントを表し、Y軸は4文字未満から10文字以上までの文字数の範囲を示している。Unit 42とパロアルトネットワークスのロゴがロックされている。
図21.CVE-2025-24813のエクスプロイト攻撃におけるセッション名の長さの傾向。

弊社は6,000件以上の検出で、この6文字というパターンの長さに注目しました。なぜエクスプロイト攻撃の大半で、6文字の文字列のセッション名が使われているのか?このアクティビティ パターンはContent-Rangeヘッダーと関連しています。

Tomcatのコンテンツ範囲ヘッダー

CVE-2025-24813のTomcatソースコード解析で述べたように、Content-RangeのHTTPヘッダーがこの脆弱性の重要な要因となります。図22は、異なるContent-Range値をグループ化したものです。

異なるバイト範囲のカウントを示す横棒グラフで、カテゴリーごとにカウントが異なる。Unit 42とパロアルトネットワークスのロゴがロックされている。
図22.CVE-2025-24813のエクスプロイト攻撃で見られたContent-Range値の傾向。

遠隔測定による6,000件以上の検出で、Content-Range: bytes 0-452/457というヘッダが確認されました。この検出結果は、6文字のセッション名と相関しています。

これら2つの検出結果は、GitHubで利用可能なNucleiスキャナーCVE-2025-24813テンプレートのパターンと一致します。図23は弊社の調査結果との相関を強調したものです。

HTTPセッションとPython変数に関連する行がハイライトされたコードを表示するテキスト エディタのスクリーンショット。3つのセクションは赤枠で強調されていて、それぞれファイル名、PUT、Content-rangeである。
図23.nuclei-templates GitHリポジトリにあるCVE-2025-24813テンプレートのセグメント。

つまり、これまでに見たCVE-2025-24813のスキャンの多くは、Nuclei Scannerを使用していることが分かります。これは理解できるもので、NucleiはMITライセンスで誰でも自由に使えるスキャナーでもあるからです。攻撃者も防御者も、おそらくこのスキャナーとテンプレートを使って脆弱性をチェックしていることが推察されます。

結論

ディレクトリの書き込み(デフォルトでは無効)およびPartial PUT(デフォルトでは有効)を許可するApache Tomcatインスタンスには、CVE-2025-24813の脆弱性があります。特定のコンポーネントを使用するApache Camelインスタンスには、CVE-2025-27636およびCVE-2025-29891の脆弱性があります。

これらの脆弱性には重大な欠陥があるため、重大なセキュリティ リスクが存在しており、攻撃者は特別に細工したHTTPリクエストを通じて、これらを悪用することができます。

このような悪用は、潜在的なリモート コード実行を可能にするだけでなく、データ侵害やネットワーク内での横方向の移動など、より広範な脅威をもたらすものです。この脆弱性をチェックするためにNuclei Scannerを使用することは、スキルの低い敵がこのような脆弱性を容易に利用できることを強調するものであり、早急な対応が重要とされます。

パロアルトネットワークスの保護と緩和策

パロアルトネットワークスのお客様は、以下の製品を通じて、上記の脅威に対する確実な保護を構築いただけます。

  • Advanced Threat Preventionを備えた次世代ファイアウォールのサブスクリプションは、ベストプラクティスに従っている場合、以下のThreat Preventionシグネチャを介して、関連するトラフィックを特定し、ブロックします。96315
  • Cortex Xpanseおよび Cortex XSIAMは、「Tomcat Web Server」アタックサーフェス ルールを使用することで、外部に面したApache Tomcatサーバーを識別できます。脅威レスポンス センターを通じて、影響を受ける可能性のある資産を確認することも可能です。

情報漏えいの可能性がある場合、または緊急の案件がある場合は、Unit 42インシデント レスポンス チームまでご連絡ください。

  • 北米: フリーダイヤル: +1 (866) 486-4842 (866.4.UNIT42)
  • 英国: +44.20.3743.3660
  • ヨーロッパおよび中東: +31.20.299.3130
  • アジア: +65.6983.8730
  • 日本: +81.50.1790.0200
  • オーストラリア: +61.2.4062.7950
  • インド: 00080005045107

パロアルトネットワークスは、本調査結果をサイバー脅威アライアンス(CTA)のメンバーと共有しています。CTAの会員は、この情報を利用して、その顧客に対して迅速に保護を提供し、悪意のあるサイバー アクターを組織的に妨害しています。サイバー脅威アライアンスについて詳細を見る。

侵害のインジケーター

CVE-2025-24813

CVE-2025-24813で確認されたソースIPアドレス

  • 54.193.62[.]84
  • 96.113.95[.]10
  • 209.189.232[.]134
  • 162.241.149[.]101
  • 167.172.67[.]75
  • 100.65.135[.]245
  • 138.197.82[.]147
  • 123.16.159[.]102
  • 193.53.40[.]18
  • 91.208.206[.]203
  • 212.56.34[.]85
  • 195.164.49[.]70
  • 185.91.127[.]9

アクティビティURL - CVE-2025-24813

  • PUT /qdigu/session
  • PUT /UlOLJo.session

ペイロード サンプルのSHA256ハッシュ

  • 6a9a0a3f0763a359737da801a48c7a0a7a75d6fa810418216628891893773540
  • 6b7912e550c66688c65f8cf8651b638defc4dbeabae5f0f6a23fb20d98333f6b

CVE-2025-27636, CVE-2025-29891

送信元IPアドレス(CVE-2025-27636、CVE-2025-29891で確認)

  • 30.153.178[.]49
  • 54.147.173[.]17
  • 54.120.8[.]214
  • 139.87.112[.]169
  • 139.87.112[.]115
  • 64.39.98[.]52
  • 139.87.112[.]98
  • 139.87.113[.]24
  • 64.39.98[.]139
  • 54.96.66[.]57
  • 138.197.82[.]147
  • 22.85.196[.]34
  • 64.39.98[.]245
  • 64.39.98[.]9
  • 54.120.8[.]207
  • 130.212.99[.]156
  • 139.87.112[.]121
  • 139.87.113[.]26

CVE-2025-27636、CVE-2025-29891のアクティビティ ヘッダー

  • CAmelHttpResponseCode
  • CAmelExecCommandExecutable
  • CAmelExecCommandArgs
  • CAmelBeanMethodName

その他の資料

Enlarged Image