WordPressが古いと危険？バージョン確認方法と安全な更新の判断基準

「WordPressに更新通知が出ているけれど、押しても大丈夫でしょうか？」

セキュリティのためには更新が必要。それはわかっていても、長く運用している企業サイトほど、更新で表示が崩れたり、問い合わせフォームが動かなくなったりするのは避けたいものです。

こんにちは。株式会社ウエブルの増子です。私たちは10年以上、WordPressなどのCMSの構築・保守に500サイト以上携わってきました。中には、数年間大きな更新をしていないサイトについてご相談を受けることもあります。

古いWordPressを触るのは怖いから、できれば放っておきたくなりますよね。お気持ちはよくわかります。
でも放っておくと、本体に加えて、利用中のプラグインやテーマまでもが古くなり、様々なリスクを蓄積していくことになります。
ではえいや！と更新（アップデート）してしまえばいいのかというと、それもまた100年分の何かが詰まった玉手箱をあける並のドッキリです。

本来、WordPressは継続的に更新（アップデート）して使うことが原則なのですが、前任者から引き継いだら既に暫く更新されていなかった、制作会社側で更新が止められていたといったケースも散見されます。
暫く更新されていないWordPressについては、いきなり更新（アップデート）をすると、不具合が起こるリスクが大きいので、慎重に計画を立て、バックアップと検証を組み合わせながら更新していくことになります。重大な脆弱性がある場合は対応を急ぐ必要はありますが、焦りは禁物。「古いから全部すぐ更新」「怖いから全部止める」の二択ではなく、状況に応じて段階的に対応をしていきます。

更新が必要な理由を、統計データから考える

Patchstackの2026年版調査によると、2025年にWordPress関連で報告された新たな脆弱性は11,334件。うち1,966件（17％）は、大規模な自動攻撃に使われる可能性が高いと評価されました。

※脆弱性（ぜいじゃくせい）とは、プログラムの不具合などが原因で生じる、セキュリティ上の弱点のことです。攻撃者はこの弱点を突いて、サイトの改ざんや情報の抜き取りを行います。WordPress本体やプラグインで脆弱性が見つかると、多くの場合は開発元が修正版を公開し、更新することで弱点がふさがれます。

さらに、同社が観測した影響の大きい脆弱性の約半数では、公開から24時間以内に悪用の試行が確認されています。特に攻撃が集中した脆弱性群では、活動量を加味した初回攻撃までの中央値は5時間でした。すべての脆弱性が5時間以内に攻撃されるという意味ではありませんが、重大な情報を月次更新まで待ってよいとは限らないことがわかります。

とはいえ、更新で重要なのは数字の新旧だけではありません。今のバージョンが影響を受けるのか、修正版があるのか、その弱点を狙った攻撃がすでに起きているのかが判断材料です。

1．まず本体・プラグイン・テーマ・PHPとデータベースのバージョンを確認する

WordPressの管理画面にログインできる場合は、次の場所を見てみてください。

確認対象	確認できる場所
WordPress本体	ダッシュボード → 更新
プラグイン	プラグイン → インストール済みプラグイン
テーマ	外観 → テーマ（子テーマ利用時は親テーマも）
PHP／データベース	ツール → サイトヘルス → 情報 → サーバー

2026年10月18日時点のWordPress最新版は7.1.3です。WordPress公式は、最後のメジャーリリースを正式なサポート対象とし、古い系列へのセキュリティ修正は保証していません。7.1.3自体もセキュリティ修正を含むリリースです。公開日が変われば最新バージョンも変わるため、その時点の公式情報を確認してください。

PHPについては、WordPress公式が8.3以上を推奨しています。PHP公式では、8.1以前はサポート終了、8.2は2026年12月末まで、8.3は2027年末までセキュリティサポート対象です。

ただし、有料プラグインや独自開発の機能は管理画面に更新通知が出ないこともあります。提供元の案内と照合する必要があります。

バックアップや管理者アカウントなど、バージョン以外に確認しておきたい項目は、「そのWordPress、大丈夫？今すぐ確認したい6つのセキュリティ対策」で紹介しています。

2．使っているバージョンに脆弱性があるか調べる

本体・プラグイン・テーマなどに「更新あり」と表示されていても、新機能なのか、重大なセキュリティ修正なのかはわかりません。そこで名称とバージョンをもとに、公開されている脆弱性情報を調べます。

調査先としては、WordPressの公式更新情報、Patchstack Database、Wordfenceの脆弱性情報、国内のJVN iPediaなどがあります。Wordfence（セキュリティ用のプラグイン）を導入済みなら、スキャン結果の警告も手がかりになります。

確認するのは、次の5点です。

自社が使っているバージョンは影響範囲に含まれるか
修正済みのバージョンは公開されているか
ログインしていない第三者にも悪用可能か
管理者権限の奪取やデータの漏えい、任意のファイル実行などにつながるか
その脆弱性を狙った攻撃が、すでに確認されているか

5つ目の「攻撃が確認されているか」は、自社サイトが攻撃されたかどうかではなく、その脆弱性を狙った攻撃が世の中ですでに観測されているかという意味です。脆弱性データベースの記載や、JPCERT/CCの注意喚起などで確認できます。脆弱性の数が多くても、すべてが同じ危険度ではありません。自社の構成に当てはめて確認することが重要です。

3．更新を急ぐかどうか、どう判断する？

まず、不審な管理者アカウントや改ざんの兆候がある場合は、すでに侵害されている可能性を優先します。更新ボタンを押す前に記録を残し、影響範囲や原因を専門家と調べます。

