PHP2Shellが最後ではない。次の脆弱性が最初に現れる場所

10月17日、Amazonのハニーポットネットワークが、匿名化されたIPアドレスからのPHP2Shell悪用の試みを記録しました。しかし、一般公開までにはまだ4日ありました。

10月21日にPHPの修正が公開された時点で、技術的な詳細はすでに漏えいし、概念実証（PoC）エクスプロイトが広く出回り、各所で悪用の試みが記録されていました。問題となったのは、PHPエンジン自体に認証不要の重大なリモートコード実行脆弱性が2件存在したことです（CVE-2026-109618およびCVE-2026-109619、いずれもCVSS v4.0で9.2）。これが、現在PHP2Shellとして知られているものです。

Snykのセキュリティリサーチチームが何が起きたのか、何をすべきかを解説しました。移行すべきリリース、アップデートできるまでのリスクを軽減する緩和策、そしてSnykプラットフォームの各機能が問題をどのように捉えるかを紹介しています。

この記事では、セキュリティリサーチチームの解説の続きをお届けします。今回の対応から何を学べるのか、こうした露出がどこにあり、どこから生じるのか、迅速な対応が数か月前からの取り組みに左右されるのはなぜか、そして次の脆弱性がすでに迫っているのはなぜかを考えます。

コードに問題がないチームにとっても、PHP2Shellが脅威となったのはなぜでしょうか？

それは、脆弱性がコードより下の層に存在するためです。どういうことでしょうか？該当する2件のCVEは、PHPエンジンのリクエスト処理の過程で発生するため、アプリケーションコードが実行される前に到達可能です。Apacheでmod_phpを使っている場合、悪用に必要なのは認証なしのリクエスト1件だけでした。

少し考えてみてください。丁寧なレビュー、問題のないコード、きちんと整った依存関係ツリーがあったとしても、それらはすべて実際の問題より上の層にあります。各チームがまず直面したのは、PHPがどこでリクエストに応答しているのか、そしてその場で悪用される可能性があるのか、という問いでした。

問われていたのは、稼働中のアプリケーションについてです。攻撃者が必ず最初に確認するのも、まさに同じことです。

PHPがどこで稼働しているかを把握できるインベントリとは？

インベントリの種類ごとに、把握できるのはその一部です。

PHPはDockerfile、ディストリビューションのパッケージ、プラットフォームイメージ、または手動のインストールを通じて本番環境に導入されます。composer.jsonの"php": ">=8.2"という制約からわかるのは、アプリケーションが受け入れるバージョンです。実際にデプロイされるバージョンは、どの方法でインストールしたかによって異なります。コンテナスキャンは、各ディストリビューションがアドバイザリを公開すると、ディストリビューションのパッケージからインストールされたPHPを検出します。一方、ソースからコンパイルされたPHP（公式PHP Dockerイメージを含む）は、この対象に含まれません。（改めて、セキュリティリサーチチームの記事では、Snykの各ビューがこの実態のどの部分を捉えるかを正確に示しています。）

バージョン文字列の問題もあります。VirusTotalは、PHPを実行している約510万件のIPアドレスをフィンガープリントで特定していますが、そのうちバージョンを公開しているのは約110万件にすぎません。つまり、およそ5件中4件はバージョンを隠しています。この問題について、私たちが読んだ中でも特に明快な要約は次のとおりです。「バージョン文字列だけを探すなら、自ら情報を明かしている問題の一部しか見えません。」

内部から見える情報と、外部から実際に応答しているものとの隔たりに、真のリスクが潜んでいます。攻撃者はURLを狙います。PHP2Shellはその典型例です。これを探る者は、必ず同じ問いを投げかけます。このURLでPHPは応答するのか？

外部から見た対応はどのようなものだったのでしょうか？

