導入
10月21日の夜、ホームページの裏で動いているプログラム（PHP）に重大な欠陥が見つかり、修正版が公開されました。翌朝の打ち合わせで、お客様から「うちのサイトは大丈夫ですか」と聞かれました。
この記事は、その日から5日間で、制作や保守で関わっているサイトを全部点検した記録です。結論を先に書きます。
- 点検したのは30ドメイン（ドメインは、サイトの住所にあたる名前です）、サーバー会社は4社。当社が実際にバージョンを切り替えたのは1つだけでした。20はサーバー会社が修正を済ませていて、利用者側の作業はなし。5つは休止中でした。
- 打ち合わせで「静的なページなので関係ない」と答えたサイトが1つ、間違いでした。お問い合わせフォームの送信処理だけPHPで動いていて、しかもサポートが終わった古い版でした。
- 別のお客様の旧サーバーを棚卸ししたら、10年前のWordPressが3つ動いていました。PHPを上げると画面が止まります。「PHPを上げる」ではなく「作り直す」案件になりました。
事業者の方に持ち帰ってほしいのは、「自分のサイトのPHPが何で動いているか」を知っているかどうかで、こういう日の過ごし方が変わる、ということです。
きっかけ
10月20日、PHPの開発チームが「重大な修正版を21日に出す」と予告しました。21日の夜、修正版（8.5.12、8.4.27、8.3.36、8.2.35）が公開されました。内容は、外部から認証なしでサーバー上のプログラムを実行されるおそれがあるもので、深刻度は最高に近い評価（CVSS 9.2）です。PHP 8.1以前には公式の修正版が出ませんでした。
翌22日の午前、お客様との打ち合わせでこの話になりました。先方が運用しているサイトは3つ。会社のサイト（WordPress）、商品の買取を受け付けるLP、ノーコードの制作サービスで作ったサイトです。私はLPについて「ページは静的なHTMLなので影響ありません」と答えました。
戻って確かめたら、LPのお問い合わせフォームの送信先は confirm.php でした。確認画面とメール送信だけPHPが動いています。サーバーのPHPは7.4.33。公式の修正版が出ない版です。昼のうちに訂正の報告書を送りました。
最初に：誰が直すのかを整理
この件で読者の方が迷うのは、「自分で何かしないといけないのか」です。答えは場所で決まります。サイトがどこで動いているか、です。
- レンタルサーバー（エックスサーバー、さくらなど）。PHP本体はサーバー会社が管理しているので、修正もサーバー会社がやります。利用者は「どのバージョンを使うか」を管理画面で選んでいるだけです。
- VPSや自前のサーバー。PHPを自分で入れているので、自分で更新します。今回、エックスサーバーもさくらも「VPSや自分で入れたPHPは対象外」と明記していました。
- ノーコードの制作サービス。PHPを使っていないので今回の件は対象外です。ただし、サービス側で別の事故が起きることはあります（後述）。
当社が関わるサイトはほぼ1です。だから今回の点検は、「サーバー会社の告知を読む」と「自分のサイトが何のバージョンで動いているかを見る」の2つが中心でした。
覚える言葉は3つだけ
- PHP。ホームページの裏で動くプログラムの言語です。WordPressはこれで動いていますし、静的なサイトでもお問い合わせフォームの送信処理だけPHPということがよくあります。
- バージョン。8.3.36 のような番号です。今回は「8.2.35、8.3.36、8.4.27、8.5.12以上なら修正済み」が目安でした。ただし8.1以前は番号が変わらないまま修正されるので、番号だけでは判断できません（後述）。
- サイトヘルス。WordPressの管理画面にある診断ページです。「ツール」→「サイトヘルス」→「情報」→「サーバー」で、PHPのバージョンが見えます。
手順0：自分のサイトのPHPが何かを調べる
外からは分かりません。多くのサーバーはPHPのバージョンを応答に出さない設定になっています（出ている場合は、それ自体を隠したほうがよいです）。
調べ方は2つです。
- WordPressなら、サイトヘルスを見る。管理者権限が要ります。
- サーバーの管理画面で「PHP Ver.切替」や「言語バージョン設定」を見る。契約者か、管理を任されている人しか入れません。
今回は10月22日にエックスサーバーの管理画面がアクセス集中で開きにくくなっていたので、WordPressのサイトヘルスで先に確認しました。
静的なサイトでWordPressがなく、管理画面にも入れない場合は、バージョンを表示するだけの小さなファイルをFTPで置いて、ブラウザで開いて、すぐ消します。ファイル名は推測されない文字列にして、消したあとに404になることまで確認します。買取LPはこの方法で7.4.33と分かりました。
点検の記録
5日間で見た30ドメインを、サーバー会社ごとにまとめます。
| サイト | サーバー | 分かったこと | やったこと |
|---|---|---|---|
| 買取LP（静的HTML＋フォーム） | エックスサーバー系 | PHP 7.4.33。公式の修正版は出ない版 | サーバー会社が7.4〜8.1に修正パッチを適用済みと告知（10月26日までに全サーバー完了）。緊急対応は不要と先方へ報告。8.3への切替は別途 |
| 同じ会社のWordPressサイト | さくら | PHP 8.3。当社の権限ではサイトヘルスが見られない | さくらが全バージョンの修正を10月22日に告知。先方の情報システム部が8.3.36を確認 |
| 同じ会社のノーコードサイト | 制作サービス側 | PHPなし。今回は対象外 | 別件でサービス側の不正アクセスが公表されていたため、フォームの回答がいくつ保存されていたかを数えて先方へ報告 |
| サービス業のコーポレートサイト（WordPress） | エックスサーバー | サイトヘルスでPHP 8.1.34。修正パッチの対象だが、8.1自体がサポート終了 | バックアップを取ってから8.3.36へ切替。全42ページの表示を切替前後で比較して差分なし。フォーム表示も確認 |
| 同じ契約に同居する静的サイト | エックスサーバー | PHP 5.4.45。フォームだけPHP。SSLもなし | 修正パッチの対象。PHP更新とSSL化を運用契約の範囲で対応する方針に |
| 別のクライアントの新サーバー（2ドメイン） | エックスサーバー系 | どちらもPHP 8.3.36 | 対応不要。予定していたサーバー移管の前にPHPを触る必要がないことを確認 |
| 同じクライアントの旧サーバー（21ドメイン） | エックスサーバー系 | 下の内訳 | 一覧表にして、3つの提案に分けて送付 |
| 別会社経由で預かる社内向けサイト | 企業の自社サーバー | PHP 8.3.36。ただしWordPress本体が6.6.2で古い | PHPは問題なし。WordPress本体の更新を別件として案内 |
| 自社サイト | シンレンタルサーバー | サイトヘルスでPHP 8.3.36。修正版 | 対応不要。サーバー会社の告知でも「急いでバージョンを変更する必要はない」を確認 |
旧サーバー21ドメインの内訳です。管理画面の「PHP Ver.切替」を1つずつ見て作りました。
| 区分 | 件数 | 判断 |
|---|---|---|
| 8.3.36（修正済み） | 5 | 対応不要 |
| 静的サイトで7.2〜8.1 | 7 | バージョン切替で済む |
| 現行のWordPressで8.1 | 1 | WordPress側の確認をしてから切替 |
| WordPress 4.4.2（2016年2月版）で5.6〜7.0 | 3 | PHPを上げると画面が止まる。作り直しの提案 |
| DNSの応答がない（休止中） | 5 | 消すか残すかを先方が判断 |
この3つのWordPress 4.4.2が、今回いちばん重い発見でした。PHP 8系では動かないので、「PHPのバージョンを切り替える」という今回の対応ができません。本体もテーマもプラグインも10年分古いので、実質は作り直しです。そして、PHPの件とは別に、10年分の既知の欠陥を抱えたまま公開されています。今回の脆弱性より、こちらのほうが急ぎだと先方に伝えました。
「番号が変わらない修正」に注意
エックスサーバー系は、8.2〜8.5は修正版に更新し、5.x〜8.1は「バージョン番号を変えずに修正パッチを適用」しました。さくらも8.1以下は同じ方式で、告知に「PHPバージョンに変更はありません」と書いています。
つまり、サイトヘルスで「7.4.33」と出ても、サーバー会社の告知を読めば修正済みです。逆に言えば、番号だけ見て「修正版じゃない、危ない」と慌てる必要はなく、番号だけ見て「新しい番号だから安全」とも言えません。告知とセットで読む必要があります。
ただし、修正パッチが当たっていても、7.4や8.1はPHPの開発元のサポートが終わっています。次に同じことが起きたとき、サーバー会社が同じ対応をしてくれる保証はありません。今回「対応不要」で済んだサイトも、落ち着いたら8.3へ上げる前提で予定を組みました。
PHPを上げるときの手順（コーポレートサイトでやったこと）
8.1.34のWordPressサイトを8.3.36へ上げたときの順番です。
- バックアップ。プラグインで本体・テーマ・プラグイン・画像・データベースを丸ごと取る。
- 切替前に、全ページの表示を保存しておく。今回は42ページ。
- サーバーの管理画面でバージョンを切り替える。反映は数分。
- 全ページをもう一度取得して、切替前と比較する。差分なし。
- お問い合わせフォームの表示を確認する。
- 崩れたら、同じ画面で元のバージョンに戻す（即時に戻せます）。
ページ数が多いと4が手作業では無理なので、当社は取得と比較を自動でやっています。ここを飛ばして「トップページだけ見てOK」にすると、下層のどこかで真っ白になっていても気づきません。
本筋ではない発見：ノーコードサービスの不正アクセス
お客様の3つ目のサイトは、ノーコードの制作サービスで作ったものでした。PHPは使っていないので今回の脆弱性は対象外です。
ただ、点検の過程で、そのサービス自体が10月16日に不正アクセスを公表していたことを確認しました。9月30日から10月1日にかけて外部から侵入され、フォームの送信内容も流出した可能性がある、という内容です。
管理画面で数えると、その時点で保存されていたフォームの回答は14件で、うち社外からの問い合わせは6件でした。これは当社が決める話ではないので、件数と含まれる項目、個人情報保護委員会への報告の選択肢を先方に渡して、判断をお願いしました。
PHPの件で「全部点検しよう」と動いたから見つかったものです。1つの通知をきっかけに、関わるサイトを全部見ると、別の問題が出てきます。
つまずき早見表
| 起きること | 原因 | 対処 |
|---|---|---|
| 「静的サイトだから無関係」と答えてしまう | フォームの送信先がPHP | HTMLのフォームの送信先（action）を見る。.php なら対象 |
| 外からバージョンが分からない | サーバーが応答に出していない | サイトヘルスか管理画面。どちらも無理なら確認用ファイルを置いて消す |
| 管理画面が開かない | 告知直後のアクセス集中 | 時間を置く。先にサイトヘルスで見る |
| 番号が古いまま（7.4.33など） | サーバー会社が番号を変えずに修正 | 告知で「適用済み」を確認。あわせて8.3への移行を予定に入れる |
| PHPを上げたら画面が真っ白 | WordPress本体やテーマが古い | 先にWordPressのバージョンを見る。4.x系はPHP 8で動かない。管理画面で元に戻す |
| サイトヘルスが見られない | 権限がない | 先方の管理者に確認を依頼する |
確認方法
自分のサイトについて、次の3つが言えれば今回の点検は終わりです。
- サーバー会社の告知ページに、自分の使っているPHPのバージョンが「対応済み」と書かれている。
- サイトヘルスか管理画面で、そのバージョンを自分の目で見た。
- お問い合わせフォームから実際に1通送って、届いた。
3つ目を忘れがちです。バージョンを切り替えたあと、フォームだけ動かなくなっていることがあります。
正直に書いておくこと
- 点検した30ドメインの内訳は、当社が切り替えた1、サーバー会社の修正で済んだ20（自社サイトを含む）、作り直しが必要な3、休止中の5、PHPを使わないノーコードの1です。「全部点検した」は「全部直した」ではありません。
- 買取LPの8.3への切替は、この記事の時点ではまだです。先方の社内手続きで、サーバーの管理者権限を当社に移してから行います。
- 旧WordPress 3件の作り直しは提案中で、返事待ちです。
- 10月23日にPHPの開発元から追加の注意喚起（別の番号）が出ています。エックスサーバーの告知では、その追加分は今回の対応の対象外とされています。
- PHP 8.2は2026年12月31日でサポートが終わります。今回8.2で対応済みになったサイトも、年内に8.3以上へ上げる必要があります。
- 自社サイトは、サーバー会社が同系列（エックスサーバー社）で告知の対象でした。サイトヘルスで見た現在のバージョンは8.3.36で、修正版でした。
要点3行
- レンタルサーバーなら、PHP本体の修正はサーバー会社がやります。利用者がやるのは「告知を読む」と「自分のバージョンを見る」の2つです。
- 「静的なサイト」でも、フォームの送信処理だけPHPということがあります。HTMLの送信先を1行見れば分かります。
- 番号が古いまま修正されることがあるので、番号だけで安全・危険を決めないでください。告知とセットで読みます。
ホームページの保守では、こうした点検を月1回、外から自動で行っています。保守先の点検結果はこちらの記事に書きました。
