PHP による CVE-2026-109618 と CVE-2026-109619 の協調リリースは、10月21日14:00 UTC に予定されていました。Next-Gen WAF のテレメトリでは、その9時間以上前に、バグの名前を冠したツールがスキャンを行っていました。リリース時点までに、100を超える送信元 IP が、24種類を超えるツール名で PHP2Shell を冠したツールを使用していました。そのツールの一つは、User-Agent に共通脆弱性識別子を含むエクスプロイトキットでした。

この投稿では、初期のトラフィックの様子、実際の PHP2Shell トラフィックと同時に進行している類似の2つのキャンペーンを見分ける方法、事業で PHP を使用しているアプリケーションへの対処方法を取り上げます。

バグの構造

PHP2Shell は、PHP に存在する2つの重大な脆弱性の通称です。どちらも CVSS スコアは9.2で、認証なしでリモートからコードを実行できる可能性があります：

• CVE-2026-109618：メモリ不足が発生すると、内部リクエストデータの設定が途中の段階で PHP の処理が中断されることがあります。その後のリクエストのクリーンアップ処理では、壊れたデータを信頼してしまいます。

• CVE-2026-109619：内部状態は、その基盤となるメモリがなくなった後も残ることがあり、同じワーカーで後続のリクエストがその状態を引き継ぎます。

PHP2shell を検出しようとする場合、一致判定に使えるペイロードの文字列は存在しない点に注意が必要です。悪用されるのは特定の条件です。リクエストを、失敗してはならないタイミングで失敗させます。 

PHP によると、Web リクエストを処理するすべての PHP インストール環境がリスクにさらされています。PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed も対象です。PHP は、その中でも mod_php のリスクを最も高く評価しています。

修正済みのリリースは 8.5.12、8.4.27、8.3.36、8.2.35 です。PHP 8.1 以前には、アップストリームから修正が提供されません。

タイムライン

情報公開の経緯と PHP2shell ツールが登場した時期。時刻はすべて UTC。情報公開に関する出来事は、PHP Foundation の事後報告と GitHub のアドバイザリ記録に記載されたとおりです。

PHP2shell に関する CVE の ID（2026-109618 & 109619）は技術的な詳細を伴わずに流出し、エクスプロイト動画の約8時間後には、PHP2shell という名前のツールが当社のテレメトリで確認されました。最初に確認した名前付きツールと、最初に確認したエクスプロイトキットは、どちらもパッチ適用済みイメージの早期リリースより前に登場しました。個々のツールが何をきっかけに登場したかについては推測しません。しかし、調整されたリリースが行われた時点で、スキャンはすでにかなり進んでいました。

干し草の山

名前に PHP2shell を含む最初のツールが登場してから10月22日の正午までに、同様の名前を持つツールからのリクエストを約250,000件保存しました。送信元は約3,200の公開 IP アドレスでした。

もちろん、すべてのスキャナーが攻撃を目的として動作しているわけではありません。そのトラフィックの約3分の1は、防御目的だと自己申告しています："認可を受けた露出状況の確認"、"パッチ適用状況の確認"、"悪用を伴わない"。多くの組織が自社の環境を確認しており、これは望ましいことです。自己申告のラベルに裏付けはありませんが、リクエストが行う小規模で無害な探査とは一致しています。

名前に PHP2shell を含むツールからのリクエスト数、ツールの種類別（10月21日03:59 UTC～10月22日正午、端数処理済み）。 

それ以外はさまざまなものが混在し、動きも速いものでした。PHP のバージョンを調査するツールの1つは、約11時間でバージョン4.0から7.2に更新されました。

これほど速く変更を繰り返すツールによって、User-Agent 文字列に基づくシグネチャは1日以内に失効済みとなります。

針

これまでのところ、実際のエクスプロイトトラフィックをそれ以外のトラフィックと区別するうえで最も信頼できる手がかりは、マルチパートの境界文字列です。見つかったエクスプロイトキットはどれも、Content-Type ヘッダーに固定の境界文字列、または一定のパターンを持つ境界文字列を使用しています。この方法で、候補となるキットを10種類以上特定しました。そのうち5種類は、名前、User-Agent、または動作から、PHP2shellとの直接的な関連が確認できました。

最も広く使われているツールキットは以下のとおりです：

• POST /index.php（または /）、User-Agent php2shell-109618

• Content-Type: multipart/form-data; boundary=B7kQpoc618

• 固定サイズのマルチパートボディと最小限のヘッダーセット

また、ホスト名ではなく生の IP アドレスを宛先とし、ホストごとに1～2件のリクエストを送信します。これは特定のサイトを標的とした攻撃キャンペーンではなく、IP アドレス空間に対する大規模なスキャンです。 

ボディのサイズはキットごとに大きく異なるため、このトラフィックを見つける際はサイズのしきい値だけに頼らないでください。

最初に除外すべき2つの類似ケース

自身のログで PHP2shell を探す際には、別の2つのキャンペーンが判別の妨げになります。

React2Shell (CVE-2025-55182)。PHP2shell のシグネチャとして出回っているものには、Content-Length のないチャンク化されたマルチパートリクエストと、A の文字列を長く連続させてパディングしたボディの2つがあります。計測した1時間では、それぞれのシグネチャに一致したものの98.6％と99.9％を React2Shell が占めていました。リリース前日の時点で、パディングのシグネチャに一致したものはすでにほぼすべて React2Shell でした。React2Shell は、/xmlrpc.php や /wp-login.php を含むあらゆるパスにリクエストを大量送信します。簡単な見分け方は、Next-Action リクエストヘッダーの有無です。Next.js サーバー Actions はこのヘッダーを使用しますが、PHP は使用しません。