先手を打てた理由は、10月21日14:00 UTCのPHPのリリースより前に、Snykが両方のCVEについてアドバイザリを公開していたことです。そのため、監視対象のプロジェクトでは修正版が判明した時点で検出できました。リリースから約30分以内に、アドバイザリには影響を受けるバージョン範囲と修正版が掲載され、各ディストリビューションのアドバイザリも公開に合わせて続きました。これにより、Snyk ContainerとUnmanagedスキャンで把握できる範囲をカバーしました。

Snyk API & Webでは、次の3つの問いに答えました。

1. PHPはどこで稼働しているのか？ Discoveryは、ドメイン上のアセットを列挙し、その技術スタックをフィンガープリントで特定します。TechフィルターでPHPを選択すると、PHPが検出されたすべてのホストとエンドポイントが、リスク評価、スコア、最終確認日とともに表示されます。バージョン番号は後から、各ホスト自体から取得します。セキュリティリサーチチームの言葉を借りれば、パッチを適用するには、まず一覧が必要です。

2. 悪用される可能性はあるのか？PHPのリリースから24時間以内に、フルスキャンプロファイルでPHP2Shellのテストが可能になりました。チームはこのチェックをカスタムプロファイルとして実行し、すべてのPHP対象について迅速に状況を確認できました。

3. 修正は有効だったのか？パッチ適用後に同じカスタムプロファイルを再実行し、ディストリビューションのアドバイザリまたはパッチレベルと照らし合わせます。パッチ適用済みのディストリビューションビルドでも、バージョン番号が古いままの場合があるためです。

つまり、Discovery --> 対象を絞ったチェック --> パッチ適用 --> 再テストです。時間との勝負が数時間単位になった今、プローブし、観察し、判断することが求められます。そして、こここそが最も懸念すべき点であり、私たちが最も重視していることです。すでにSnyk API & Webを利用しているチームは、10月21日より前に難しい準備を終えていました。ドメインがマッピングされ、アプリケーションがターゲットとして設定済みだったのです。チェックが利用可能になると、フィルターをかけてすばやくスキャンするだけで対応できました。

継続的な外部視点のテストがもたらす大きな価値のひとつは、初日に必要となる対応のための準備を、その数か月前から済ませられることです。

PHP2Shellを外部から検出できるなら、難しかったのは何でしょうか？

時間です。

5月、私たちはCOSの基盤となる違いを説明しました。ヒューリスティックで検出できる脆弱性は、決定論的なツールで発見できます。稼働中のアプリケーションやAPIにペイロードを送り、応答を観察して推測するのです。一方、コンテキスト依存の脆弱性（BOLA、テナント間の情報漏えい、ビジネスロジックの連鎖）には、決まったシグネチャがありません。アプリケーションが本来行うべきことと、実際の動作との隔たりに潜んでいるためです。

存在が判明した後、PHP2Shellは外部からテスト可能になりました。つまり、ヒューリスティックで検出できる脆弱性の最初のカテゴリに明確に当てはまります。難しかったのは、制約となっていたのは、脆弱性の公表から、公開しているすべての対象でチェックを実行できるようになるまでの隔たりです。その間は攻撃者が悪用できる時間となり、今回は公表の4日前にその時間が始まりました。

脆弱性の情報は、その後も更新されました。10月23日、PHPプロジェクトは部分的な回避策（CVE-2026-115560）について説明しました。これは、アップロードの進行状況が有効な状態で、セッション開始前にアプリケーションがini_set()でセッションのシリアライズハンドラーを切り替える場合に適用されます。発生条件はまれですが、水曜日に出した結論も、金曜日には再確認が必要でした。ある時点での回答は、数日で古くなります。

なぜPHP2Shellが最後ではないのでしょうか？

その理由は3つあります。発見の経緯に由来するものです。

1. AIの支援を受けて発見されたからです。ウェブを30年間支えてきたエンジンでのことです。セキュリティリサーチチームはこう端的に述べています。「LLMとエージェントの時代になっても、サーバーは今なお稼働し続けています。」そして、今回の脆弱性を発見した種類のモデルは、今や攻撃者も手にしています。

