PHPの深刻な脆弱性（PHP2shell）への対応記録——エックスサーバーで動くサイトの棚卸しから8.3系への切り替えまで

10月21日に何が発表されたか

開発元（The PHP Group）がphp.netに掲載したお知らせの要点は、次のとおりです。

開発元は修正版の公開に先立って事前告知を出し、日本時間21日23時に公開する予定だと案内していました。22日にはIPAとJPCERT/CCも注意喚起を出しています。どちらの注意喚起にも、悪用が確認されたという報告は書かれていません。

レンタルサーバー：Shift Forwardの対応

お引き受けした各社のサイトは、多くがエックスサーバーで動いていました。エックスサーバーのPHPの修正は同社が入れますが、どのサイトがどこでPHPを使っているかは、サイトを預かる側でないと分かりません。

サイトを棚卸しして切り替えの手順を決める

ログイン情報を預かる前に、外から見える範囲で当たりを付けました。手がかりにしたのは次の4つです。

• 応答のヘッダー（X-Powered-Byなど）
• WordPressが出す目印（generatorの表示やreadme.html）
• 問い合わせや応募のフォームの送信先が、.phpのファイルか、外部のフォームサービスか
• ドメインの設定から分かるサーバー会社

これで、各サイトの構成とサーバー会社が分かりました。サーバーの契約とWordPressの管理者のログイン情報は、各社から預かりました。本番のサイトがすでに修正済みのバージョンで動いていた会社もありました。そうした会社でも、使っていない初期ドメインに残っていた古い設定も8.3系に上げました。

エックスサーバーは21日16時から、予防のため管理画面へのアクセスを止めていました（サイトの表示とメールは通常どおり）。その間は、WordPressの管理画面にある「サイトヘルス」でPHPのバージョンを調べました。

手順は、まず8.3系にし、表示や動きに問題があれば8.2系、それでも問題があれば元のバージョンに戻す、という順に決めました。8.3系は、開発元が脆弱性を直す期間が2027年末まで続き、WordPressの推奨環境（PHP 8.3以上）にも合います。フォームは、本当に送ると各社やお客様にメールが届いてしまうので、送らずに確かめる手順を用意しました。修正版の公開予定（23時）より前に、各社のサーバーとサイトの構成を状況表にまとめ終えていました。

8.3系に切り替えて全ページを見比べる

エックスサーバーのお知らせによると、同社は21日のうちに、発表前の不正アクセスのリスクを下げる緩和措置を利用者のサーバーにも入れ、その後、設定しているバージョンを変えないまま修正を入れています。

PHPの修正そのものはエックスサーバーが入れているので、8.3系への切り替えは、開発元のサポートが続くバージョンに移す作業として行いました。

切り替えたサイトは、切り替えの前後で全ページ（パソコンとスマートフォンで計88画面）の表示を見比べ、PHPのエラーが出ていないことも見ました。フォームは、何も入力せずに送って入力チェックが働くことと、不正な送信を防ぐ確認用の値（トークン）がわざと誤っているとエラーで止まり、メールが送られないことを確かめました。送信処理のプログラムも読み、入力の整形、メールの送信、データベースへの保存がWordPressの標準の関数だけでできていて、8.3系で動かなくなる書き方がないことも確かめました。

切り替え前の画面の保存から、切り替え、全ページの見比べ、各社への報告までを約1時間で終えました。用意していた8.2系や元のバージョンへ戻す場面はありませんでした。

自前のサーバー：pixivの対応

イラスト投稿サービスのpixivは、自前のサーバー（Kubernetes）で動き、PHP入りのコンテナを自分たちで作り直して入れ替えています。運営するピクシブ株式会社の技術ブログの記事によると、事前にDocker公式イメージを更新する方法と、PHPをソースから自前でビルドする方法の2つを用意し、21日19時にメンテナンスに入って、外からの接続をすべて止めてから更新しました。修正版の公開からpixivのメンテナンスを終えるまでは約30分でした（ピクシブ株式会社の公式X）。pixivのお知らせでは、この脆弱性による被害は確認されていないとされています。

修正版が出る前に更新の方法を2つ用意し、先にメンテナンスに入っていたことで、当日の作業がこの短さに収まっています。自前でサーバーを持つ場合の進め方として、参考になる対応です。

自社のサイトを確認・更新するときのポイント

PHPで動いているものを全部洗い出す

• ホームページの本体のほか、サブドメインのサイトや、問い合わせ・応募のフォームの送信先を調べてください。ページがHTMLでも、フォームだけPHPで動いていることがあります。
• 予約・受発注・社内の業務システムも対象です。PHPを使う製品や機器は、提供元のお知らせを見てください。
• サーバー会社の初期ドメインや、使っていないドメインにもPHPの設定が残っていることがあります。
• サーバーの契約と、WordPressの管理者のログイン情報が、すぐ使えるかを確かめてください。
• サーバー会社の管理画面が使えないときでも、WordPressなら「ツール」→「サイトヘルス」→「情報」の「サーバー」の欄で、PHPのバージョンが分かります。