「侵害の兆候」は、次のような状態として現れます。

覚えのない管理者アカウントがある、または管理者のメールアドレスが変わっている
Googleで「site:自社ドメイン」と検索すると、覚えのない通販・ブランド品などのページが出てくる
スマートフォンで検索結果から開いたときだけ、別のサイトに転送される
Google Search Consoleに、知らない所有者や送信した覚えのないサイトマップが登録されている
「プラグイン」画面の「必須」タブに、入れた覚えのないプラグインがある
画像などを保存するフォルダ（wp-content/uploads）に、PHPファイルが置かれている
ブラウザやGoogleに「危険なサイト」と警告される、またはサーバー会社からマルウェア検知の連絡が来る

なお、セキュリティプラグインから届く「ログイン試行をブロックしました」という通知は、攻撃を防げたという報告です。それだけで侵害されたわけではありません。

侵害の兆候が見当たらなければ、次は、使っているプラグインなどの脆弱性が、すでに攻撃者に狙われているかどうかを見ます。たとえば、自社で使っている問い合わせフォームのプラグインに脆弱性が見つかり、その弱点を突いた攻撃がほかのサイトで実際に起きていると報告されている場合です。自社サイトにまだ被害がなくても、同じプラグインを使っている以上、次に狙われてもおかしくありません。このような場合は、速やかに対応します。修正版があれば、バックアップや必要な動作確認を伴って適用します。修正版がない場合は、問題のある機能の停止・置き換え・暫定防御を検討します。

それ以外の更新は、サポート期限やサイトの重要度を踏まえて計画的に実施します。ただし、まだ攻撃が確認されていない脆弱性でも、危険性が高ければ早急な対応が必要な場合があります。

サイトの状態	基本的な判断
侵害の兆候がある	更新作業に先立ち、記録・影響調査・初動対応を優先
ほかのサイトで攻撃が確認されている、または重大で攻撃に使われやすい脆弱性がある	速やかに影響を評価し、修正・停止・暫定防御を判断
脆弱性はあるが、攻撃はまだほとんど確認されていない	影響範囲と業務リスクを評価し、優先度をつけて更新
更新内容が新機能の追加や軽微な不具合修正だけ（セキュリティ修正を含まない）	急がず、バックアップと検証の手順を含めた計画を立てて更新
PHPなどのサポートが終了している、またはバージョンの組み合わせで更新できない	互換性を確認し、段階的な移行計画を作る

「必ず当日中」「必ず1か月後」と一律に決めるより、脆弱性の深刻さ、公開範囲、個人情報の有無、停止時の影響で判断する方が実務的です。

4．更新でエラーが起きるのはなぜ？

WordPressの更新で問題になりやすいのは、エラーが発生するケース。
本体・プラグイン・テーマ・PHPバージョンの組み合わせが原因となることが多いです。

WordPressでは、本体・PHP・プラグインがそれぞれ「動作に必要なバージョン」を指定しています。たとえばプラグインの最新版が「PHP 8.0以上」を条件にしていると、PHPが古いサイトではそのプラグインを最新版に更新できません。反対にPHPを先に新しくすると、今度は古いプラグインやテーマが動かなくなることがあります。長く更新していないサイトほど、「PHPが古いからプラグインを更新できない」「プラグインが古いからPHPを上げられない」という、身動きの取れない状態になりやすいのです。

例えば数年間更新されていないサイトでは、現在のPHPでは動作しない古いプラグインが残っていたり、カスタマイズされたテーマが新しいWordPressの仕様に対応していなかったりすることがあります。更新後にレイアウトが崩れる、管理画面にエラーが出る、問い合わせフォームが送れなくなるなどの不具合が起こり得ます。

企業サイトで特に困るのは、表面上は表示されているのに、問い合わせや採用応募が届かなくなることです。更新後の確認項目は、サイトの役割に応じて決めておく必要があります。

5．安全に更新するための6つの手順

① バックアップを確保する。 ファイルとデータベースを保存し、復元に必要な情報を確認します。ウエブルでも、お預かりしているサイトのバックアップを定期的にAWSに保存する運用を行っていますが、実際の更新時には対象サイトの状況に応じたバックアップと復元手順を確認することが大切です。

② 互換性を調べる。 プラグイン・テーマが新しいWordPressやPHPに対応しているかを確認し、開発が止まっている製品があれば置き換えも検討します。各プラグインの配布ページに記載されている「必要なWordPressのバージョン」「必要なPHPのバージョン」を一覧にし、どの順番で上げれば途中で動かなくならないかを決めます。数年分の差がある場合は、一度に最新まで上げず、PHP・本体・プラグインを少しずつ交互に上げていきます。

③ 可能なら検証環境で試す。 本番サイトとは別の環境で更新し、表示や主要機能に問題がないか調べます。緊急の場合は、検証の範囲と所要時間を絞る判断も必要です。

④ 本番へ反映する。 更新対象と作業順を決め、必要以上にまとめて変更しないようにします。フォームや会員機能など重要な処理がある場合は、作業時間も配慮します。

⑤ 動作を確認する。 トップページだけでなく、問い合わせフォームの送信、採用応募、検索、ログイン、ECなら購入手続きなど、事業に関わる機能を確認します。

⑥ 作業履歴を残す。 更新した製品とバージョン、日時、担当者、確認結果、不具合時の対応を記録します。社内説明や引き継ぎにも役立ちます。委託先との役割分担など、運用体制の考え方は「企業のWordPressセキュリティ対策｜AI時代に見直したい4つの視点と運用体制」で解説しています。