PHPの重大な脆弱性で見直したい、WordPressの安全なアップデート手順〜EC事業者向けチェックリスト付き〜

こんにちは！３号機です。

スマホの画面に出てくる「今夜アップデートしますか？」の通知。あれ、毎回なんとなく「あとで」を押してしまいませんか。私は押します。押し続けます。今日は疲れてるから「あとで」、明日は朝早いから「あとで」、週末こそはと思いながら、気づけば週末も「あとで」。もはや「あとで」が指に染みついていて、通知が出た瞬間に反射で押している自分がいます。動体視力が鍛えられます。

そんなある日、ふだん使っているアプリを開いたら「最新バージョンにアップデートしてください」と、うんともすんとも動かなくなりました。慌ててアップデートボタンを押すと、今度は「OSが古いため、このバージョンはインストールできません」。いやいや、ちょっと待ってくれと。こっちは今すぐ使いたいんやと。結局、溜めに溜めたOSのアップデートを一気に走らせることになり、夜の自宅でぐるぐる回る進捗バーを見つめながら、「あとで」の積み重ねが一番あとで困るのだと、身をもって学んだのでした。

てなわけで、今回は「WordPressのアップデート」についてのお話です。

はじめに〜PHPの重大な脆弱性で考える、サイトの「あとで」〜
ECとWordPress〜意外と身近なシステムです〜
まずは確認しよう〜今のPHPとWordPressのバージョン〜
- WordPressの「サイトヘルス」で確認する
- PHPのサポート期限を知っておこう
安全なアップデートの手順〜6つのステップ〜
つまずきやすいポイント〜ここで止まりがち〜
ついでに見直したいセキュリティ〜控えファイルと管理者アカウント〜
- 設定ファイルの「控え」を公開フォルダに置かない
- 管理者アカウントの棚卸し
EC運営者向け〜アップデート前後のチェックリスト〜
さいごに〜「あとで」は一番あとで困る〜

はじめに〜PHPの重大な脆弱性で考える、サイトの「あとで」〜

2026年10月、PHPに重大な脆弱性が見つかり、修正版が公開されました。
PHPというのは、WordPressを動かしているプログラミング言語のこと。つまり、WordPressで作られたサイトはすべて、この影響を受ける可能性があったわけです。

今回の脆弱性は、ログインなどをしなくても、外部からサーバー上でプログラムを動かされるおそれがあるというもの。開発元が前日にわざわざ「明日、重大な修正を出します」と予告するほどで、WordPressでサイトを運営している企業やお店のあいだでも「うちは大丈夫かいな！？」とちょっとした騒ぎになりました。

公表日：2026年10月21日（前日に事前予告）
内容：認証なしで、外部からプログラムを実行されるおそれがある脆弱性が2件
修正版：PHP 8.5.12 ／ 8.4.27 ／ 8.3.36 ／ 8.2.35
PHP 8.1以前：開発元のサポートが終わっているため、通常の更新対象外

多くのレンタルサーバーでは修正版への切り替えが進められていますが、サーバーの設定で古いPHPを選んだままのサイトは、その恩恵を受けられないこともあります。

この記事では、今回の件をきっかけに、WordPressのPHP・本体・テーマ・プラグインを、サイトを止めずに安全に更新する手順をまとめました。私たちが日頃のサイトメンテナンスで実際に踏んでいる手順をもとにしています。

WooCommerceなどでネットショップを運営している店舗さまや、ブランドサイト・LP・ブログ・採用ページをWordPressで運営しているEC事業者さまは、ぜひ参考にしてみてください。

ECとWordPress〜意外と身近なシステムです〜

EC事業者にとって、WordPressは意外と身近な存在です。

自社ECサイト（WooCommerceなど）
ブランドサイト、商品LP、キャンペーンページ
オウンドメディア、ブログ
お問い合わせフォーム、資料請求、採用ページ

楽天市場やAmazonで販売していても、集客の入口や信用の土台としてWordPressのサイトを持っているお店は多いのではないでしょうか。

このサイトが止まれば機会損失、改ざんされればお客さまからの信用に関わりますし、ECサイトであれば個人情報や決済にも関わってきます。
「ちゃんと表示されているから大丈夫」ではなく、中身のバージョンを定期的に確認して更新しておくこと。地味ですが、これがお店を守る基本なんですね。

まずは確認しよう〜今のPHPとWordPressのバージョン〜

WordPressの「サイトヘルス」で確認する

管理画面の「ツール」→「サイトヘルス」→「情報」タブを開くと、次の項目が確認できます。

WordPress：WordPressのバージョン
サーバー：PHPのバージョン
データベース：MySQL・MariaDBのバージョン

「ステータス」タブに「改善が必要」と出ている場合は、その中身もあわせてチェックしておきましょう。

PHPのサポート期限を知っておこう

PHPは、リリースから約4年でサポートが終了します。2026年11月時点のサポート状況はこちらです。

PHPのバージョン	セキュリティ修正の期限	状況
8.1以前	終了済み	早めの移行が必要
8.2	2026年12月31日	まもなく終了
8.3	2027年12月31日	サポート中
8.4	2028年12月31日	サポート中
8.5	2029年12月31日	サポート中

