2026年10月21日、PHP本体に見つかった重大な脆弱性「PHP2Shell」の修正版が公開されました。ログイン不要で外部からサーバー上のプログラムを実行される恐れがあり、修正版の公開前から攻撃が観測されています。AMELAでは、開発・保守を担当しているPHPシステムを対象に、24時間以内のリスク軽減と、修正版への早期移行を進めています。本記事では、PHPで動くシステムを持つ企業が「いつまでに、何を判断すべきか」を、その対応手順をもとにまとめます。
PHP2Shellとは何か
PHP2Shellは、CVE-2026-109618とCVE-2026-109619という2件の脆弱性の通称です。深刻度はCVSS v4.0で両方とも9.2と評価されています（BleepingComputer）。どちらも、リクエストが異常な形で終わったときにPHPがメモリを壊れた状態のまま残し、攻撃者がそれを足がかりにプログラムを実行できる、という種類の欠陥です。
経営やシステム管理の立場から押さえておきたいのは、次の3点です。
- アプリケーション側では防げない。 攻撃は、Webアプリケーションのコードが動く前の段階で成立します。ログイン機能や入力チェックがしっかりしていても、それだけでは守れません。
- 対象が広い。 Webサイトや業務システムでPHPを使っていれば、構成を問わずほぼすべてが対象です。WordPressや各種CMSも含まれます。
- 攻撃はすでに始まっている。 Cloudflareは修正版の公開前に攻撃を観測しています。英国の国家サイバーセキュリティセンター（NCSC）は、すぐに更新できないシステムはオフラインにするよう勧告しています（NCSC）。
対策の考え方——「時間を稼ぐ対策」と「根本対策」を分ける
PHP2Shellへの対応は、2つの段階に分けて考えると判断しやすくなります。1つは、修正版に移行するまでの間に攻撃を受けにくくする「暫定対策」です。もう1つは、脆弱性そのものを取り除く「根本対策」、つまり修正版のPHPへの移行です。
重要なのは、暫定対策はあくまで時間稼ぎだという点です。PHPプロジェクト自身も、暫定対策では完全には防げないと明言しています。暫定対策を入れたことで安心して移行を先送りにしてしまうのが、最も避けたい失敗です。
ステップ1：対象システムを洗い出し、優先順位を決める
最初にやるべきことは、自社でPHPが動いているシステムをすべて把握することです。主要な業務システムだけでなく、キャンペーン用のLP、WordPressで作った採用サイト、社内向けの管理画面など、見落としやすいものまで含めて洗い出します。システムごとに、PHPのバージョン、インターネットに公開されているか、個人情報や決済情報を扱うかを確認します。
そのうえで、次の基準で優先順位を決めます。インターネットに公開されていて、古いPHP（8.1以下）で動いているもの、または個人情報や決済を扱うものが最優先です。こうしたシステムは24時間以内に暫定対策を入れ、1週間以内に移行計画を決めます。公開されていても新しいPHP（8.2以上）であれば、暫定対策と並行して48時間以内に修正版へ更新します。社内やVPNからしか使えないシステムは、3日以内の暫定対策と、次回の定期メンテナンスでの更新が目安です。金融や医療など、業界によってはさらに厳しい期限が必要になります。
ステップ2：当日中に暫定対策を入れる
暫定対策は、2つの層を重ねて行います。
1つ目は、PHPの設定変更です。PHPプロジェクトは、攻撃の入口となる機能（セッションのアップロード進捗機能）を無効にすることと、メモリやリクエストサイズに関する設定を見直すことを推奨しています。設定はアプリケーション側から上書きできない場所に書き、変更後はPHPのプロセスをすべて再起動する必要があります。メモリの上限を外す設定を含むため、サーバー側でメモリの使用量に上限を設けることも欠かせません。具体的な設定値は、PHPの公式アドバイザリー（本記事末尾の参考情報）を確認してください。
2つ目は、WAF（Webアプリケーションファイアウォール）による防御です。CloudflareはPHP2Shellの既知の攻撃パターンを遮断するルールを提供しています。ただし、WAFが守れるのはWAFを経由した通信だけです。サーバーのIPアドレスに直接アクセスされると、WAFは素通りされてしまいます。そのため、WAFの有効化とあわせて、サーバー側ではCloudflare経由の通信だけを受け付けるよう制限します。この「オリジンの制限」がない状態では、WAFの効果は限定的です。
ステップ3：侵入された痕跡がないかを確認する
攻撃は修正版の公開前から始まっていたため、「これから守る」だけでは不十分です。インターネットに公開しているシステムでは、2026年10月20日以降を対象に、すでに侵入されていないかを確認します。確認するのは、Webサーバー上に覚えのないファイルが作られたり書き換えられたりしていないか、不審なプロセスや定期実行の設定がないか、アクセスログに不自然な大量のリクエストがないか、といった点です。確認の前に、証拠となるログを保全しておくことも大切です。
痕跡が見つかった場合は、通常の対策手順を中断し、インシデント対応に切り替えます。サーバーを隔離し（調査のため削除はしません）、データベースのパスワードやAPIキーなど、そのサーバーから使える認証情報をすべて変更し、クリーンな状態から環境を作り直します。個人情報が漏えいした可能性がある場合は、法令にもとづく報告が必要になることもあります。
ステップ4：PHPのバージョンに応じて根本対策を行う
根本対策の方法は、使っているPHPのバージョンによって大きく変わります。
| PHPのバージョン | 根本対策 |
|---|---|
| 8.2〜8.5 | 修正版（8.2.35／8.3.36／8.4.27／8.5.12）へ更新 |
| 7.4〜8.1 | OSベンダー等の修正パッケージを利用し、並行して移行を計画 |
| 7.3以下 | 修正版なし。暫定対策を続けながら8.3／8.4へ移行 |
PHP 8.2以上であれば、同じバージョン系列の中での更新なので、影響は比較的小さく、短期間で対応できます。一方で、7.3以下の古いPHPには修正版が提供されていません。暫定対策でしのぎながら、PHP 8.3または8.4への移行を進めるしかありません。8.2はセキュリティ修正の期限が2026年12月31日で切れるため、移行先には適していません。
古いPHPからの移行は、フレームワークやライブラリの対応状況を調べ、検証環境で十分にテストしてから本番に反映する必要があり、一定の期間がかかります。だからこそ、暫定対策を入れたその日のうちに、移行の見積もりとスケジュールを決めることが重要です。
対策が効いているかを確認する
対策は、入れただけで終わりにせず、実際に効いているかを確認します。設定が本番環境に反映されているか、アプリケーション側から設定を変えられないか、サーバーに直接アクセスすると拒否されるか、WAFが攻撃を記録しているか、そしてログインやお問い合わせフォーム、ファイルのアップロードなどの主要な機能が通常どおり動くかを確かめます。AMELAでは、作業した担当者とは別の担当者がこの確認を行うことにしています。
修正版に移行したあとも、WAFとオリジンの制限は残しておきます。今回のような「修正版より先に攻撃が始まる」脆弱性に、次も備えるためです。
まとめ
PHP2Shellは、認証なしで、しかもアプリケーションより先に攻撃が成立する、PHP本体の脆弱性です。PHPで動くシステムを持つ企業は、対象システムを洗い出したうえで、24時間以内に暫定対策（PHPの設定変更、WAFとオリジンの制限）と侵入の確認を行い、バージョンに応じて修正版へ移行する必要があります。特に古いPHPには修正版がないため、移行計画を早めに決めることが何よりも重要です。
AMELAでは、古いPHPシステムの緊急対応から、PHP 8系への移行、移行後の運用・監視までを一貫して支援しています。対応にお困りの際は、お問い合わせからお気軽にご相談ください。システム運用の体制づくりについては、IT運用保守サービスもご覧ください。
