話題のPHP脆弱性「PHP2shell」から考える ― 防ぐのが難しい攻撃だからこそ、基本に立ち返る

2026年10月、Webサイトや業務システムで広く使われているPHPに深刻な脆弱性「PHP2shell」が公表され、国内でも複数のWebサービスが緊急メンテナンスに入りました。「自社のサーバーは大丈夫だったのか」「そもそも社内のどこでPHPが動いているのか分からない」と感じた方もいらっしゃるのではないでしょうか。

今回の件で特徴的だったのは、修正プログラム（パッチ）の公開前から攻撃の動きが観測されていた点です。本記事では、PHP2shellの概要を整理したうえで、「パッチが出る前に攻撃される」ことを前提にした備え方を、「把握する」「被害を小さくする」という2つの基本から解説します。

PHPとは、Webサイトやアプリケーションを動かすためのプログラミング言語です。WordPressをはじめとするCMS（コンテンツ管理システム）や、企業の業務システムでも広く利用されています。

IPA（独立行政法人情報処理推進機構）によると、今回報告されたのは、メモリ不足時のエラー処理に起因する脆弱性（CVE-2026-109618）と、リクエスト処理に関連する脆弱性（CVE-2026-109619）の2件です。悪用されると、遠隔の第三者によって任意のコードを実行されるおそれがあり、この2件の組み合わせが「PHP2shell」と呼ばれています。深刻度を示すCVSS（共通脆弱性評価システム）v4.0のスコアは、いずれも9.2とされています。

修正版はPHP 8.2.35／8.3.36／8.4.27／8.5.12として公開されました。一方、PHP 8.1以前はすでにサポート終了を迎えており、公式の修正版は提供されていません。

また、IPAは、PHPがWebアプリケーションだけでなく、ソフトウェア製品やネットワーク機器の内部でも利用されている場合があることにも注意を促しています。自社で構築したWebサイトだけを見ていればよい、というわけではない点に注意が必要です。

今回の経緯を時系列で整理すると、次のとおりです。

10月20日：脆弱性の情報が予定より早く外部に漏えい。PHP開発チームが緊急リリースの事前告知を実施

10月21日：IPAが「事前準備のお願い」を公表。サポート終了版を使い続けるサイトが見受けられること、攻撃がごく短時間で行われるおそれがあることを指摘

10月21日（修正版公開前）：Cloudflare社が初期段階の攻撃活動を観測したと報告

10月21日夜（日本時間）：修正版が公開

修正プログラムが提供される前の脆弱性を突く攻撃を「ゼロデイ攻撃」と呼びます。今回は情報漏えいによって、パッチ公開前に攻撃が始まる、ゼロデイ攻撃に近い状況が生じました。

ここで重要なのは、「パッチが出たらすぐ当てる」という対策だけでは間に合わない時間帯が存在するということです。加えて、サポート終了版を使っている場合は、そもそもパッチが届かない状態が続きます。パッチ適用の重要性は変わりませんが、それだけに頼らない備えが求められています。

攻撃の手口は事前に分からなくても、攻撃を受けたときに困る状況はある程度共通しています。

・どのサーバーが影響を受けるのか、すぐに判断できない

・侵入された場合に、被害がどこまで広がるか分からない

この2点を平時から解消しておくことが、ゼロデイ攻撃やそれに近い攻撃への現実的な備えになります。

今回、IPAは修正版の公開前から、PHPを利用しているプログラムの棚卸しを呼びかけていました。

用途を問わず全台を確認したうえで、「影響するバージョンか」「攻撃が成立する条件があるか」「インターネットから届くか」の3点で優先度を判断することができますが、こうした判断をくだすためには、対象となるサーバーを洗い出せる状態になければなりません。

IT資産管理をしていない状態でなければ、事件のたびに全台を手作業で調べることになり、対応の初動が大きく遅れます。最低限、次の項目は一覧にしておくことをおすすめします。

・サーバー・機器名と用途

・OS、PHPなどのミドルウェアとそのバージョン

・インターネットに公開しているかどうか

・管理担当者や保守委託先

あわせて、古いバージョンを放置しないことも重要です。サポートが終了したバージョンは、今回のような重大な脆弱性が見つかっても公式な修正が受けられません。なお、PHP 8.2も2026年12月31日にサポート終了を迎える予定です。一覧にサポート期限も記載しておけば、更新計画を前倒しで立てやすくなります。

今回の脆弱性が悪用された場合、攻撃者のコードはPHPを実行しているアカウント（Webサーバーの実行ユーザー）の権限で動作するとされています。つまり、その権限で読み書きできるものは、攻撃者にも読み書きできるということです。

たとえば、データベースへの接続情報、クラウドサービスの認証情報、社内の他システムへの通信経路などが、Webサーバー1台を足がかりに狙われる可能性があります。

入られることを前提にするなら、入られた後にできることを減らすのが基本です。

・Webサーバーの実行アカウントに管理者権限を与えない

・データベースのアカウントは、必要な操作だけに権限を限定する

・管理者パスワードの使い回しをやめる

・Webサーバーから社内ネットワークへの通信を、必要なものだけに制限する

攻撃者が不正なプログラム（Webシェルなど）を設置した場合、PHPを更新しても侵入の足場は残り続けます。脆弱性をふさぐことと、侵入後の痕跡を確認することは別の作業です。PHPのプロセスから不審なプログラムが起動していないかなど、侵入後の挙動を監視できる仕組みがあれば、被害の拡大前に対処できます。

IPAは、修正の適用が難しい場合、暫定対策やアクセス制限を検討し、それも難しければ外部からのアクセス遮断やサービスの一時停止を判断するよう呼びかけています。誰が、どの条件で止める判断をするのかを平時に決めておくと、深夜の緊急対応でも迷わずに済みます。

こうした対策には、ソフトウェアのバージョンを一元的に把握できるIT資産管理、侵入後の不審な挙動を検知するEDR、アカウントと権限を一元管理するIDaaS、既知の攻撃通信を入口で遮断するUTMといったカテゴリの製品が有効です。ただし、これらの仕組みは修正プログラムの代わりにはならず、あくまで適用までの時間を稼ぐ手段である点にご留意ください。

PHP2shellのように、パッチの公開前から攻撃が始まるケースでは、「パッチが出たら当てる」だけでは防ぎきれない時間帯が生まれます。だからこそ、「どこで何が動いているかを把握する」「入られても被害を小さくする」という基本が、ゼロデイ攻撃やそれに近い攻撃への備えになります。

貴社の環境に合った対策について、お気軽にご相談ください。

本記事はサイバーセキュリティ対策に関する一般的な情報提供を目的としたものです。自社の規模・環境を考慮した上で、最適な製品をご選定ください。