10月21日21:00～22:00 UTC に PHP エンドポイントへの POST リクエストの Next-Action ヘッダーを基に測定した、出回っている各 "PHP2shell" シグネチャのうち実際には React2Shell であるものの割合。リリース前日の同じ時間帯：パディングのシグネチャのうち、すでに99.7％がReact2Shell でした。

wp2shell。これはまったく別の脆弱性で、2026年7月に公表された、WordPress コアで認証なしにリモートコードを実行できる脆弱性です。このエクスプロイトキットは、WordPress の index.php にサイズの大きいマルチパートのボディを送信し、その際、----wp2shell で始まるバウンダリーを使用します。このキットは PHP2shell の公開よりずっと前から活動していました。そのため、これを集計に含めると、実際には存在しない「公開前からの php2shell の活動」という話を作り出すことになります。

両方に共通する教訓は、リクエストの形状に基づくシグネチャが示すのは攻撃者ではなく、リクエストの種類だということです。公表前のベースラインと比較し、増加分があれば、識別に使えるヘッダーや境界で分けてから、その発生源を判断してください。

エッジから見えるもの、見えないもの

エッジではエクスプロイトの試行は確認できますが、成功したかどうかは確認できません。PHP2shell は PHP ワーカーをクラッシュさせたり破損させたりすることで動作するため、成功した試行と失敗した試行が外部からは同じように見えることがあります。標的になったと思われる場合、確認に必要な情報はオリジンにあります：

• PHP-FPM のエラーログ

• ワーカーのクラッシュを示す Apache のエラーログ（例：AH00051 の "child pid … exit signal" エントリ）

• コネクトバックシェルはオリジンから外部への通信を伴うため、PHP ワーカーからの予期しない外向き接続

PHP2Shell が示す AI の実態

AI が脆弱性の発見に役立つことは確かで、その速度は以前よりもはるかに速くなっています。最初のツールが登場してから約1日で、約3,200の IP アドレスから、名前の付いたツールが数十種類使われていることを確認しました。また、あるツールは約11時間でバージョン4.0から7.2になりました。 

それらのいずれかが AI を使って書かれたかどうかは、断定できません。一方、観測できるトラフィック自体はありふれたものです。キットは生の IP アドレス宛てに固定のマルチパートボディを送信し、ホストごとに1～2件のリクエストを送ります。送信元は、多くのスキャンで使われるのと同種の VPN やホスティングのインフラストラクチャです。AI による支援の程度にかかわらず、脅威の範囲は拡大し、その動きは速まっています。

そして今のところ、防御を主に担っているのは依然として人間です。防御側は自分たちのシステムを確認し、トラフィックにラベルを付けました。ハンターが共有したシグネチャは、ほぼすべて別の攻撃キャンペーンに関するものと判明しました。パッチ適用、ベースラインの設定、オリジンログの精査は、AI の支援があっても、依然として大部分を人が担う作業です。適切な場所に適切な多層防御を配置する戦略を、人が考える必要があります。

今必要な対応

1. パッチを適用してください。8.5.12、8.4.27、8.3.36、8.2.35 のいずれか、またはお使いのディストリビューションが提供するパッチ適用済みパッケージにアップグレードしてください。8.1 以前を使用している場合は、バックポートについてパッケージの配布元に問い合わせるか、アップグレードしてください。

2. 誤った手がかりを追わない。脅威を探す際、User-Agent、IP アドレス、ボディのサイズはいずれも判断を誤らせる可能性があります。本当の手がかりは、マルチパートのバウンダリー文字列にあります。

3. React2Shell と wp2shell に該当しないことを確認してから、PHP2shell として集計してください。

4. IP ブロックリストの扱いに注意。この脆弱性について出回っているリストには、通常のトラフィックが流れる VPN や Tor の出口ノード、住宅回線やモバイル回線の IP アドレスが複数含まれています。ブロックすると、実際のユーザーに悪影響が及びます。

5. Fastly Next-Gen WAF をご利用のお客様：Next-Gen WAF で保護されているアプリケーションについては、CVE-2026-109618 と CVE-2026-109619 の両方を対象とするシグナルをオプトインで有効にしてください。これは、悪用を示す構造的な兆候を検出し、仮想パッチとして機能する、CVE 固有の Templated Rule です。詳しくは、プロアクティブな保護に関する Fastly の投稿をご覧ください。
   

注：以下に示す Workspace 設定内の Automatic 共通脆弱性識別子 Virtual Patching の切り替え設定もご検討ください。

指標

今回の測定方法

これらの数値は、2026年10月20日～2026年10月22日の Fastly Next-Gen WAF のリクエストテレメトリに基づいています。情報公開の時期は、PHP Foundation の事後報告と GitHub のアドバイザリー記録に基づいています。これらの件数は下限値です。報告できるのは、Fastly の WAF が検知して記録したリクエストに限られます。また、ヘッダーに関する一部の数値は、終日分ではなく、対応するサンプル時間帯のデータに基づいています。

最新の情報については、PHP の重大な RCE 脆弱性「PHP2Shell」（CVE-2026-109618 および CVE-2026-109619）に対する Fastly のプロアクティブな保護をご覧ください。