WordPressを安全に更新する手順

まず、慌てないでください。 「既知の脆弱性に該当している」ことと「すでに攻撃されている」ことは別です。 多くの場合は、順を追って更新すれば解消します。

すでに侵入された疑いがある場合は手順が変わります。 この記事の最後を先に読んでください。

何よりも先にこれをしてください。ファイルとデータベースの両方です。 片方だけでは元に戻せません。

• ファイル — wp-content/ 配下（テーマ・プラグイン・アップロードした画像）と wp-config.php。本体のファイルは再ダウンロードできるので必須ではありません
• データベース — 投稿・固定ページ・設定・ユーザー情報がすべてここにあります。 これが無いと、ファイルだけ戻してもサイトは復元できません

取っただけで安心しないでください。 バックアップファイルのサイズが極端に小さくないか、ダウンロードして開けるかを確認します。 「取っていたつもりが空だった」は実際によくあります。

取得方法はサーバ会社の管理画面、WordPressのプラグイン、 サーバの自動バックアップ機能などがあります。環境によって異なるため、 まず契約しているサーバ会社のマニュアルを確認するのが確実です。

診断結果は重大な順に並んでいます。特に次の順で優先してください。

1. 情報が漏れているもの（debug.log や設定ファイルのバックアップの公開） — すでに漏洩している状態なので、まずアクセスを止める
2. 実証コードが公開されている脆弱性 — 攻撃に使われやすい状態です
3. 深刻度が「緊急」のもの
4. その他

本サイトが深刻度（CVSS）よりも悪用実績（KEV）と悪用確率（EPSS）を優先して 並べているのは、「攻撃されたらどれだけ深刻か」と「実際に攻撃されるか」が別だからです。

更新する順序

1. WordPress本体
2. プラグイン
3. テーマ

この順にするのは、プラグインとテーマが本体のバージョンに合わせて作られているためです。 逆順にすると、新しいプラグインが古い本体で動かないことがあります。

1つずつ更新する

まとめて更新すると、問題が起きたときにどれが原因か特定できません。 1つ更新するたびにサイトを表示して確認する、を繰り返します。 数が多いと面倒ですが、壊れたときの切り分けにかかる時間のほうが長くなります。

可能ならテスト環境で先に試す

本番と同じ構成の複製を用意し、そこで更新して表示を確認してから本番に適用します。 壊れて困るサイトほど効きます。用意できない場合は、 アクセスの少ない時間帯に、戻せる状態を確保してから行ってください。

トップページが表示されただけで終わらせないでください。 壊れやすいのは動きのあるページです。

• 問い合わせフォーム — 実際に送信して、送信完了画面とメール受信まで確認する
• 商品ページ・カート・決済 — ECなら最優先。売上に直結します
• 予約フォーム・会員ログイン
• スマートフォンでの表示 — PCだけ確認して崩れに気づかない例が多いです
• 管理画面 — 投稿の編集画面が開くか

フォームは「送信できたように見えて、実はメールが届いていない」という壊れ方をします。 画面の表示だけでなく、メールが実際に届くところまで確認してください。

1つずつ更新していれば、原因は直前に更新したものです。

1. 該当のプラグインを停止する — これで直るなら原因が確定します
2. 停止しても直らない場合はバックアップから戻す — ファイルとデータベースの両方
3. 原因が分かったら記録しておく — 「このプラグインは更新できない」と分かっていること自体が 次回の判断材料になります

画面が真っ白になって管理画面にも入れない場合、 FTPやサーバのファイルマネージャから wp-content/plugins/ 配下の 該当プラグインのフォルダ名を変更すると、WordPress がそれを認識できなくなり、 結果としてプラグインが停止した状態で起動します。応急処置として使えます。

WordPress には自動更新の仕組みがあります。どこまで任せるかは、 壊れたときに気づける体制があるかで決めます。

• 本体のマイナー更新（セキュリティ修正） — 有効にしてよい。 互換性を壊さない修正が中心で、既定でも有効です
• 本体のメジャー更新 — 手動を推奨。見た目や編集画面が変わることがあります
• プラグイン・テーマ — 判断が分かれます。 自動にすれば更新漏れは無くなりますが、壊れたことに誰も気づかない期間が生まれます

プラグインを自動更新にするなら、死活監視か表示チェックを併せて用意してください。 「自動更新にしたから安心」が一番危険な状態です。 監視が用意できないなら、頻度を決めて手動で回すほうが安全です。

「更新するとサイトが壊れる」「修正版が出ていない」という場合の選択肢です。

• そのプラグインを停止・削除する — 使っていない機能なら、これが最も確実です。 停止しただけではファイルが残るので、不要なら削除してください
• 代替のプラグインに移行する — 開発が止まっている場合、今後も修正されません。 プラグインページの「最終更新」が数年前なら、移行を検討する時期です
• WAFで該当する攻撃を遮断する — 応急処置です。根本解決にはなりません

更新できない理由を把握しておくこと自体が保守です。 「なぜか分からないが更新していない」と「カスタマイズと競合するので更新できない」は、 緊急の脆弱性が出たときの動きがまったく違います。

PHPのバージョンが古くて更新できない場合は、PHPを上げるのが先になります。 サポートの切れたPHPは、それ自体が脆弱性を抱えたまま修正されません。

これは更新では解決しません。対応が根本的に異なります。 次のような兆候がある場合は、更新を試みる前に専門家に相談してください。

• 身に覚えのない管理者ユーザーが増えている
• 覚えのないファイルが設置されている、既存ファイルの更新日時が変わっている
• 検索結果に無関係な単語が表示される、海外サイトへ勝手に転送される
• サーバ会社やGoogleから警告が届いた

このような場合、バックドアが残っていると、更新しても再び侵入されます。 侵入経路の特定と、クリーンな状態からの復旧が必要です。 また、この状態のサイトのバックアップを取っても、 バックドアごと保存されるだけである点に注意してください。