10月20日、PHPの2つの重大な脆弱性の詳細が、修正プログラムの準備が整う前にオンライン上で流出した。 ウェブの大部分を支えるスクリプト言語であるPHPは、パッチのリリースを1日繰り上げ、10月21日に公開した。これらの脆弱性（CVE-2026-109618およびCVE-2026-109619、通称「php2shell」）により、攻撃者はログインを必要とせずに、PHP自体を通じてWebサーバー上でコマンドを実行することが可能となる。
今すぐパッチを適用しましょう。そのアドバイスは正しいのですが、そこには抜け穴があります。この投稿では、その抜け穴について解説します。
修正パッチが公開される前から、攻撃者たちはこの脆弱性を悪用するテストを行っていた
PHP 8.2 から 8.5 向けの修正プログラムが公開されており、PHP プロジェクト側は、PHP 8.1 以前のバージョンには更新が提供されないとしている。ある推計によると、現在も稼働中の該当サーバーは約 884,000 台に上るとされており、これは単一の情報源に基づく概算値である。
Amazonのハニーポット（ 攻撃者を誘き寄せるために設置されたおとりサーバー）は 、この脆弱性が公表される4日前の10月17日に最初の攻撃試みを記録しており、10月21日までにAmazonはこの脆弱性が広く悪用されていると説明した。Cloudflareも早期の攻撃を確認しており、英国国立サイバーセキュリティセンター（NCSC）は各組織に対し、 直ちに更新を行うか 、システムをオフラインにするよう警告した 。実際に何台のサーバーが乗っ取られたかは、依然として不明である。 Amazonは、ハニーポット以外で同様の攻撃が成功したかどうかは不明であると述べている。
どんな欠点も、誰かが公表するずっと前からすでに世間に知れ渡っているものだ
脆弱性は、発生した日ではなく、公表された日にニュースとなる。PHPのメンテナンス担当者は、2024年の監査でこの問題の兆候を最初に発見したが、一般の人々が知る前に、攻撃者たちがすでにその脆弱性を悪用していた。
このようなパターンは以前にも見られました。2021年12月にLog4jの脆弱性が発覚した際、Vectra社は、攻撃の最初の兆候を見抜くのは困難であり、環境内の少なくとも1台のサーバーはすでに侵害されていると想定するのが最も安全であると指摘していました。現在、貴社が運用しているソフトウェアの他の脆弱性も、おそらく同様の状況にあるでしょう。つまり、誰かには知られているものの、公には発表されていないのです。パッチ適用は、公表された脆弱性に対処するものです。それ以外の脆弱性に対しては、何の役にも立ちません。
見落としているPHPサーバーこそが最も重要だ
PHPは、WordPress、Drupal、Joomla、Magentoのサイトや、ホスティングコントロールパネル、そしてPHPの名が一切出てこない多くのソフトウェアを動作させています。あなたが知っているサーバーにはパッチが適用されますが、あなたが知らないサーバーこそが、誰も監視していないため、攻撃者に真っ先に狙われるのです。
修正プログラムがリリースされた当日に、すべての問題を修正できるチームなどありません。どのサーバーがインターネットに公開されており、どのサーバーに最も重要なデータが保存されているかを把握しておけば、未解決の問題リストを、修正が完了するまで停止すべきサービスを含む、少数の優先事項に絞り込むことができます。攻撃を受けた疑いのあるサーバーについては、再起動前にログとメモリのスナップショットを保存してください。再起動すると痕跡が消えてしまうからです。
PHPサーバーがダウンした後はどうなるのか
PHPを通じてコードを実行できるようになった攻撃者は、通常、malware を必要としません。Webサーバーにはすでにシェル、ネットワーク接続、ファイルへのアクセス権があるため、攻撃者はマシンにすでにインストールされているツールを使ってシステム内を調査し、認証情報を見つけ出し、あるシステムから別のシステムへと移動することができます。Webサーバーは、わずかに異なるコマンドでWebサーバーとしての動作を行っているだけなので、一見して異常は見られません。これが、私が取り上げる3つの検知の抜け穴のうちの最初のものであり、つまり「一見して異常が見られない」という点です。
変化するのは、サーバーが通信する先です。何年も同じページを提供してきたWebサーバーが、突然、これまで接続したことのない場所にアクセスしたり、見慣れないアドレスにリクエストを送信したり、内部システムとの通信を開始したりすることがあります。こうした動作は、パッチの適用状況ではなく、ネットワークトラフィックに現れます。ネットワークを監視することで、サーバー自体を誰かが監視しているかどうかに関わらず、サーバーが実際にどこに接続しているかを確認することができます。
Vectra AIが見ることができるものと、見ることができないもの
Vectra AIは、最初の攻撃ベクトルが何であるかについては、それほど重視していません。私たちが注目しているのは、その後に何が起こるかということです。
今日の話題はPHPです。来週はまた別の話題になるでしょう。新たな脆弱性、ヘルプデスクへの電話、内部関係者などです。私たちが注目する点は、どの侵入経路が使われたかには依存しません。私たちは、攻撃者がシステム内に侵入した後にシステムがどのような動作をするかを監視するため、侵入経路が判明していたり、脆弱性が公表されていたりする必要はありません。これは、侵入経路が不明である場合や、脆弱性がまだ公表されていない場合に特に重要です。
潜在的なPHPサーバーとシャドーITの特定
PHPインフラのセキュリティを確保する上での課題の一つは、そもそもそれがどこにあるのかを把握することです。忘れ去られたアプリケーション、管理されていないサーバー、そしてシャドーITは、既知の脆弱性に対するパッチが適用された後であっても、セキュリティ上の死角を生み出す可能性があります。
Vectra AIのPHPサーバー可視化ダッシュボード セキュリティチームが、暗号化されていないHTTPトラフィックで観測された指標（例：）などを活用して、見落とされがちなPHPサーバーを特定するのに役立つ、新たな調査ツールを提供します。 .php エンドポイントおよび PHPSESSID クッキー。これにより、アナリストはこれらのホストが外部から発信された暗号化トラフィックも受信しているかどうかを調査でき、さらなる調査が必要な、潜在的に侵害されている可能性のあるシステムの優先順位付けに役立ちます。
このダッシュボードは、PHPサーバーの完全な一覧を提供することを目的としたものではありません。観察可能なPHP関連の指標を示すシステムを特定することしかできず、暗号化されたトラフィックやネットワーク可視性の制限により、一部のサーバーが検出されない可能性があります。その代わり、このダッシュボードは、既存の資産発見および脅威ハンティングのワークフローを支援するツールとして機能し、アナリストが潜在的なシャドーITを明らかにしたり、リスクの程度を調査したり、パッチ適用後もさらに詳細な調査が必要なシステムを特定したりするのを支援します。
セキュリティ侵害を受けたPHPサーバーが明らかにする、組織の回復力について
かつての成功の尺度は、攻撃者が侵入できたかどうかでした。より優れた指標は、攻撃者がどこまで侵入できたかということです。パッチの適用、適切なネットワーク設計、ネットワークのゾーン分け、最小権限の原則、そして最も重要なビジネスプロセスを担うシステムを把握しておくこと――これらすべてが、攻撃者の侵入範囲を制限します。ネットワークの記録からは、ドアが閉まる前に誰かが侵入したかどうか、そしてその人物が次にどこへ向かったのかを確認することができます。
ホワイトペーパー『AIを活用した攻撃の時代における「ギャップ」への注意』では、これら3つのギャップについて、その全容が詳しく解説されています。