古いWordPressとPHPの脆弱性｜旅行会社の31サイトを棚卸しした実測古いWordPressとPHPの脆弱性｜旅行会社の31サイトを棚卸しした実測

「うちのホームページ、全部でいくつあるんだっけ」

古くから続く会社で、こう聞いて即答できる担当の方はあまりいません。キャンペーンのたびにドメインを取り、作った人が辞め、サーバーの請求だけが毎年届く。どれが動いていて、どれが止まっているのか、もう誰にも分からない。

2026年10月、旅行会社のさくらツーリストで、この「全部でいくつ」を本当に数えることになりました。PHP（ホームページを動かすプログラムの言語）に大きな脆弱性が見つかり、古い版のまま動いているサイトを放っておけなくなったからです。

数えた結果、ドメインは46個ありました。中身まで確かめたサイトは31。その半分以上が、直した版の出ない古いPHPの上で動いていた。この記事は、そこから1週間で何を見つけ、どう振り分けたかの記録です。社名は、ご本人の了承を得て出しています。

PHPの脆弱性（PHP2Shell）で、全部のサイトを洗い出すことになった

10月21日の夜、さくらツーリストのいくつかのサイトを一度止めました。PHP2Shellと呼ばれる、PHPの脆弱性への対応です。この穴を狙う攻撃には、10MBを超えるような大きな送信が使われます。

困ったのは、修正版が出たのがPHP 8.2以降だけだったこと。PHP 7.4や5.2のサイトは、待っていても直した版は届きません。7.4から8.0に上げても、対策にはならない。

同じ日、レンタルサーバーのロリポップは、契約者のサーバー全体のPHPを修正版に入れ替えていました。8.2以降で動いていたサイトは、それで対象から外れます。逆に言えば、サイトごとに今どの版で動いているかを知らないと、安全かどうかも言えない。

ここで初めて、どのサイトがどこにあるかの一覧が会社に無いと分かりました。まず数えるところから。

棚卸しの結果、ドメイン46個・サーバー会社5社に散らばっていた

46個。ドメインの契約を全部並べた数です。

そこから、DNS（ドメインとサーバーをつなぐ住所録）をたどり、サーバーに入れたものから中身を確かめていきました。中身を確かめた31サイトの置き場所は、ロリポップ、GMO、AWS、さくらインターネット、ヘテムルの5社。同じロリポップでもアカウントが分かれていて、入り方がすぐには分からないサーバーもありました。

PHPの版は5.2から8.5まで

31サイトのPHPの版を並べると、こうなりました。一番古い5.2は、2011年に出た版です。

PHP 5.26サイト

PHP 7.411サイト

PHP 8.28サイト

PHP 8.41サイト

PHP 8.51サイト

PHPを使っていない4サイト（HTMLだけ）

7.4が11サイトと一番多い。サーバーによっては版をサーバー単位でしか選べず、1つのサーバーに載った6サイトがそろって7.4のまま、という所もありました。サイトを1つずつ見ていても、古くなるときはまとめて古くなる。

WordPressは3.5から7.1まで、半分が4系

WordPressは20個見つかりました。使われていない置きっぱなしのものも含めた数です。

10個が4系。2016年に出た4.5のまま、ずっと更新されていないものもありました。PHPを上げれば古いテーマが止まり、上げなければ穴が残る。どちらにも動けないまま、何年も置かれていたわけです。

古いWordPressは時代遅れなのか。31サイトを更新・静的化・移転・停止に振り分けた

「WordPressはもう時代遅れなんですか」と聞かれることがある。

私の答えは、更新を続けるならWordPressのままでいい、です。時代遅れなのはWordPressではなく、何年も更新していない版のほうでした。

振り分けの基準は、担当の方への質問1つだけ。このサイトを、これから誰かが更新しますか。

これから更新するか更新するなら、WordPressのままPHPと本体を最新にする。

今のサーバーで最新にできるかできないなら、新しいサーバーへ移してから最新にする。

