10月21日の夜、PHP本体に「緊急」の脆弱性が公表された
2026年10月21日、PHP本体にリモートからコードを実行できる脆弱性（通称 php2shell、CVE-2026-109618 / 109619）が公表されました。深刻度はCVSS 9.2。WordPressのプラグインやテーマの脆弱性なら月に何件も見ますが、PHPそのものが対象になるのは久しぶりで、翌朝にはレンタルサーバー各社が一斉に告知を出す騒ぎになりました。
私は制作会社で数十社・約150サイトの保守に関わっています。この記事では、公表の翌日から1週間で実際にやった「全サイトの棚卸し」と、その中で気づいたこと・つまずいたことをまとめます。同じ立場の人が、次に同じことが起きたときに最初の1日を短縮できるように、という意図で書いています。
まず押さえた事実（執筆時点）
- 修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。8.1以前には公式の修正がないので、古い系列を使っているサイトはバージョンを上げる以外に手がない
- レンタルサーバー各社の対応は割れた。管理画面を一時停止して一斉適用した会社、一部サーバーでサイト表示を止めた会社、系列によって適用日が数日ずれた会社がある
- バージョン番号を変えずにパッチを当てた会社がある。つまり、管理画面に表示される版数だけでは「対応済みか」を判断できない
最初にやったのは「PHPを上げること」ではなく「一覧を作ること」
騒ぎの最中に一番やってはいけないのは、手元のサイトから順にPHPを上げていくことです。どのサイトが対象で、どのサーバーにあって、誰が管理していて、連絡先は誰か。これが揃っていないと、途中で必ず止まります。
私はスプレッドシートに1サイト1行で、次の列を作りました。
- サイト名・URL・種別（WordPress／静的）
- PHPを使っているか
- 稼働状況（稼働中／制作中／閉鎖済み）
- 保守契約の有無、担当者
- サーバー会社、サーバーの管理者（当社かクライアントか）
- WordPressの版数
- パッチ適用前のPHP版数、適用後の版数、確認日
- 対応区分、クライアントへの案内区分、今回の対応状況
- バックアップ取得日と格納先、切替予定日・完了日、動作確認
列を見ると分かるとおり、半分は「技術情報」ではなく「誰が・いつ・どう連絡するか」です。約150サイトのうち、WordPressが約90、静的HTMLが約60。この静的60サイトが曲者でした。
静的サイトでも「PHPを使っている」ことがある
静的HTMLのサイトは対象外だと思いがちですが、実際に1サイトずつFTPで見ていくと、次のようなものが出てきます。
- お問い合わせフォームだけ
mail.phpや MailformPro（PHP製）で動いている - 旧サイトのファイルが
oldや_backupというディレクトリに残っていて、中に古いPHPがある - 採用サイトやLPだけCGIやPHPのフォームを使っている
- リニューアル前のWordPressのファイルが、使われないまま残っている
「使っていないけど置いてあるPHP」は、動かしていなくてもサーバー上に存在する限り攻撃の入口になり得ます。今回は、不要と確認できたものはバックアップを取ってから削除しました。棚卸しの副産物として、サーバーの掃除ができたのは正直ありがたかったです。
サイトを4つに分けた
一覧ができたら、PHPの版数とサーバーの種類で機械的に分けます。
A：PHP 8.2以上・共用サーバー（約70サイト）
サーバー会社がパッチを当ててくれる区分。こちらの作業は「適用済みかの確認」だけ。ただし、版数が変わらない会社もあるので、公式告知と照合して確認日を記録する。
B：PHP 8.1以下（約45サイト）
公式修正がないので、8.2以上の系列に切り替える必要がある。今回の作業のほぼ全部がここ。切り替えると古いプラグインやテーマで「重大なエラー」が出ることがあるので、バックアップと動作確認がセット。
C：VPS・自社管理・サーバー不明（約15サイト）
共用サーバーの自動対応がない、またはそもそもどこで動いているか分からない。1件ずつ管理者を特定するところから始まる。
対象外（約20サイト）
PHPを使っていない静的サイト、閉鎖済み、他社でリプレイス済み。
この分け方の良いところは、AとBは技術的な判断がほぼ不要で、手を動かす人に任せられることです。判断が必要なCに、自分の時間を集中できます。
「誰に何を伝えるか」も6つに分けた
技術の区分とは別に、クライアントへの案内を6種類に分けました。保守契約の有無と、サーバーを誰が管理しているかで決まります。
- 当社で実施（保守契約あり）
- 切り替えを推奨し、有償での代行を提案（当社管理のサーバー）
- 切り替えを推奨し、手順を案内（クライアント管理のサーバー）
- 要確認（サーバー管理者が分からない）
- 自社サイト
- 連絡不要（サーバー会社の対応で修正済み）
案内文はこの6種類だけテンプレートを作り、一覧のセルに区分を入れると文面が決まる形にしました。ここで1つ失敗したのは、最初に区分を自動判定にしようとしたことです。保守契約の有無やサーバー管理者の情報が不完全な状態で自動化すると、間違った案内が飛びます。結局、人が手で入力して、別の人がチェックする運用にしました。
PHPを上げる前に、必ずやったこと
B区分の切り替え作業は、次の順番で進めました。
- バックアップ（ファイルとデータベースの両方）を取り、格納先を一覧に書く
- 古いプラグイン・テーマを確認する。特に
create_function()のような、PHP 8で廃止された関数を使っているものは、切り替えた瞬間に「重大なエラー」になる - サーバーの管理画面でPHPの版数を切り替える
- トップ・下層ページの表示、管理画面へのログイン、フォームのテスト送信を確認する
- 一覧に完了日と動作確認の結果を書く
4のフォーム確認は飛ばされがちですが、PHPの版数が変わるとメール送信まわりで不具合が出ることがあり、見た目は正常でも問い合わせが止まっているケースがあります。
切り替えてエラーが出た場合は、慌てずに旧版へ戻して、原因のプラグインを更新するか代替に替えてから再挑戦します。この復旧手順は別記事にまとめています。
実際につまずいたこと
一覧と区分があっても、現場では想定外が起きます。今回あったものを挙げておきます。
- クライアントが先にPHPを上げてしまった：事前連絡をお願いした翌日に「更新完了しました」と連絡が来て、直前のバックアップが取れなかった。更新前の最新バックアップは3週間前のものだった
- サーバーの管理画面に入れない：二要素認証がクライアントのスマホに紐づいていて、こちらではログインできない。FTPのパスワードも変更されていた
- サイトが閉鎖中・メンテナンス中で確認できない：サーバー移行の途中だったり、契約期限切れで止まっていたりで、現状を見られないサイトが数件
- サーバー会社が分からない：他社制作のサイトを引き継いだもの、データ納品だけで公開先を把握していないもの
- 古いCMSの扱い：外部に開発を委託した独自CMSは、開発者にPHPの利用状況と対応可否を問い合わせるところから。更新の見込みがないPHP製CMSは、バックアップを取ってサーバーから撤去する判断をした
どれも「今回だけ」の問題ではありません。平時から一覧があれば、最初の1日で済んだことばかりです。
棚卸しを「今回限り」にしないために
一番の教訓は、この一覧は緊急時に作るものではなく、常に持っているべきものだということです。
今回作った管理表は、PHP対応が終わったあとも、次の列を足して運用を続けることにしました。
- PHPの版数と、サーバー会社のサポート期限
- WordPress本体の版数と自動更新の有無
- サーバー・ドメイン・SSLの期限（これは別記事で書いた管理と統合）
- フォームの種類と、テスト送信の最終確認日
もう1つ、PHPを修正しても、すでに侵入されていた場合の痕跡は消えません。公開フォルダに覚えのないPHPファイルがないか、WordPressに覚えのない管理者がいないかは、切り替えとは別に確認する項目として一覧に入れました。
関連記事
PHPを上げた直後に「重大なエラー」で管理画面に入れなくなったときの復旧手順、脆弱性アラートの読み方、期限管理の考え方は、別の記事にまとめています。
まとめ
- PHP本体の緊急脆弱性では、「上げる」前に「全サイトの一覧」を作る。静的サイトにもPHPは潜んでいる
- 版数とサーバーでA・B・C・対象外の4つに分け、判断が必要なものだけに時間を使う
- クライアントへの案内は、保守契約とサーバー管理者で6種類に分けてテンプレート化する
- PHPを上げる前はバックアップ、上げた後はフォームのテスト送信まで確認する
- 一覧は緊急時に作るものではなく、平時から持っておくもの
約150サイトの棚卸しは、1週間かかりました。次に同じことが起きたら、一覧があるので初日に区分まで終わるはずです。「次」は必ず来るので、今のうちに一覧だけでも作っておくことをおすすめします。