2. 発見の頻度が高まっています。SnykのCTO兼最高イノベーション責任者であるManoj Nairは、9月にこう説明しました。「AIが広く使われているソフトウェアから見つけ出す、こうした深刻な欠陥。かつては年に1、2回しかなく、誰もの四半期計画を覆すような発見が、私の見る限り、今では週に何度も起きています。」

3. 対応までの時間が大幅に短くなっています。Amazon Integrated SecurityのCISOであるCJ Mosesは、PHP2Shellから得られる、ほかの事例にも当てはまる2つの教訓を示しました。防御側は「一般公開日が、悪用が始まる最も早い日だと思い込んではいけません。」また、「パッチ公開からエクスプロイトが実用化されるまでの時間は、構造的な理由で縮まっています。」AIを活用した分析によって、パッチの差分やアドバイザリから実用的なエクスプロイトを作るコストが下がっているためです。インターネットに公開されたシステムにおける重大な脆弱性について、彼はこう助言しています。「パッチ適用と緩和策の期間は、時間単位で測るべきです。」

次の脆弱性に備えるには、何が必要でしょうか？

製品名を除けば、必要なのは4つの特性です。どのアプローチについても、この特性を基準に評価してください（私たちのものも例外ではありません）。製品名ではなく、4つの特性に注目してください。どのアプローチも、この基準で評価すべきです（もちろん、私たちのものも含みます）。

1. アドバイザリの公開前から存在するインベントリ。外部から把握して常に最新に保つことで、新たな情報が公開されたらすぐにフィルターで絞り込めます。

2. 数時間以内に利用できるチェック。アドバイザリの公開からテスト実行までの時間が、攻撃者にとっての隙になります。その時間を測定しましょう。

3. 必要なときに実施できる再テスト。同じ対象に絞ったチェックを、修正が有効だと確認できるまで繰り返します。

4. シグネチャに頼らないテスト。ヒューリスティックで検出できるのは、すでに誰かが説明した問題です。それ以外には推論が必要です。アプリケーションが本来どう動作するべきかを見極め、期待される動作と実際の動作との隔たりを探るテストが求められます。

Snykが提供する機能に当てはめると、次のようになります。

Snyk API & Webは、Discovery、脆弱性の公開に応じてチームが最新に保つエンジン、そして実行と再実行が可能な対象特化型プロファイルという、最初の3つを担います。Continuous Offensive Securityは4つ目を加えます。AI Pentestingはペンテスターのようにアプリケーションについて推論し、Agent Red Teamingは偵察によってスタック内のLLMを検知すると直ちに動き出します。また、Snyk API & WebのエンジンであるDynamic Testingが、ヒューリスティックで検出できる脆弱性を継続的にカバーします。プラットフォームの用語では、これがValidateです。アプリケーションを継続的に攻撃し、修正が有効になったことを証明するとともに、まだ悪用可能な問題を明らかにします。

そして、セキュリティ態勢の問題があります。10月14日のThe AI Security Panel: UnfilteredでManojが投げかけたのは、私たちが何度も立ち返る問いでした。「自律型の攻撃者があなたを攻撃するなら、なぜ自分自身を攻撃しないのでしょうか？」この問いこそがCOSの前提です。私たちが取り組んでいるのは、この一連の流れにあるすべての隔たりを縮めることです。アドバイザリの公開からチェックの実行まで、そしてチェックから修正の確認までをつなぎます。

次の脆弱性は、まずどこに現れるでしょうか？

どのエンジンが、いつ影響を受けるかは誰にもわかりません。最初にどこで現れるかは、より予測しやすいでしょう。あなたのURLです。テストは、すでにその場所で行われているべきです。

今、あなたのURLで攻撃者に何が見えるか確認しませんか？Evo Continuous Offensive Securityのデモを予約して、外部から攻撃対象領域をマッピングし、検出結果のうち何が悪用可能かを実証し、修正が有効になるまで再テストする方法をご覧ください。