お役立ち情報
お客様のビジネスを、
WEBでええ感じに
お客様のビジネスを、
WEBでええ感じに
「PHPに重大な脆弱性が見つかった」「レンタルサーバーの管理画面がメンテナンス中」――2026年10月21日ごろから、こんなニュースを見て不安になった方も多いのではないでしょうか。
私も実際に運用中のお客様のWordPressサイトを管理しているので、今回のニュースをきっかけに、改めてPHPのバージョンや更新方法を確認しました。
でも、PHPのバージョンアップって、正直ちょっと怖くないですか？
今回は、そんな不安を一つずつ解消しながら、企業のWordPressサイトをPHP 7.4.33から8.3.36へ更新しました。この記事では、まず「そもそも何が起きたのか」をやさしく整理し、そのうえで実際に行った安全性を重視した手順を全部紹介します。
※2026年10月24日時点に確認できた情報をもとにしています。掲載するお客様の作業画面は、会社名・ドメイン・サーバーID・記事内容などを匿名化しています。
まずは、今回ニュースで騒がれているPHPの脆弱性が見つかった騒動は、「なぜ起きているのか？」から御説明します。
PHPは、WordPressなどのWebサイトを裏側で動かしているプログラミング言語です。
たとえばWordPressを「建物」にたとえるなら、見えているデザインや記事が内装、PHPはその裏で働く設備のようなもの。普段は意識しなくても、ログインや記事の表示、お問い合わせ処理などを支えています。
なので、PHPに大きな問題が見つかると、WordPressを使っているサイトにも影響する可能性があります。
今回、PHPの内部処理に次の2件の脆弱性が見つかり、修正版が公開されました。
CVE-2026-109618：メモリ不足が起きたときの処理に問題があるCVE-2026-109619：処理を終えたはずの古い情報が残ってしまう場合があるどちらも深刻度は10点満点中9.2。条件がそろうと、ログインしていない第三者が遠隔から不正なプログラムを実行できるおそれがあります。
言い換えると、建物の中へ入るための鍵を持っていない相手にも、裏側の設備を勝手に操作される可能性がある、という問題です。
ただし、「この脆弱性がある＝すでにサイトが乗っ取られている」という意味ではありません。実際の危険性は、PHPのバージョン・サーバーの構成・適用済みの修正などによって変わります。
出典：PHP公式・2026年10月21日のセキュリティ情報／CERT-EUによる注意喚起
PHP公式が今回の2件を修正したバージョンは、次のとおりです。
| PHPの系列 | 修正済みのバージョン |
|---|---|
| PHP 8.2系 | 8.2.35以降 |
| PHP 8.3系 | 8.3.36以降 |
| PHP 8.4系 | 8.4.27以降 |
| PHP 8.5系 | 8.5.12以降 |
※あくまで2026年10月21日に公開された2件についての修正バージョンです。PHP 8.1以前は公式サポートが終了しているため、レンタルサーバー会社が独自に修正パッチを適用している場合があります。「PHP 7.4.33だから今回の穴は未対策」と、バージョン番号だけでは断定できません。
今回、個人的に「これは本当にありがたい対応だな」と思ったのがエックスサーバーです。
PHPの修正版が出る前から予防的な対策を行い、10月21日には管理画面などへのアクセスを一時停止。利用者のWebサイト表示やメールの送受信は継続したまま、安全対策を進めてくれました。
さらに、通常は公式の更新が提供されないPHP 7.4などの古い系列に対しても、独自の修正パッチを適用しています。
主な対応の流れをまとめると、こんな感じです。
| 日時（日本時間） | エックスサーバーの対応 |
|---|---|
| 10月21日・12時まで | 公表前から予防的な緩和措置を適用 |
| 10月21日・16時 | 予防的措置として管理画面等を一時停止 |
| 10月21日・23時ごろ | PHP公式の修正版公開を受け、対応を進行 |
| 10月22日・6時45分 | PHP 8.2〜8.5の対象サーバーへの修正適用完了 |
| 10月22日・12時 | PHP 7.4〜8.1の対象サーバーへの修正適用完了 |
| 10月22日・14時 | PHP 5.6〜7.3の対象サーバーへの修正適用完了 |
| 10月22日・20時10分〜 | サービスサイトを順次再開 |
出典：エックスサーバー公式によるメンテナンス・パッチ適用のお知らせ
ここは誤解しやすいので、はっきり区別します。
エックスサーバー公式によれば、同社が管理するレンタルサーバーサービスでは、PHP 5.6〜8.5の対象サーバーへの今回の脆弱性の修正パッチ適用が完了しています。そのため、これらのPHPを利用している場合、今回の脆弱性だけを理由に急いでPHPのバージョンを変更する必要はない、と案内されています。
ただし、これは「古いPHPをずっと使っていても大丈夫」という意味ではありません。公式サポートが終了した系列を使い続けると、今後の別の脆弱性やプラグインとの互換性が問題になります。
また、XServer VPSなど自分でOSやPHPを管理するサービスには、自動的に修正パッチが適用されません。利用しているサービスの種類を確認してください。
もしホームページを「見るだけ」の方なら、普段お使いのスマートフォンやPCでPHPを更新する必要は基本的にありません。
一方、WordPressサイトを運用・保守している人は、次の順番で確認しましょう。
「焦っていきなり更新する」のではなく、「自分の環境が対策済みか確認し、必要な更新を安全に進める」のがポイントです。
今回のお客様のサイトはPHP 7.4.33でした。エックスサーバーによる今回の脆弱性対策は実施されていましたが、PHP 7.4自体はすでに公式サポートが終了しています。
今回の脆弱性をしのぐだけでなく、今後も安心してWordPressを運用していただくため、これを機にサーバーが「推奨」と表示していたPHP 8.3.36へ移行することにしました。
ただし、運用中のWordPressには、テーマ・プラグイン・カスタムフィールドなどが組み込まれています。PHPを一気に変更すると、サイトが崩れたり、一部の機能が動かなくなったりする可能性があります。
だからこそ、今回選んだのは「事前にバックアップを取得し、本番サイトをコピーしたテスト環境で検証してから、本番を変更する」方法です。
ここから、実際に行った作業を順番に紹介します。初めての方は、まずはご自身のサイトでバックアップの取得と復元を練習してから実践してみてください。
STEP1：現在のPHPバージョンを確認する
STEP2：WordPress側・サーバー側のバックアップを確保する
STEP3：本番サイトのコピーでテスト環境を作る
STEP4：BASIC認証でテスト環境へのアクセスを制限する
STEP5：テスト環境のSSLを整える
STEP6：テスト環境だけPHP 8.3へ更新する
STEP7：投稿や独自機能まで動作検証する
STEP8：WordPressのサイトヘルスを確認する
STEP9：サーバーのエラーログを確認する
STEP10：問題がなければ本番環境を更新する
エックスサーバーのサーバーパネルを開き、「PHP」→「PHP Ver.切替」へ進みます。更新するドメインの行で、現在のバージョンを確認しましょう。
今回の例では、更新前はPHP 7.4.33でした。右端の鉛筆マークを押すと選択可能なバージョンが一覧で表示されます。
サーバー側で「PHP 8.3.36（推奨）」が表示されたため、今回はこのバージョンをテスト対象にしました。「最新」と書かれたものを無条件で選ぶのではなく、WordPress本体・テーマ・プラグインとの互換性を確認して更新先を決めます。
この時点で「設定する」は押しません。まずは情報を確認するだけです。
ここは絶対に飛ばさないでください。
バックアップは、できれば「WordPress側」と「サーバー側」の両方で取得します。また、WordPressのデータは大きく分けて次の2種類です。
wp-config.php などサーバーのWeb領域をバックアップしただけでは、MySQLデータベースが含まれない場合があります。エックスサーバーの「サーバー領域データ」と「MySQLバックアップ」は、別々に確認してください。逆に、利用するバックアップ機能が両方をまとめて取得する方式なら、対象と復元範囲を確かめることが重要です。
使用しているバックアッププラグインなどで、ファイルとデータベースを含むバックアップを取得します。バックアップファイルの保存先、容量、エラーの有無も確認します。同じサーバー上だけでなく、可能であれば別の安全な場所にも保管しましょう。
サーバーパネルで「自動バックアップの取得・復元」を開き、取得対象日と対象ドメインを確認します。実際に作業前のバックアップデータを取得し、履歴が「正常終了」になったことまで確認しました。
なお、エックスサーバーで取得したWeb領域のバックアップは、/userbackup に置かれる場合があります。この取得済みデータは一定時間（公式案内では24時間）で自動削除されるため、「取得できた＝永久に保存された」ではありません。自動バックアップの保持期間もプラン・サーバーによって確認が必要です。
これは強くお伝えしたいことです。
「バックアップを取ったことがある」と「バックアップから復元できる」は別物です。
初めてサーバー作業をする方は、いきなりお客様のサイトで操作しないでください。まずは自分のテストサイトで、ファイルとデータベースをバックアップし、別の検証環境に復元して、正常に表示されることまで試してください。
復元すると既存データが上書きされる場合があるため、復元テストをお客様の本番サイトで行うのもNGです。「戻し方を知っている」状態になってから作業しましょう。
ここが今回の作業の核心です。エックスサーバーの「WordPress簡単インストール」にあるサイトコピー機能を利用しました。
サーバーパネル → 「WordPress」→「WordPress簡単インストール」を開きます。本番サイトの行を探して「詳細」をクリックします。
詳細画面の「＋コピー」をクリック。「コピー対象」は、投稿・画像なども確認したいので「全て」を選択します。
コピー先は、本番とPHPバージョンを分けて設定できる別ドメインにします。今回は、エックスサーバーの初期ドメインの空ディレクトリを使用しました。
この段階で、必ず以下を確認してください。
「コピーする」を実行後、コピー先サイトが一覧に追加され、新しいデータベースが用意されていることを確認します。
今回は本番とは異なるデータベースになっていました。これにより、検証中に記事などを保存しても本番のデータベースを直接書き換えない構成にできました。
ただし、コピー機能によっては一部ファイル・URLの置換が対象外の場合があります。コピー後に表示を確認し、メール送信や外部API連携、決済、解析タグなどが本番とつながったままになっていないか注意してください。
さくらのレンタルサーバーには、対応プランで「バックアップ＆ステージング（SnapUP）」という機能があります。エックスサーバーのコピー機能とは画面が異なりますが、考え方は同じです。
WordPress用スナップショットにはデータベースも含まれます。ただし、利用条件・対応構成・メンテナンス状況には制限があります。ステージング環境は公式案内では作成後90日で自動削除されます。
参考：WordPressのスナップショット作成／ステージングサーバー作成
コピー直後のサイトを誰でも見られる状態で放置するのは避けましょう。エックスサーバーでは「ホームページ」→「アクセス制限」で、検証用ディレクトリにだけBASIC認証を設定できます。
「ユーザー設定」から「＋ユーザーIDを追加」を選び、テスト用のID・強いパスワードを登録します。
対象フォルダのアクセス制限を「ON」にします。本番サイトのフォルダを選ばないように注意してください。
シークレットウィンドウで検証用URLにアクセスし、認証画面が表示されるかを確認します。WordPressの「設定」→「表示設定」で「検索エンジンがサイトをインデックスしないようにする」にチェックも入れておくと、認証を解除した場合への補助対策になります。ただし、noindexはアクセス制限の代わりにはなりません。
今回、テスト用URLに初めてアクセスしたとき、SSL証明書のエラーが出ました。これはWordPressやPHPの異常ではなく、検証用ドメインのSSL設定が未完了だったためです。
サーバーパネルの「ドメイン」→「SSL設定」で、検証用ドメインのSSLをONにします。
ここで焦らないことも大事です。WordPressのコピー処理、SSL証明書の反映、ドメインやDNSの反映には時間がかかることがあります。作業条件によっては一日で終わらないこともあります。エラーが出たからといって、すぐ設定を何度も変更せず、まず「反映待ち」かどうか確認しましょう。
BASIC認証のID・パスワードを入力する場合は、SSLが正しく反映されたHTTPS接続で確認します。
いよいよPHPを変更します。ただし、ここでも本番サイトはまだ触りません。
「PHP」→「PHP Ver.切替」で、検証用ドメインの鉛筆マークをクリックし、今回は「PHP 8.3.36」を選択しました。
変更後は、検証用ドメインだけPHP 8.3系になり、本番ドメインはPHP 7.4系のままです。
ここではブラウザでテストサイトを表示して、真っ白な画面・500エラー・レイアウト崩れがないか確認します。もし表示できなくなった場合は、まずテスト環境のPHPを元のバージョンに戻し、PHPエラーや互換性を調べます。本番にはまだ影響させません。
サイトのトップページが表示されたら、ひとまず第一関門はクリア。ただし、それだけで更新成功とは言えません。
例えば、記事の編集やフォーム送信で初めてエラーが発生することもあります。今回の検証では、次の機能までチェックしました。
「カスタム投稿タイプ」とは、標準の「投稿」「固定ページ」とは別に作る独自の投稿機能です。例えば「制作実績」「お客様の声」「商品紹介」などを専用の管理画面で管理する仕組みです。
また、入力項目を自由に追加できる「カスタムフィールド」を使っている場合は、値が表示されるだけでは不十分です。テスト環境で値を編集して保存し、画面を再読み込みして反映されるか確認します。
今回もカスタム投稿タイプの個別ページ表示とカスタムフィールドの編集・保存まで正常に動くことを確認できました。お客様から預かった実データを使って公開記事を不用意に更新するのではなく、検証環境だけで行います。
※編集後の「保存しました」通知そのものを写した画像は手元にないため、ここでは保存ボタンの位置と入力欄の画像を掲載しています。
WordPress管理画面で「ツール」→「サイトヘルス」を開きます。まず「ステータス」で重大な問題が出ていないか確認します。
続いて「情報」→「サーバー」を開くと、WordPressから見た実際のPHPバージョンが確認できます。
今回のテスト環境ではPHP 8.3.36と表示され、サイトヘルスも「良好」になりました。
なお「停止中テーマを削除してください」「キャッシュを使ってください」などの改善提案は、PHP更新の不具合とは限りません。更新前からあった注意点と、PHP更新後に新しく発生した問題を分けて考えましょう。
エックスサーバーなら「アクセス解析」→「エラーログ」から確認できます。まず検証用ドメインを選び、PHP更新や動作確認をした当日のログを見ます。
今回、テスト環境では当日分のエラーログが見つかりませんでした。一方、本番側には別のアクセスに関するApacheのログが残っていました。
具体的には、プラグイン内のフォルダへの直接アクセスが禁止されたログ（AH01276）と、server-status へのアクセスが拒否されたログ（AH01797）でした。どちらも、これだけをもってPHP 8.3の互換性エラーとは判断できません。
逆に、更新直後に PHP Fatal error や Uncaught Error が増えた場合、特定のページで500エラーが出る場合、保存できない場合などは要調査です。ログの有無だけでなく、発生時刻、URL、実際の症状を合わせて確認します。
テスト環境で一通り確認できたら、本番サイトの更新に進みます。
作業前にバックアップの取得日時が最新の状態に近いこと、万一の切り戻し手順、関係者への連絡方法を再確認します。お問い合わせや注文が増え続けるサイトでは、バックアップへ復元すると更新後のデータが失われる可能性にも注意が必要です。
「PHP」→「PHP Ver.切替」で、今度は本番ドメインを選び、テスト済みのPHP 8.3.36へ変更します。
今回の本番更新後には、トップページ・管理画面・カスタム投稿タイプなどを確認したうえで、実際にフォームの送信テストを実施しました。
最後に、通知先担当者へのメール到達、資料リンクの表示、必要に応じてフォーム履歴の保存まで確認すればより確実です。
まずPHPを変更前のバージョンに戻して、正常表示に復帰するか確認します。その上で、テスト環境でテーマ・プラグインの互換性やPHPエラーを調査します。
最初からデータベースを上書き復元するのは避けましょう。復元時点より後のお問い合わせや記事更新などを失う可能性があります。PHPを戻すだけで復旧できるのか、ファイルだけ戻す必要があるのか、切り分けることが大切です。
初心者の方に一番伝えたいのは「怖いから何もしない」でも「勢いで更新する」でもない、ということです。怖さの原因を一つずつ分解して、試せる場所で確認し、それから本番で実行すればいいのです。
PHPの更新は、運用中のサイトほど慎重になります。でも、手順を分ければ過度に怖がる必要はありません。
今回のように「バックアップ → テスト環境でのPHP更新 → 独自機能まで動作検証 → 本番更新 → 本番での送信確認」の順番を守るだけで、トラブルの発見や対処がしやすくなります。
そしてもう一度。初めての方は、ぜひ自分のサイトでバックアップから復元まで練習してみてください。クライアントのサイトを操作するのは、その後です。
「自分で作業するのは不安」「万が一のときに対応できるか心配」という方は、お気軽に合同会社WEBでええじゃないかまでご相談ください。現状のPHPバージョンやサイト構成、バックアップ・テスト環境の可否などを確認し、安全性を重視した更新方法をご提案します。
※本記事は実際の運用サイトでの作業事例を匿名化したものです。どの環境でも不具合が起きないことを保証する手順ではありません。サーバー・テーマ・プラグインの仕様により、必要な検証や手順は変わります。
