PHPの重大な脆弱性php2shellの影響と対策

PHPを使ってWebサイトを公開している場合は、PHP本体のセキュリティ更新を確認してください。2026年10月21日に、認証なしでサーバー上のコードを実行されるおそれがある2件の脆弱性が公表されました。通称は「php2shell」です。PHP公式は修正版を公開し、速やかな更新を呼びかけています。 PHP公式のセキュリティ告知

レンタルサーバーでは、まず事業者の対応状況を確認します。VPSや自社サーバーでは、実際にWebリクエストを処理するPHPを更新し、関連プロセスの再起動と動作確認まで行います。本記事の情報基準日は2026年10月22日です。

最初に確認すること

PHPが何をするソフトか知りたい場合は、 PHPの紹介ページ も参考になります。WordPressの利用者は、後述するサーバー事業者への確認から始めると、作業の担当範囲を整理できます。

どのような脆弱性か

今回の2件は、PHP内部のメモリやリクエスト状態の扱いに関係します。

どちらも、条件によって認証不要のリモートコード実行につながります。詳しい技術情報は、PHP開発元の メモリ不足処理に関する公告 と 古い内部状態に関する公告 で確認できます。

PHP-FPMやApacheも確認が必要

対象をWindowsのPHP-CGIだけに限定しないでください。PHP公式は、PHP-FPM、Apache modphp、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHP環境に注意を求めています。特にmodphpでは、アプリケーションのコードが実行される前に攻撃が成立する実証が報告されています。 PHP公式告知

「ログインが必要な管理画面だから」「アップロード画面を隠しているから」といった理由だけで対象外と判断せず、PHP本体の修正状況を確認します。PHPを内蔵する製品については、 NCSC-NLの製品調査リスト も調査の入口になりますが、最終的な対応状況は各ベンダーの告知を確認してください。

修正版とバージョン番号の見方

PHP開発元が今回公開した修正版は次のとおりです。同じ分岐を継続利用する場合は、この版またはそれ以降の修正済みリリースを確認します。

ソースやWindows向け配布物は 公式ダウンロードページ から確認できます。

Linuxディストリビューションには、既存のパッケージに修正だけを取り込む「バックポート」があります。この場合、表示されるPHPの基本バージョンは上の表より古くても、修正済みのことがあります。OSと配布元の公告に記載されたパッケージ全体のバージョンで判断してください。

例えばUbuntu 24.04 LTSの標準配布パッケージでは、php8.3-fpmなどの修正済み版として8.3.6-0ubuntu0.24.04.13が案内されています。他のOSや外部リポジトリには、この番号を流用できません。 Ubuntu USN-8948-1

PHP 8.1以前はPHPプロジェクトによる通常のサポートが終了しています。今回、7.4・8.0・8.1向けの最小限のソース修正も提供されていますが、長期サポートが再開されたわけではありません。保守ベンダーの提供状況を確認し、サポート対象への移行も計画します。 PHP公式告知 ・ サポート期間

更新の手順

1 サイトとPHPの対応関係を調べる

ドメインごとのPHPバージョン、処理方式、配布元、運用担当者を記録します。複数サイトを運用している場合は、設定が共通とは限りません。外部公開している環境を優先し、APIや検証環境も棚卸しに含めます。 ENISAの共同声明

SSHを使える場合、次のコマンドはコマンドライン側のPHPの確認に使えます。設定の変更は行いません。

php -v
php --ini

-vはバージョン、--iniは設定ファイルの場所を表示します。 PHP公式のコマンドラインオプション

ただし、この結果だけではWeb側のPHPを確認できません。PHP-FPMのプール、Apacheのモジュール、サーバー管理画面など、サイトに実際に割り当てられた実行環境も確認してください。調査のために詳細なphpinfo()をインターネットへ公開したままにしないようにします。

2 バックアップと復旧方法を確認する

サイトのファイル、データベース、PHPやWebサーバーの設定を保管します。既に利用できる検証環境があれば、更新後のログイン、フォーム、アップロード、主要機能を先に確認します。

同じ分岐のセキュリティ更新と、8.2から8.5などの分岐変更は分けて考えます。分岐変更が必要な場合は、拡張モジュールやアプリケーションの互換性も確認してください。

3 配布元に合った修正を適用する

レンタルサーバーでは、事業者がPHPを更新する場合があります。「メンテナンス実施予定」だけでなく、利用中のプランとPHP系列が対応済みか確認します。管理画面の切替が必要な場合は、事業者の手順に従います。

VPSや自社サーバーでは、OSまたは契約中の配布元が提供するセキュリティ更新を適用します。Ubuntuの公式案内ではパッケージ更新と、利用するアプリケーションの再起動が説明されています。独自ビルドや外部リポジトリの場合は、その配布元の修正を確認してください。 Ubuntuの対応手順