レンタルサーバーの場合

修正が入ったかは、サーバー会社のお知らせで確かめてください。管理画面に出るバージョンだけでは分からないことがあります。たとえばエックスサーバーは、PHP 5.6〜8.5に、設定しているバージョンを変えないまま修正を入れたとお知らせで案内しています。開発元のサポートが終わったバージョンを使っていれば、移行を計画してください。

PHPのバージョンの切り替えは管理画面の設定の変更で、エックスサーバーではドメインごとに一覧から選び直せます。WordPress本体やプラグインも更新するなら、先にバックアップを取ってください。

自社サーバーの場合

php -vで分かるのは、コマンドラインで使うPHPのバージョンです。Webのアクセスを処理しているPHP（PHP-FPMやmod_php）とは違うことがあります。Debian・UbuntuなどのPHPは提供元が修正だけを取り込むので、バージョンが8.3.36などにならないことがあります。たとえばUbuntu 24.04 LTSの修正済みのパッケージは8.3.6-0ubuntu0.24.04.13で（USN-8948-1）、Ubuntu 24.04ではphp-fpm8.3 -vにこの細かいバージョンまでは出ません。パッケージのバージョンを、提供元のお知らせと照らし合わせてください。

RHELなどで有志のRemiのリポジトリ（rpms.remirepo.net）を使っている場合は、リポジトリ側の更新を確かめてください。開発元のお知らせには、当日はまだ更新がないと書かれていました。

dpkg -l 'php*'                        # Debian・Ubuntu
rpm -q php php-fpm                    # RHEL など
sudo systemctl restart php8.3-fpm     # Debian・Ubuntu（例）
sudo systemctl restart php-fpm httpd  # RHEL など

パッケージを更新したら、PHP-FPMやApacheを再起動し、動いているPHPが新しくなったかを確かめてください。更新と再起動には管理者の権限（sudo）が要ります。WordPressならサイトヘルスで、それ以外のサイトなら一時的に置いたphpinfo()のページで分かります。phpinfo()のページは、見たらすぐ消してください。

すぐに更新できないときの暫定の設定は、開発元のお知らせに項目ごとに載っています。特定の攻撃の道筋を減らすだけで、更新の代わりにはなりません。

8.1以前を使っている場合

7.4系から8.3系のようにバージョンを上げると、古い書き方のプログラムが動かなくなることがあります。php.netの移行ガイド（8.0、8.1、8.2、8.3）を、いまのバージョンから順に読んでください。8.2系も、開発元が脆弱性を直す期間は2026年12月31日（木）で終わります（Supported Versions）。

切り替える前に戻し方と見比べ方を決める

• 切り替え前の全ページの画面を、パソコンとスマートフォンの表示で保存してください。切り替え後に同じページと見比べられます。
• 戻し先のバージョンにも今回の修正が入っているかを確かめてください。修正済みの戻し先がない場合は、公開の制限や一時停止も含めて判断してください。
• フォームは、まず送らずに確かめます。何も入力せずに送って入力チェックが働くことと、送信の手前で止まる処理が動くことを見てください。送信まで試すなら、自動返信の宛先は自分のアドレスにし、受け手には事前にテストだと伝えてください。
• プラグインが切り替え先のバージョンに対応していれば、プラグインの更新は別の作業にできます。対応していなければ、更新と切り替えの順番を決めてください。

攻撃を受けていないかを調べる

更新する前に入り込まれていた場合、更新しただけでは元に戻りません。JPCERT/CCの注意喚起に調べるときの目安が載っていて、痕跡が見つからなくても攻撃を受けていないとは言い切れない、という注意も書かれています。

レンタルサーバーなら、管理画面からアクセスログとエラーログをダウンロードしてください。フォームなどへの送信（POST）の集中や、サーバーエラー（HTTP 500）の急増が目安です。ログは一定の日数で消えることがあります。読み方が分からなければ、ファイルのままサーバー会社や保守の担当に渡してください。

自社サーバーなら、不審なmultipart/form-data形式のリクエストと、その前後のメモリ上限のエラーやHTTP 500、PHPのワーカーの異常終了や頻繁な再起動、値が不自然に長いPHPSESSIDのCookieがないかを調べてください。見覚えのないファイルや外への通信も調べてください。

次の告知を受け取れるようにする

修正版の事前告知は、php.netのお知らせのRSSに出ます。修正版が出たあとの調べ方は、JPCERT/CCの注意喚起で届きます。どちらも、告知を見る担当者のアドレスで受け取れるようにしてください。JPCERT/CCはメール配信に登録できます。保守を外部に任せている場合は、告知が出たときの連絡と対応の流れを、保守の契約に入れておいてください。

まとめ

どのサイトでも、まずPHPで動いているサイトやフォーム、業務システムを洗い出し、いまのバージョンと修正が入ったかを確かめてください。開発元のサポートが終わったバージョンや8.2系のサイトは、切り替え前の画面を保存して8.3系以上への移行を計画し、アクセスログとエラーログを保存して攻撃を受けていないかも調べてください。