更新しないが、見に来る人はいるかいるなら、HTMLに書き出してPHPを使わない置き場所へ移す。

誰も見ていないか中身を保管してから止める。

結果はこうです。

確認だけで済んだ14サイトは、ロリポップの8.2以降で動いていたものと、もともとHTMLだけのものです。もとから新しい版に上げてあったサイトは、今回は何もしなくてよかった。古いサイトの放置は、こういう日に差が出ます。

PHP 8に上げると、古い書き方で止まる

会社のサイトはWordPressのまま、PHPを7.4から8.4に上げました。上げた直後、35ページが表示されなくなりました。原因はテーマの中の古い書き方で、PHP 7までは見逃されていた書き方が、8では止まる扱いになります。直したファイルは25個。そのあと全845ページを切り替え前と比べ、全部一致するのを確かめてから公開に戻しています。

上げる前に古い書き方を検索で洗い出し、上げたら全ページを比べる。この順番を外すと、どこかのページが黙って真っ白になったまま残ります。

移したあとに12時間止まったサイト

AWSの新しいサーバーへ移したサイトでは、移した5日後に事故がありました。10月27日の朝、外からの機械的なアクセスが続き、Webサーバーの処理が150まで増えてメモリが足りなくなった。データベースが強制的に止められ、自動で立ち上がる設定になっていなかったので、そのまま12時間止まっていました。同時に動かす処理の上限を12に下げ、データベースが落ちても5秒で立ち上がるように直しています。

移して最新にしたら終わり、ではない。小さなサーバーほど、混んだときの上限を決めておく必要がありました。

静的化したら、全ページを今のサイトと1つずつ比べた

静的化は、WordPressなどが毎回作っているページを、HTMLのファイルとして書き出しておくことです。

書き出したファイルを置くだけなので、置き場所でPHPを動かす必要がありません。今回の脆弱性のようなPHPの穴は、そもそも関係なくなる。置き場所にしたCloudflare Pagesは、この規模なら費用がかかりません。

その代わり、書き出し漏れが怖い。そこで、仮のURLに上げたものと今のサイトを、全ページで比べました。

比べたのは、ページが開けるかと題名です。サイトマップ（サイト内のページの一覧）に載っているURLが全部入っているかも、合わせて突き合わせました。

静的化でつまずいたこと

一致させるまでに、引っかかったところが3つあります。

1つ目は、存在しないページの扱い。Cloudflare Pagesは404.html（ページが見つからないときの画面）を置かないと、どんなURLにもトップページを返します。消したはずのページが全部トップに見えてしまうので、必ず置く。

2つ目は、WordPressが付けるファイル名の後ろの記号です。CSSや画像の名前の後ろに版の番号が付いていて、書き出すとその番号ごと別の名前になる。戻さないまま切り替えると、見た目のCSSが読めなくなります。

3つ目は、ページの中の画像がサイトの住所を直接指していること。仮のURLで見ても画像は今のサイトから出てくるので、見た目では確かめになりません。画像やCSSが書き出しの中に入っているかを、ファイルの側で数えました。

マカオの案内サイトの奥からは、279MBの動画ファイルが出てきました。新しい置き場所の1ファイルの上限は25MB。どうしようかと思ったら、そもそも使われていないファイルでした。置いていきます。

サーバーを移転するときに、一番止まりやすいのはメール

サイトは移したのに、メールが届かなくなる。サーバー移行で一番起きやすい事故です。ホームページとメールは、同じドメインの名前を使っていても別々の行き先を持っています。メールの行き先はMXレコードという設定で決まり、今回のいくつかのドメインでは、それがwwwの付かないドメインそのものを向いていました。そこを新しい置き場所に向けると、メールも一緒に新しい置き場所へ行こうとして、受け取る相手がいない。

そこで、メール用に mail. で始まる別の名前を作って元のサーバーへ向け、メールの行き先をそちらに付け替えてから、ホームページだけを移しました。

満杯の箱が、問い合わせフォームの送り先だった

さくらインターネットのサーバーでは、メールそのものを調べています。