WordPress公式も、PHP 8.3以上、MariaDB 10.11以上またはMySQL 8.0以上の環境を推奨しています。PHP 8.2を使っているサイトも、年内に次の移行を計画しておくと安心です。

安全なアップデートの手順〜6つのステップ〜

ここからが本題です。私たちが実際に行っている手順を、順番に紹介していきます。

バックアップを取る
テスト環境で試す
自動更新を一時停止する
本体 → テーマ → プラグイン → PHPの順に更新する
全体を確認する
後片付けをする

① バックアップを取る

何よりも先に、データベースとファイルの両方をバックアップします。
多くのレンタルサーバーには、管理パネルからデータベースを書き出す機能や、過去の自動バックアップから戻す機能がありますので、まずはそれを確認しましょう。

バックアップしたファイルは、サイトの公開フォルダの中ではなく、手元のパソコンなど外から見えない場所に保管してください（理由は後半でお話しします）。

② テスト環境で試す

いきなり本番サイトを更新するのではなく、本番とそっくりのテスト環境で、先に同じ更新を試します。
手元のパソコン（MAMP、Localなど）や、サーバーのサブドメインに本番のコピーを作るのが一般的です。

テスト環境を作るときは、次の3つに気をつけましょう。

パスワードをかける：Basic認証などで、関係者以外が見られないようにします。
検索エンジンに載せない：本番と同じ内容のページが、検索結果に出てしまわないようにします。
メールや外部への送信を止める：テスト中に、お客さまへメールが届いたり、注文データが外部に送られたりしないようにします。

検索エンジンに載せない設定は、テスト環境の「.htaccess」というファイルに、次の1行を足すのが手軽です（本番には入れないでくださいね）。

Header set X-Robots-Tag "noindex, nofollow"

③ 自動更新を一時停止する

作業中にプラグインが勝手に更新されてしまうと、どの変更で不具合が出たのか分からなくなってしまいます。
そこで作業期間だけ、「wp-config.php」というファイルで自動更新を止めておきます。

/* 更新作業が終わるまで自動更新を止める（作業後に必ず見直す） */
define( 'AUTOMATIC_UPDATER_DISABLED', true );

あわせて、エラーの内容が画面に表示されない設定になっているかも確認しておきましょう。エラー表示にはサーバー内のファイルの場所などが含まれるので、本番では表示しないのが基本です。

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

④ 本体 → テーマ → プラグイン → PHPの順に更新する

ここがいちばん大事なところ。更新する順番です。

WordPress本体を更新（PHPは今のまま）
テーマを更新（親テーマの更新、子テーマの修正）
プラグインを更新（使っていないものは停止・削除）
最後にPHPを新しいバージョンに切り替える

なぜPHPを最後にするのか。理由は2つあります。

ひとつは、古いプラグインやテーマは、新しいPHPで動かないことがあるから。先に中身を新しくしておくことで、トラブルを減らせます。
もうひとつは、PHPの切り替えはサーバーの管理パネルからすぐに元へ戻せるから。万が一表示がおかしくなっても、最短で復旧できるんです。

ただし、新しい版のプラグインの中には「PHP 8.2以上が必要」といったものもあり、古いPHPのままでは更新できないことがあります。その場合は、PHPを切り替えた直後に更新しましょう。

３号機

たとえばCocoonを使っている場合、カスタマイズは子テーマに入れておき、親テーマのCocoonは公式の更新版に差し替えるのが基本です。親テーマを直接いじっていると、更新のたびに変更が消えてしまうのでご注意を！

⑤ 全体を確認する

更新が終わったら、見た目だけでなく「動き」まで確認します。

トップ、商品・サービスページ、ブログ記事、カテゴリ一覧、検索、ページ送りが表示されるか
お問い合わせ・資料請求フォームから、実際に送信して受信できるか
アクセス解析や広告の計測タグ（GA4、Meta広告など）が動いているか
管理画面で、記事の作成・編集・画像のアップロードができるか
サーバーのエラーログに、新しいエラーが出ていないか
サイトヘルスに「重大な問題」が出ていないか

ページ数が多いサイトは、サイトマップに載っているURLをひと通り開いて、エラーになるページがないかを確認するのがおすすめです。

⑥ 後片付けをする

最後に、使わなくなったものを片付けます。

停止したプラグイン、使っていないテーマを削除する
テスト環境を削除する（放置すると、それ自体が攻撃の入口になります）
自動更新の方針を決めて、設定を戻す

自動更新は、WordPress本体のセキュリティ更新（小さな更新）だけ自動にして、プラグインやテーマは月に1回くらい手動で確認して更新する、という運用がバランスがよいと思います。

/* 本体のセキュリティ更新（マイナー更新）だけ自動にする */
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

つまずきやすいポイント〜ここで止まりがち〜

古いテーマ・自作テーマのPHPエラー

何年も前に作ったテーマや、自作のテンプレートは、新しいPHPでエラーになることがあります。よくある例をいくつか紹介します。