コンテナでは、修正済みPHPを含むイメージを用意し、必要に応じてアプリケーションを再ビルドして、実行中のコンテナを作り直します。新しいイメージを取得しただけで、既に動いているコンテナの内容が変わったとは判断できません。

Ubuntu 24.04 LTSの標準パッケージを使う例

次は、OSがUbuntu 24.04 LTSで、Ubuntu標準リポジトリのPHP 8.3を利用する管理者向けです。外部リポジトリや独自ビルドには、そのまま適用しないでください。更新にはPHP以外のパッケージが含まれる場合もあるため、バックアップと作業時間を確保し、変更内容を確認してから進めます。

sudo apt update
apt-cache policy php8.3-fpm libapache2-mod-php8.3 php8.3-cli
apt -s upgrade

apt-cache policyで導入済み版と候補版、配布元を調べます。apt -s upgradeは更新予定を表示するシミュレーションです。インストール済みの対象パッケージに修正済み候補があることと、他の変更への影響を確認したうえで、更新を実行します。 APTの操作説明 ・ apt-cacheの説明

sudo apt upgrade

PHP 8.3 FPMがこのサイトを処理している構成では、対象サービスの再起動例は次のとおりです。

sudo systemctl restart php8.3-fpm

Apache mod_phpを使っている構成では、PHPを読み込んでいるApache側を再起動します。

sudo systemctl restart apache2

両方を無条件に実行する手順ではありません。実際の構成に対応するサービスを選び、停止時間と影響を確認してください。候補版が提供されない場合や更新が保留される場合は、配布元やパッケージ設定を調べ、修正が入ったと推測しないでください。 Ubuntuの公式対応手順 ・ 修正済みパッケージ一覧

4 更新されたPHPを実際に読み込ませる

PHP-FPM、mod_phpを使うApacheなど、該当する実行プロセスに更新を反映します。サービス名と再起動方法は環境によって異なります。古いワーカーが残っていないことを確認してください。Webサーバーだけを再起動しても、別サービスのPHP-FPMに反映されるとは限りません。

5 動作と修正状況の両方を確認する

1. 配布元の公告と、インストール済みパッケージまたはビルドの修正状況を照合する。
2. 実際のWeb側PHPに更新が読み込まれたことを確認する。
3. 公開ページ、管理画面、フォーム、アップロードなどを確認する。
4. エラーログとアクセスログに更新後の異常がないか確認する。
5. 担当者、実施時刻、対象サイト、確認結果を記録する。

画面が表示されたことと、脆弱性が修正されたことは別の確認です。公開サイトへ攻撃用の実証コードを送る方法で確認する必要はありません。

すぐに更新できない場合

修正が適用されるまで、外部公開の停止やアクセス元の制限を運用担当者と検討します。CERT-EUは、即時の修正が難しい場合、修正の適用と確認が終わるまでインターネット公開環境を隔離することを推奨しています。 CERT-EU

PHP公式には設定による暫定緩和策もありますが、特定の攻撃経路を減らすものであり、修正の代わりにはなりません。memory_limitなどを根拠なく変更すると可用性にも影響するため、設定をコピーするだけで解決したと判断しないでください。

Cloudflareは今回の攻撃向けのWAF保護を案内していますが、PHP自体の更新も必要としています。WAFを利用していても更新を継続し、保護対象の通信経路を確認します。 Cloudflareの公式案内

不審な動作がある場合

見覚えのないファイルや管理者、不審なプロセス・外部通信がある場合は、保守担当者に連絡し、ログや実施記録を保全してください。更新だけで侵入済みの変更が元に戻るわけではありません。影響調査と復旧を分けて進めます。 カナダのサイバーセキュリティ機関による対応案内

よくある質問

WordPressやプラグインの更新だけで直りますか

今回の修正対象はPHPの実行環境です。WordPress本体やプラグインの更新も必要に応じて行いますが、それだけでは今回のPHP本体の修正を代替できません。

Composerやスキャナーを導入すれば修正できますか

Composerのauditは依存ライブラリの検査です。ZAPはWebアプリケーションの検査、Trivyは対応するパッケージやイメージなどの検査に使います。導入しただけでPHP本体に修正が入るものではありません。検査で警告が出ない場合も、配布元の修正状況を確認してください。 Composerのaudit ・ ZAPの入門説明 ・ TrivyのPHP対応範囲

古いバージョンが表示される場合は未修正ですか

上流版では修正版との比較が必要ですが、ディストリビューションのバックポートでは表示が異なることがあります。サーバー事業者や配布元が示す修正済みパッケージと照合します。