この記事は2026年10月21日19時10分（日本時間）時点の情報です。
PHPの修正版は同日23時に公開される予定です。
影響バージョンと修正版が公式発表された後に追記します。
PHP開発チームが、重大な脆弱性2件を修正する緊急リリースを予告しました。
どちらもCVSS v4.0で9.2と評価されています。
ネット上では「php2shell」と呼ばれていますが、現時点では公式名称ではありません。
また、PHP公式は攻撃条件、影響バージョン、修正版番号をまだ公開していません。
この記事では、未確認の回避策やPoCには触れません。
サーバー管理者が今できる棚卸しと、公式リリース後の更新手順を解説します。
まず確定情報と未確認情報を分ける
PHP公式が発表している内容
2026年10月21日19時10分時点の確定情報は、次の3点です。
| 項目 | 確定している内容 |
| 脆弱性 | 重大な脆弱性2件 |
| 深刻度 | どちらもCVSS v4.0 9.2 |
| 公開予定 | 10月21日14:00 UTC、日本時間23時 |
詳細が先に公開された場合や、悪用が確認された場合は前倒しされる可能性があります。
まだ断定できない内容
影響を受けるPHPのバージョンと修正版番号は未発表です。
攻撃が成立する設定やリクエストの条件も、公式には公開されていません。
検索すると具体的なCVE番号や暫定設定が見つかります。
しかし、公式発表前に第三者のスクリプトを本番環境へ適用するのは危険です。
設定変更がアプリケーションを壊すだけでなく、悪意あるコードが混入している可能性もあります。
php2shell対策の第一歩は実行環境の棚卸し
管理主体を先に確認する
同じWordPressサイトでも、契約形態によって対応者が変わります。
| 環境 | PHP本体を更新する人 | 利用者が行うこと |
| 共有レンタルサーバー | サーバー事業者 | 完了通知とPHPバージョンを確認 |
| マネージドVPS | 契約内容による | 保守範囲と事業者通知を確認 |
| VPS・EC2・自社サーバー | 原則として利用者 | OSパッケージ更新と再起動 |
| Docker・Kubernetes | 原則として利用者 | 修正版を含むイメージへ再ビルド・再配置 |
共有サーバーでは、利用者がOSのPHPパッケージを更新できないことが一般的です。
サーバーパネルや登録メールに届く案内を確認してください。
CLIのPHPバージョンを確認する
SSH接続できる環境では、最初に次のコマンドを実行します。
“`bash
php -v
php –ini
command -v php
“`
`php -v`は、シェルから実行される**CLI版PHP**の情報です。
Webサイトが同じPHPを使っているとは限りません。
PHP-FPMとWebサーバー側を確認する
NginxとPHP-FPMの構成では、稼働中のFPMサービスを確認します。
“`bash
systemctl list-units –type=service | grep -E ‘php.*fpm’
ps aux | grep ‘[p]hp-fpm’
“`
UbuntuでPHP 8.3を利用している例では、次のように確認できます。
“`bash
php-fpm8.3 -v
systemctl status php8.3-fpm
“`
サービス名はOSとPHPのバージョンによって変わります。
Apacheのmod_phpを利用している場合は、Apacheへ読み込まれたモジュールも確認します。
“`bash
apachectl -M | grep php
“`
公開ディレクトリへ`phpinfo.php`を置いたままにしないでください。
`phpinfo()`はモジュール、パス、環境変数など多くの情報を外部へ公開します。
Dockerコンテナ内のPHPを確認する
ホストOSの`php -v`では、コンテナ内のPHPを確認できません。
まず稼働中のイメージを確認します。
“`bash
docker ps –format ‘table {{.Names}}\t{{.Image}}’
docker compose exec php php -v
docker compose exec php php –ini
“`
Composeのサービス名が`app`の場合は、`php`を`app`へ読み替えます。
複数のPHPコンテナがある場合は、Web、queue、schedulerをそれぞれ確認します。
公式リリース前に準備すること
バックアップと復旧手順を確認する
更新前に、ファイルとデータベースのバックアップを取得します。
VPSやクラウドでは、ボリュームのスナップショットも選択肢です。
ただし、バックアップがあるだけでは復旧できるとは限りません。
保存先、取得時刻、復元方法まで確認してください。
ログを上書きしないようにする
アクセスログ、Webサーバーのエラーログ、PHP-FPMログの保存期間を確認します。
侵害が疑われる場合、ログは原因調査の重要な証拠になります。
緊急対応の途中でローテーションや削除をしないよう注意します。
一時停止の方法を決める
修正版をすぐ適用できない場合は、公開停止や接続元制限を検討します。
CERT-EUも、直ちに修正できない公開アプリケーションの隔離を案内しています。
ロードバランサー、WAF、Security Group、Nginxのアクセス制御など、環境に合う方法を事前に確認します。
公式リリース後のPHP更新手順
Ubuntu・Debian系
最初に、OSベンダーのリポジトリに修正版が配信されたことを確認します。
“`bash
sudo apt update
apt list –upgradable 2>/dev/null | grep ‘^php’
sudo apt upgrade
“`
更新後は、利用中のPHP-FPMを再起動します。
“`bash
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx
“`
Apacheとmod_phpの構成では、Apacheを再起動します。
“`bash
sudo systemctl restart apache2
“`
ここにある`8.3`やサービス名は例です。
実際に稼働しているバージョンへ読み替えてください。
RHEL・AlmaLinux・Rocky Linux系
RHEL系では、利用中のパッケージとモジュールストリームを確認します。
“`bash
rpm -qa | grep ‘^php’
sudo dnf check-update
sudo dnf update ‘php*’
“`
更新後はPHP-FPMとWebサーバーを再起動します。
“`bash
sudo systemctl restart php-fpm
sudo systemctl reload nginx
“`
ディストリビューションは修正をバックポートすることがあります。
その場合、表示される上流PHPのバージョンだけでは判定できません。
OSベンダーのセキュリティアドバイザリとパッケージリリース番号を確認してください。
Docker・Docker Compose
公式または信頼できる提供元が、修正版を含むイメージを公開したことを確認します。
その後、ベースイメージを取得し直して再ビルドします。
“`bash
docker compose pull php
docker compose build –pull –no-cache php
docker compose up -d –force-recreate php
docker compose exec php php -v
“`
Dockerfile内でOSパッケージからPHPを入れている場合は、ビルド時に更新が入る構成か確認します。
既存コンテナを再起動するだけでは、イメージ内のPHPは更新されません。
WordPressとLaravelで追加確認すること
WordPressはPHP本体を更新できない
WordPressの管理画面から更新できるのは、WordPress本体、テーマ、プラグインです。
今回必要なPHP本体の更新は、サーバー側で行います。
PHP対策後に、WordPress側も正規の更新を適用します。
WP-CLIを利用できる場合は、状態確認に次のコマンドを使えます。
“`bash
wp core version
wp core verify-checksums
wp plugin list –update=available
wp theme list –update=available
wp user list –role=administrator
“`
`wp core verify-checksums`はWordPressコアの改変確認に役立ちます。
有料プラグインや独自テーマまで完全に検査するコマンドではありません。
Laravelは常駐プロセスも再起動する
`composer update`を実行しても、PHPエンジンの脆弱性は修正されません。
OSパッケージやコンテナのPHPを更新する必要があります。
PHP-FPMのほかに常駐プロセスがある場合は、更新後に読み込み直します。
“`bash
php artisan queue:restart
php artisan horizon:terminate
php artisan octane:reload
“`
すべてを実行する必要はありません。
queue、Horizon、Octaneのうち、利用しているものだけを対象にします。
Supervisorやsystemdでワーカーを管理している場合は、プロセスが正常に再起動したことも確認します。
更新後に「直った」と判断するための確認
すべての実行経路でバージョンを確認する
CLI、PHP-FPM、コンテナ、queue workerが同じ修正済み環境を使っているか確認します。
`php -v`だけを見て完了にしないことがポイントです。
次に、トップページ、ログイン、管理画面、フォーム、メール送信を確認します。
API、決済、画像アップロード、バッチ処理がある場合は、それらも対象です。
実際に調べて気づいた情報確認の難しさ
今回、事業者の公式ページを調べる中で、SNSの説明と公開ページの内容が一致しない場面がありました。
特にXserverについては、公開ページだけでは今回の脆弱性との因果を明記した全域停止を確認できませんでした。
緊急時は、検索結果の見出しだけで判断しないことが大切です。
契約者メール、サーバーパネル、公式障害情報の順に確認すると、利用中の環境に合う情報へたどり着きやすくなります。
侵害が疑われる場合の初動
削除より先に隔離と保全を行う
不審なPHPファイルや管理者アカウントを見つけても、すぐ削除しないでください。
最初にサーバーを外部ネットワークから隔離します。
次に、ディスクのスナップショットとログを保全します。
最近変更されたPHPファイルは、次のコマンドで調査できます。
“`bash
find /var/www -type f -name ‘*.php’ -mmin -2880 -print
“`
これは直近48時間に更新されたファイルを列挙するだけです。
表示されたファイルが不正とは限らず、攻撃者が更新時刻を変更する可能性もあります。
確認結果だけで安全と判断しないでください。
侵入経路を塞いだ後、安全な端末から管理者パスワード、SSH鍵、データベース認証情報、APIキーを変更します。
封じ込め前に認証情報だけを変えると、新しい情報も取得される可能性があります。
今回の緊急対応で覚えておきたいこと
– PHP公式が示す影響バージョンと修正版を確認する。
– 共有サーバーでは、事業者の完了通知を優先する。
– VPSでは、CLIとPHP-FPMの両方を確認する。
– Dockerでは、修正版イメージからコンテナを作り直す。
– WordPressやComposerの更新をPHP本体の修正と混同しない。
– Laravelのqueue、Horizon、Octaneも再起動する。
– 侵害が疑われる場合は、削除より先に隔離とログ保全を行う。
23時の公式公開後は、この記事に影響バージョン、修正版番号、CVE、正式な回避策を追記します。
それまでは、非公式のPoCや緩和スクリプトを本番サーバーで試さないでください。
公式情報
– [PHP開発チーム：Upcoming Critical PHP Security Release](https://news-web.php.net/php.announce/509)
– [PHP公式サイト](https://www.php.net/)
– [CERT-EU：Security Advisory 2026-018](https://cert.europa.eu/publications/security-advisories/2026-018/)
– [さくらインターネット：緊急メンテナンスのお知らせ](https://help.sakura.ad.jp/notification/n-2697/)
—
コメント