満杯の箱には、新しいメールはもう入らない。届いても受け取れずに戻っていきます。そして、預かっているお客さまのサイトの1つで、問い合わせフォームの送り先がまさにこの箱でした。

フォームから送った人には「送信しました」と出る。けれど、誰も読まない箱に向かっていた。

移すときに、フォームの送り先は会社で決めた受付用のアドレスにまとめ、お客さまのサイトは送り先をどうするか相談しています。メールを使っていないことが分かったので、このサーバーは解約すればメールも止まってよい、という判断にもなりました。

誰も使っていないサーバーに、毎年払っていた

年20,512円。さくらインターネットのVPS（借りた仮想のサーバー）の、1年分の料金です。

契約は2013年から続いていました。担当の方に聞くと「使っていない。解約でよい」。何が入っているのかは、最後まで分からないままでした。同じ会員の中には、6サイトが載ったレンタルサーバーの契約も年6,600円で続いていて、こちらは静的化が終わったら解約します。

AWSにも、どのサーバーにもつながっていない固定のIPアドレスが残っていて、これも課金が続く設定でした。金額は小さい。それでも、何に払っているか分からない請求が残っていると、次に何かあったとき、どこを見ればいいのかが分からなくなります。

計測を見たら、問い合わせが0件になっていた

0件。貸切バスの予約サイトの、GA4（Googleの無料のアクセス解析）の問い合わせの数です。180日さかのぼっても0件でした。

ところが、同じサイトの直近90日で、問い合わせフォームを開いた回数は1,238回ありました。開いた人が1人も送っていない、とは考えにくい。

調べると、フォームの確認ページと送信完了ページに、GA4のタグが入っていませんでした。サイトに残っていた、もう終わった古い版の計測タグ（ユニバーサルアナリティクス）が、GA4にページを見た数だけを送っていた。問い合わせを数える仕組みは、どこにもつながっていなかった。10月24日に完了ページへ計測を入れ、送信の数はそこから取れるようになりました。

逆向きの例もある。別のサイトでは、9月18日から10月28日まで、訪問も問い合わせも全部2倍に数えられていました。誰かが同じサイト用の受け口をもう1つ作り、両方に送る形になっていたためです。

数字が0でも2倍でも、管理画面はそれらしく見えてしまう。サイトごとの計測の箱、GA4のプロパティ29個も、名前がURLのままで、どれがどのサイトか分かりにくかったので、サイト名に付け直しました。

計測の入れ方の手順はGoogle広告のコンバージョン設定にも書いています。

古いホームページを何本も持っている会社が、最初にやること

脆弱性の知らせが来てから慌てないために、平時にやっておくことを並べます。

• 持っているドメインを全部書き出した（ドメイン会社の管理画面の一覧から）
• ドメインごとに、ホームページの置き場所のサーバー会社が分かる
• サイトごとのPHPの版と、WordPressの版が分かる
• サーバー会社の管理画面に、会社の人がログインできる
• これから更新するサイトか、もう更新しないサイトかを決めてある
• メールをどのサーバーで受けているか、そのメールを使っているかが分かる
• 問い合わせフォームの送り先が、今読んでいるアドレスになっている
• フォームから送ったとき、GA4で1件として数えられる
• 使っていないサーバーやIPアドレスの請求が残っていない

さくらツーリストでは、この一覧づくりに一番時間がかかりました。サイトを直す作業より、どこに何があるかを突き止めるほうが長い。全部のチェックが埋まらなくても、埋まらなかった項目が、そのまま次にやることの一覧になる。

ふだんの保守で何をするかと、作り直すかどうかの判断は、別の記事に書いた。WordPressの保守運用とWordPressサイトのリニューアルの2本。

私は今回、サイトの置き場所とPHPの版の洗い出しから、WordPressとPHPの更新、静的化と全ページの比較、サーバーとメールの切り替え、GA4の入れ直しまでを一人で通して進めています。何本ものサイトをまとめて見直したいときの進め方は、ホームページ保守のページに書いています。