PHP2Shell（CVE-2026-109618/109619）の影響と対策手順

2026年10月21日、PHP本体の重大な脆弱性「PHP2Shell」の修正版が公開されました。認証なしでリモートからコードを実行でき、修正版の公開前から攻撃が観測されています。AMELAでは、開発・保守を担当しているPHPシステムすべてを対象に、24時間以内のリスク軽減と、できるだけ早い修正版への移行を進めています。本記事では、その対応手順を簡潔にまとめます。

PHP2Shellとは

PHP2Shellは、CVE-2026-109618とCVE-2026-109619の2件の脆弱性の通称です。深刻度はCVSS v4.0で両方とも9.2と評価されています（BleepingComputer）。

押さえておくべき点は3つです。

• アプリより先に攻撃が成立する。 mod_php構成では、ログインしていない1回のリクエストで、アプリのコードが動く前に攻撃が成立します。アプリ側の対策では防げません。
• 影響範囲が広い。 PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedのいずれも対象で、mod_phpが最もリスクの高い構成です。
• 攻撃はすでに始まっている。 Cloudflareは修正版の公開前に攻撃を観測しています。英国NCSCは、すぐに更新できないシステムはオフラインにするよう勧告しています（NCSC）。

対策の全体像

対策は「暫定対策で時間を稼ぎ、修正版のPHPで根本的に解決する」という流れです。暫定対策はすべてのシステムで同じですが、根本対策の方法はPHPのバージョンによって変わります。暫定対策はあくまで時間稼ぎで、脆弱性を取り除けるのは修正済みのPHPだけです。

ステップ1：PHPシステムを洗い出し、優先度を決める

まず、PHPを使っているシステムをすべて洗い出します。WordPressやLP、社内の管理画面も漏れやすいので注意してください。各サーバーで次のコマンドを実行し、PHPのバージョン、動作方式（FPMかmod_phpか）、OSを確認します。

php -v                                   # CLIのバージョン（Webと異なる場合あり）
ps aux | grep -E 'php-fpm|httpd|apache2|lsphp|frankenphp' | grep -v grep
apachectl -M 2>/dev/null | grep -i php   # php_module があれば mod_php
cat /etc/os-release

Webで実際に使われているバージョンは、社内環境に一時的に置いたphpinfo()で確認するのが確実です。確認したら、すぐに削除してください。そのうえで、次の基準で優先度を決めます。

ステップ2：PHPの設定で攻撃経路を塞ぐ

PHPプロジェクトの推奨にもとづき、3つの設定をアプリから上書きできない場所に書き、すべてのワーカーを再起動します（reloadでは不十分です）。変更前に、設定ファイルのバックアップを取ってください。

PHP-FPMの場合は、プールの設定ファイルに書きます。

php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M

mod_phpの場合は、.htaccessではなくvhostまたはhttpd.confに書きます。コンテナの場合は、conf.dの.iniに入れてイメージを再ビルドします。

memory_limit = -1にすると1つのリクエストがメモリを使い切るおそれがあるため、外側で上限を必ず設けます。systemdならMemoryMaxとOOMPolicy=continue、コンテナならメモリ上限、FPMならpm.max_requestsで設定します。あわせて、リクエストごとに適用している無効な設定や非推奨の設定は削除します。display_errorsや@でエラーを隠しても対策にはなりません。

ステップ3：Cloudflare WAFを有効にし、オリジンを閉じる

Cloudflareは、PHP2Shell向けのルールをManaged Rulesetで配信しています。ドメインをCloudflare経由にしてWAFのManaged Rulesetを有効にしたうえで、オリジンサーバーへのHTTP/HTTPSをCloudflareのIPレンジからだけ許可します。この制限がないと、攻撃者はサーバーのIPに直接アクセスしてWAFを迂回できます。SSHのポートを誤って閉じないよう注意してください。設定後、外部からcurl -I http://<オリジンIP>を実行して拒否されること、ドメイン経由では通常どおりアクセスできることを確認します。

ステップ4：侵入の痕跡を確認する

修正版の公開前から攻撃が観測されていたため、P1とP2のシステムは2026年10月20日以降を対象に確認します。確認の前にログを保全してください。

find /var/www -type f -name '*.php' -newermt '2026-10-20' -ls   # 新規・改変されたPHPファイル
dmesg -T | grep -i -E 'segfault|oom'                            # ワーカーのクラッシュ
ps -u www-data -f; crontab -u www-data -l                       # 不審なプロセス・定期実行

アクセスログでは、同じ送信元からの大きなmultipartのPOSTの繰り返しに注意します。痕跡が見つかった場合は通常の手順を中止し、次の対応に切り替えます。

1. サーバーを隔離する。調査のため、削除はしない。
2. DB、APIキー、SSHキーなど、そのサーバーで使える認証情報をすべて変更する。
3. クリーンなソースから、修正版のPHPで環境を作り直す。

ステップ5：バージョン別に根本対策を行う

7.3以下からの移行では、PHPCompatibilityやRectorで互換性を調査し、ステージング環境で回帰テストを行ってから本番に反映します。mod_phpは、この機会にPHP-FPMへ切り替えます。8.2はセキュリティ修正の期限が2026年12月31日のため、移行先には適していません。

対策後の確認

確認は、作業をした人とは別の人が行います。

• Web SAPIのphpinfoで3つの設定値が反映されている（CLIではなく、Local valueの列で確認する）
• ini_setで値を上書きできない
• メモリの上限が有効になっている
• オリジンのIPへ直接アクセスすると拒否され、WAFのログにイベントが記録されている
• ログイン、フォーム、アップロード、決済などの主要機能が通常どおり動く

修正版に移行したあとも、WAFとオリジンの制限は長期の防御層として残します。

まとめ

PHP2Shellへの対応は、すべてのPHPシステムで24時間以内に暫定対策（PHPの設定、WAFとオリジンの制限）と侵入の確認を行い、バージョンに応じて修正版へ移行する、という2段構えです。PHP 7.3以下の古いシステムには修正版がないため、移行計画を早めに決めることが重要です。

AMELAでは、レガシーなPHPシステムの緊急対応から、PHP 8.xへの移行、運用・監視までを支援しています。お困りの際はお問い合わせからご相談ください。運用体制についてはIT運用保守サービスもご覧ください。

参考情報

• BleepingComputer — PHP ships emergency patches for critical PHP2Shell flaws
• PHP Security Advisory GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
• PHP Security Advisory GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
• NCSC — Critical security issue affecting PHP