1. 「更新しない」は、4つの層で別々に起きる
「WordPressを更新する」と一口に言っても、更新の対象は4つの層に分かれています。既定で自動かどうかも、放置したときに起きることも、層ごとに違います。
| 層 | 何か | 既定の更新 | 放置すると |
|---|---|---|---|
| PHP | WordPressを動かす、サーバー側のプログラム言語 | 自動ではない。サーバーの管理画面などで版を切り替える | 版ごとに修正の提供期限があり、過ぎると脆弱性が直らない |
| WordPress本体 | 管理画面と、ページを組み立てる仕組み | 5.6以降に新規で入れたサイトは自動 | 自動更新が無効か失敗していると、古いまま残る |
| プラグイン・テーマ | 問い合わせフォーム・SEO・デザインなど、後から足した機能 | 既定では手動(プラグインごとに自動へ切り替えられる) | 脆弱性の大半はここで見つかる |
| バックアップ | 壊れたときに戻すための、ファイルとデータベースの控え | 本体に機能は無い(プラグインかサーバーの機能で取る) | 事故のあとに戻す先が無い |
本体の自動更新は、WordPress 5.6以降に新規で入れたサイトでは既定で有効です。プラグインとテーマは、プラグインごとに自動更新を選べる画面が5.5で入りましたが、既定は無効です。この既定のままだと、「WordPressを更新しない」サイトで実際に止まっているのは、本体ではなく残りの3層だと考えています。
2. PHP ― 修正の期限が切れた版で動くWordPressは35.8%
PHPの各版は、公開から2年間は不具合と脆弱性の修正が出て、その後の2年間は重大な脆弱性の修正だけが出ます。4年で提供が終わります。2026年10月22日時点でphp.netに載っている、提供中の版は次のとおりです。
| 版 | 公開 | 不具合の修正の終了 | セキュリティ修正の終了 |
|---|---|---|---|
| 8.1以前 | ― | 終了 | 終了 |
| 8.2 | 2022年12月8日 | 2024年12月31日 | 2026年12月31日 |
| 8.3 | 2023年11月23日 | 2025年12月31日 | 2027年12月31日 |
| 8.4 | 2024年11月21日 | 2026年12月31日 | 2028年12月31日 |
| 8.5 | 2025年11月20日 | 2027年12月31日 | 2029年12月31日 |
この期限の違いが、2026年10月21日に実際の差として現れました。PHPの開発元は、認証なしに遠隔からコードを実行できる重大な脆弱性2件(CVE-2026-109618、CVE-2026-109619)を修正した版として、8.2.35・8.3.36・8.4.27・8.5.12を公開しました。正式な修正版が出たのは提供中の4つの系列だけです。開発元は7.4・8.0・8.1向けにも最小限の修正のソースをOSの配布元などに向けて提供しましたが、利用者が自分で当てられる版ではありません。IPA(情報処理推進機構)は翌22日に注意喚起を出し、この2件の組み合わせは「PHP2Shell」と呼ばれています。
WordPress.orgも21日に記事を出し、次の3点を案内しています。この脆弱性はWordPress固有ではなく、PHPを動かすサーバーすべてに関わること。WordPress側の更新では直らず、WordPressの更新の予定も無いこと。自分のサイトのPHPの版は、管理画面の「ツール > サイトヘルス > 情報 > サーバー」で確認できることです。
では、WordPressのサイトはどのPHPで動いているのでしょうか。wordpress.orgが公開している統計(更新の確認のときにサイトから送られる情報の集計)を2026年10月22日に取得し、php.netのサポート状況で分けました。
35.8%が、PHPの開発元からセキュリティ修正が出ない8.1以前の版で動いていました。最も多いのは7.4の15.9%で、8.1が10.5%、8.0が3.8%と続きます。今回の修正版が出た8.2〜8.5で動くサイトは64.1%です。このうち8.2(23.7%)は2026年12月31日でセキュリティ修正が終わるので、年が明けると、修正の出ない側は59.6%に増えます。
8.1以前の版でも、サーバー会社が、開発元が配布元向けに提供した修正を受け取って当てたり、WAF(攻撃を遮る仕組み)で緩和したりする場合があります。WordPress.orgの記事も、ホスティング会社がすでに対応している可能性に触れたうえで、利用者側でも更新の案内を確かめ、必要ならPHPを更新するよう書いています。つまり、自分のサーバーが対応済みかどうかは、サーバー会社の案内を読んで判断する作業です。
PHPの版の切り替えは、サーバー側の設定です。WordPressの管理画面からはできず、契約しているサーバーの管理画面などで行います。切り替えると、古いプラグインやテーマが動かなくなることがあるため、切り替える前に互換性を確かめ、切り替えた後に表示とフォームを確かめる作業が残ります。WordPressが推奨する版は8.3以上で、公式の要件のページは、7.4でも動くが公式のサポートが終わった版は脆弱性にさらされる可能性がある、と書いています。
3. 本体 ― 自動更新は既定だが、当たったかを確かめる人が要る
WordPress本体は、5.6以降に新規で入れたサイトでは、機能を足す大きな更新も修正のための小さな更新も自動で当たります。公式に積極的にサポートされるのは最新版だけで、古い系列への修正は「好意として」4.7まで配られます。更新の権限と作業の分担は、更新する内容と担当者からWordPressが要るかを決める記事で試しています。
自動更新があっても、確かめる人が要ることは、2026年7月の例で分かります。WordPress 6.9.0〜6.9.4と7.0.0〜7.0.1に、管理者の権限を持たない攻撃者が遠隔でコードを実行できる脆弱性の組み合わせ(CVE-2026-60137、CVE-2026-63030。「wp2shell」と呼ばれています)が見つかり、修正版6.9.5と7.0.2が出ました(片方の脆弱性は6.8.0〜6.8.5にもあり、6.8.6で直っています)。WordPress.orgは影響を受ける版に自動更新を強制的に配りましたが、IPAの注意喚起は、環境や設定によっては自動更新が無効だったり失敗したりしている可能性があるとして、管理画面で版が上がっているかを確かめ、上がっていなければ手動で更新するよう書いています。
その後も、2026年9月17日の7.1.1、9月22日の7.1.2、10月6日の7.1.3と、セキュリティ修正を含む版が続いています。7.1.3には7件のセキュリティ修正が入りました。wordpress.orgの統計(2026年10月22日)では、最新の系列7.1で動くサイトは63.0%で、残りの37.0%はそれより古い系列です。
本体の更新が自動で当たったあとにも、表示・フォーム・予約が動いているかを確かめる作業は残ります。自動更新を切ってあるサイトでは、更新を当てるかどうかの判断そのものが、誰かの作業です。
4. プラグイン・テーマ ― 脆弱性の91%はここで見つかり、更新は既定で手動
WordPressの脆弱性情報を集めているPatchstackの年次報告(2026年版)では、2025年にWordPressの周辺で新しく見つかった脆弱性は11,334件で、前年より42%増えました。そのうち91%はプラグイン、9%はテーマで見つかり、WordPress本体で報告されたのは6件(いずれも優先度の低いもの)でした。
プラグインとテーマは、既定では自動で更新されません。更新を当てるかどうかは、管理者が判断します。判断には、次の3つの選択が含まれます。
- すぐ当てる。脆弱性は塞がりますが、テーマや他のプラグインとの相性で表示やフォームが崩れることがあります。当てたあとに確かめる作業が要ります。
- 当てない。壊れはしませんが、脆弱性が残ります。
- 使っていないプラグインを消す。更新の対象そのものが減ります。
誰も判断しなければ、「当てない」が続きます。プラグインの作者がすでに修正を出していても、サイト側で当てなければ塞がりません。制作会社に作ってもらったサイトで、納品後にこの判断を誰が持つかが決まっていない場合、更新の通知だけが管理画面に溜まっていきます。
5. バックアップと復旧 ― 取る人と、戻す人は別に決める
WordPressの公式の資料は、データベースにはすべての投稿・コメント・リンクが入っており、消えたり壊れたりすると書いたものをすべて失う、と書いています。推奨されているのは、小さなサイトでも週1回、更新の多いサイトでは毎日バックアップを取り、直近の3〜5世代を、サーバー上・クラウド・手元のパソコンのように別々の場所に置くことです。ファイルとデータベースは同じ時点で取って1組として扱い、自動で取っているバックアップも、ときどき手動のバックアップで動いていることを確かめるよう書かれています。
WordPress本体には、バックアップを取る機能も戻す機能もありません。プラグインを入れるか、サーバーの機能を使うかを決め、保管先と世代数を決め、戻す手順を一度は試しておく作業が、誰かに残ります。
事故が起きたときに要るのは、バックアップそのものより、戻す人です。WordPress.orgの「サイトが乗っ取られた」ときの手引きは、症状と時刻を記録し、外部のスキャナーとプラグインの両方で調べ、必要なら専門の組織に依頼する、という順で書いています。どのバックアップが乗っ取られる前のきれいな状態か、データベースをどう戻すか、戻したあとに同じ穴をどう塞ぐかは、どれも判断の要る作業です。戻せるバックアップが無ければ、文章と写真を集め直して作り直すことになります。
「サイトが消えた」という言葉には、乗っ取りのほかに、契約が終わって公開が止まる場合や、作り直しになる場合が混ざっています。契約の側から起きる事故は、解約後もホームページを使えるかを契約書で確かめる記事で分けています。
6. 作成サービスでは、何が運営会社の側で、何が自分の側か
Wix・STUDIO・ペライチのような作成サービスでは、PHP・本体・プラグインの3層を運営会社が持ちます。利用者がPHPの版を切り替えたり、プラグインの更新を判断したりする場面はありません。そのかわり、復元の仕組みと範囲はサービスごとに違い、アカウントと権限の管理は自分の側に残ります。2026年10月22日に各社のヘルプと公式ページで確かめた範囲を並べます。
| 項目 | Wix | STUDIO | ペライチ |
|---|---|---|---|
| サーバーとソフトの更新 | 運営会社。脆弱性の自動スキャン、攻撃の監視、侵入テストを行うと説明 | 運営会社。利用しているプラットフォーム・ミドルウェア・ライブラリに脆弱性が見つかれば更新すると説明。WAFを設定 | 運営会社(ヘルプにサーバー更新の記述は見つからず) |
| HTTPS | 新しいサイトで自動 | 常時SSL/TLS。独自ドメインでも証明書を発行 | 独自ドメインでLet's Encryptの証明書を自動取得 |
| 復元の仕組み | サイト編集履歴から以前の版へ復元。ストア・ブログ・予約などのアプリの内容、連絡先、CMSのコレクションは戻らない(CMSは別のバックアップ) | バージョン管理で復元。保存期間はFree 1日・Mini 5日・Personal 30日・Business 120日・Business Plus 360日。CMSとフォームのデータは対象外 | 削除したページは1か月以内なら復活できる。ブログ(CMS)の記事は削除すると復元できない |
| 自分の側に残るもの | 二段階認証、共同管理者の権限、復元の操作 | メンバーの権限(オーナーを複数にすることを推奨)、復元の操作 | 復元の操作 |
作成サービスで「消える」事故が起きるとすれば、運営会社のサーバーの脆弱性ではなく、アカウントの乗っ取り、共同管理者の操作、プランの失効、復元できる期間を過ぎた削除のどれかだと考えています。どれも、運営会社の側ではなく自分の側で起きます。二段階認証を設定し、管理者を誰にするかを決め、復元できる期間を知っておくことが、作成サービスでの「更新」にあたります。
作成サービスからWordPressへ、あるいはその逆へ移るときに、文章・写真・ドメインの何を引き継げるかは、自作ホームページを修正するか作り直すかを引き継げるものから判断する記事で整理しています。
7. 更新・バックアップ・復旧の判断を、誰が持つかを決める
IPAの2026年10月22日の注意喚起は、PHPの更新が難しい場合の進め方として、システムの担当者だけでなく事業の責任者や経営層も含めて、更新と移行、その後の継続的な維持管理に必要な人員・予算・保守体制を確保できるかを検討するよう書いています。体制の見通しが立たない場合は、現行のシステムの継続を前提とせず、保守を受けられる製品やサービスへの移行も含めて検討するよう書いています。中小企業や個人事業主のホームページでも、問いは同じです。4層それぞれの判断を誰が持つかを、作り方ごとに並べました。
| 判断 | WordPressを自分で持つ | WordPressで保守を頼む | 作成サービス | 静的サイトで制作会社に頼む |
|---|---|---|---|---|
| PHPの版を切り替える | 自分(サーバーの管理画面) | 保守先 | 運営会社 | 制作会社(PHPを使わない構成もある) |
| 本体の自動更新が当たったかを確かめる | 自分 | 保守先 | 運営会社 | 更新する本体が無い |
| プラグインの更新を当てるか決める | 自分 | 保守先 | 運営会社 | 更新するプラグインが無い |
| バックアップを取り、事故のときに戻す | 自分 | 保守先 | 復元の機能は運営会社、操作は自分 | 制作会社 |
| アカウントと権限を管理する | 自分 | 自分と保守先 | 自分 | 自分と制作会社 |
WordPressは多機能で、その分、更新するものと判断することが多い仕組みです。判断する人がいないまま公開を続けると、PHPの期限、プラグインの脆弱性、戻せないバックアップのどれかが、事故につながると考えています。
WordPressを選ぶなら、更新・バックアップ・復旧の判断を引き受ける相手(制作会社か保守の事業者)に、いくらかでも払う。払わないなら、そもそも判断が要らない作成サービスを選ぶ。この順で決めるのがよいと考えています。更新する本体やプラグインの無い静的サイトを制作会社に任せる形も、判断を引き受ける相手に払う側に入ります。保守を頼むときは、PHPの切り替え、プラグインの更新の判断と更新後の確認、バックアップの頻度・保管先・戻す手順、事故のときの連絡先を、引き受ける範囲として契約で確かめます。保守の費用を年の総額で比べる見方は、修正費用を月額保守と都度払いで比べる記事に書きました。
デジステップの標準プランはWordPressを使わない静的サイトで、公開しているサーバーとドメインの管理は制作側が持ち(文字や画像の修正は依頼ごとの費用)、維持費は月額2,200円(サーバー・ドメインの実費)です。今のWordPressのサイトの更新を誰も判断していない状態なら、文章・写真・ドメインを引き継いでデジステップで作り直すこともできます。