例1：存在しない値を読もうとしてエラーになる

/* 修正前 */
$post_type = $wp_query->query['post_type'];

/* 修正後：値がないときは空にする */
$post_type = $wp_query->query['post_type'] ?? '';

例2：同じ設定値を2回作ろうとしてエラーになる

/* 修正前 */
define( 'PAGE_1ST', 11 );

/* 修正後：まだ作られていないときだけ作る */
defined( 'PAGE_1ST' ) || define( 'PAGE_1ST', 11 );

例3：WordPressで廃止された関数を使っている

/* 修正前（廃止された関数） */
echo get_avatar( get_the_author_id(), 63 );

/* 修正後 */
echo get_avatar( get_the_author_meta( 'ID' ), 63 );

テスト環境で「WP_DEBUG」を有効にして、ログ（wp-content/debug.log）に出たエラーをひとつずつ直していくと効率的です。

有料プラグインのライセンス切れ

有料プラグインは、ライセンスが切れていると更新できません。
アップデートを機に、本当に有料版が必要なのか、無料の後継プラグインや代わりのプラグインで足りないか、見直してみるのもおすすめです。

使っていないプラグインが残っている

停止しているだけのプラグインも、サーバー上にファイルが残っている限り、脆弱性の原因になりえます。
使っていないフォームプラグインやSNS連携プラグインなどは、思い切って削除しちゃいましょう。

ついでに見直したいセキュリティ〜控えファイルと管理者アカウント〜

アップデート作業は、サイトの中を見直すよい機会です。あわせて次の点も確認しておくと安心です。

設定ファイルの「控え」を公開フォルダに置かない

「wp-config.php」には、データベースのパスワードなど、大切な情報が書かれています。
作業前に「念のため」とコピーした「wp-config.php.bak」や「wp-config.old」のようなファイルが公開フォルダに残っていると、URLを開くだけで中身を読まれてしまうことがあります。

実際、こうした控えファイルの名前を順番に試して回る自動ツールのアクセスは、多くのサイトに毎日のように届いています。控えは手元のパソコンに保存して、サーバー上には置かないようにしましょう。
念のため、「.htaccess」で控えファイルを見られないようにしておくこともできます。

# 設定ファイルや控えファイルへのアクセスを拒否する
<FilesMatch "(^wp-config|\.(bak|old|orig|save|swp)$|~$)">
  Require all denied
</FilesMatch>

.htaccessを触るときの注意
書き方を間違えると、サイト全体が表示されなくなることがあります。必ずテスト環境で確認してから、本番に反映してくださいね。

管理者アカウントの棚卸し

見覚えのない管理者アカウントがないか
退職者や、契約が終わった外部パートナーのアカウントが残っていないか
管理者権限が、必要以上の人に付いていないか

EC運営者向け〜アップデート前後のチェックリスト〜

WooCommerceなどでネットショップを運営している場合は、通常のサイトよりも確認しておきたいことが増えます。

セール・キャンペーン期間を避けて、アクセスの少ない時間帯に作業する
作業日時を社内に共有し、作業中は商品登録や記事更新を止めてもらう
テスト環境では、決済をテストモードにしておく（実際の決済が走らないように）
カート投入から注文完了まで、実際の流れをひと通り試す
注文確認メールや発送メールなど、自動メールが届くか確認する
在庫連携、受注管理システム、モール連携など、外部との連携が動いているか確認する
広告や計測のタグ（GA4、Meta広告、Clarityなど）が動いているか確認する
お問い合わせフォームから、実際に送信して受信できるか確認する

楽天市場やYahoo!ショッピングなどのモール店舗さまでも、外部の受注管理ツールや自社サイトとの連携でPHPが使われていることがあります。
「自社で管理しているサーバーやツールがあるか」を、この機会に一度洗い出してみてください。

さいごに〜「あとで」は一番あとで困る〜

今回のPHPの脆弱性は、「サーバーやWordPressの更新は、何か起きてからでは遅い」ということを、あらためて感じさせる出来事でした。

まずはサイトヘルスで、PHPとWordPressのバージョンを確認すること。
更新するときは、バックアップ → テスト環境 → 本体 → テーマ → プラグイン → PHPの順番で。
更新したあとは、見た目だけでなく、フォームや計測などの「動き」まで確認すること。
そして、使っていないプラグインや、設定ファイルの控えを残さないこと。

どれも地味な作業ですが、お店の信用を裏側でそっと支えてくれる大事なメンテナンスです。

ちなみに私のスマホは、あの夜以来、通知が出たらその日のうちにアップデートしています。進捗バーを見つめる夜は、もうこりごり。「あとで」より「いま」！アップデートは、思い立ったが吉日なのです。

※2026年11月時点の情報です。PHP公式サイトのセキュリティ情報・サポート期限、WordPress公式の動作環境を確認して整理しています。サーバーの画面や設定方法は、お使いのレンタルサーバーによって異なります。作業前には、各サーバー会社のマニュアルも必ずご確認ください。

参考：
PHP公式サイト：News Archive（2026年）
PHP公式サイト：Supported Versions
WordPress公式：Requirements（動作環境）