WordPress本体の脆弱性を確認・解消する|既知の脆弱性を悪用した侵害を防ぐ

当ページは検証・整備中のドラフトです。
内容は実環境での検証や追加調査により変更される予定です。
参照:ページ公開・更新ポリシー

WordPress本体の更新が行われる目的

WordPress本体の更新には、主に次のような目的がある。

  • 脆弱性の修正
  • 不具合の修正
  • 新機能の追加
  • 既存機能の変更や改善
  • 動作環境や互換性への対応

ここでは、このうち脆弱性対策を前提としてWordPress本体の更新を扱う。新機能の使い方や、機能追加を目的としたアップデートについては対象としない。

セキュリティ修正が含まれる更新は、既知の脆弱性を残さないためにも適用を優先したい。一方、新機能の追加だけであれば、その機能を必要としていないサイトでは更新を急ぐ理由は小さくなる。
ただし、WordPressの更新はその後のバージョンにも積み重なっていく。ある更新を見送っても、後から新しいバージョンへ更新すれば、それまでの変更もまとめて適用される。

そのため、特別な理由がなければ更新を長期間ため込まず、こまめに適用しておく方が管理しやすい。更新後に表示崩れや機能上の問題が発生した場合も、変更を一つずつ適用していれば、どの更新を境に問題が発生したのか切り分けやすくなる。

WordPress本体の更新(リリース)の種類

WordPress本体の更新は、マイナーリリースとメジャーリリースに分けられる。

更新例WordPressでの扱い主な内容
6.8 → 6.8.1マイナーリリースメンテナンスやセキュリティ修正など
6.8 → 6.9メジャーリリース新機能や仕様変更を含む
6.9 → 7.0メジャーリリース6.8 → 6.9と同じ分類

一般的なソフトウェアでは、先頭の数字が変わる更新を大規模な変更として扱うバージョニングも広く使われている。しかし、WordPressはこの考え方でバージョン番号を付けていない。

WordPressでは 6.8 → 6.96.9 → 7.0 も同じメジャーリリースであり、「WordPress 6」「WordPress 7」という技術的な世代区分もない。先頭の数字が変わったという理由だけで、特別に大規模な更新と判断する必要はない。

見るべきなのは実際のリリース内容で、新機能や仕様変更の影響が大きければ、バックアップやテーマ・プラグインとの互換性をあらためて確認し、更新後も確認範囲を広げる必要がある。

WordPressの自動更新とは

WordPressには、本体の更新をバックグラウンドで適用する自動更新機能がある。

自動更新が行われたことはメール通知でも知ることができる

標準ではメンテナンスやセキュリティを目的とした更新が自動更新の対象となる。管理画面の「ダッシュボード → 更新」では、メジャーリリースを含む新しいバージョンまで自動更新するか、メンテナンス・セキュリティリリースを中心とした自動更新にするかを切り替えられる。

自動更新の範囲

運用方法

メンテナンス・セキュリティリリース

小規模な修正を自動適用し、メジャーリリースは確認して更新

すべての新しいWordPressバージョン

メジャーリリースを含めて自動更新

「メンテナンス・セキュリティリリース」のみを自動更新にしている状態

「すべての新しいWordPressバージョン」を自動更新にしている状態

切替ボタンのリンクで自動更新の範囲を切り替えることができる

wp-config.phpやプラグインなどを利用すれば、自動更新をさらに制限することもできる。ただし、これは管理画面に用意された通常の切り替えとは別の更新制御となる。

自動更新設定の注意点

WordPressで自動更新を有効にしていても、必ず更新が完了するとは限らない。

更新動作は管理画面の設定だけでなく、wp-config.phpやプラグインなどからも制御できる。ファイルを書き換えられないなど、実行環境が原因で自動更新に失敗するケースもある。

さらに、ホスティングや外部のWordPress管理サービスが独自の更新機能を提供していることも珍しくない。

WordPressの自動更新設定
        +
WordPress内部の更新制御
        +
ホスティング・管理サービス
        ↓
実際の更新動作

そのため、WordPress側では手動更新にしたつもりでも、別のサービスによって更新されることがある。反対に、自動更新を有効にしたつもりでも、別の設定や実行環境が更新を妨げている可能性もある。

自動更新を利用するなら、どの仕組みが更新を担っているのか一度確認しておくと後々の混乱を減らせる。

自動更新と手動更新の使い分け

自動更新と手動更新のどちらが適しているかは、サイトの構成や管理方法によって異なる。

小規模環境では、「マイナーリリースを自動化し、メジャーリリースは内容を確認してから手動で適用する」運用だと安全性と手間のバランスが良い。

WordPress本体の更新手順

日常の更新作業では、現在のバージョンと更新内容を確認し、その影響に応じて準備を変えていく。

現在のバージョンと更新先を確認する

WordPress管理画面から、現在使用しているバージョンと利用可能な更新を確認する。

自動更新を利用している場合も、現在のバージョンを見れば、実際に更新が適用されているか判断できる。

更新内容を確認する

更新先のリリース内容を確認し、どのような変更が含まれているか把握しておく。

特にメジャーリリースでは、新機能や仕様変更、互換性に関する情報が確認対象となる。詳細を知りたい場合は、WordPress公式のリリース情報を参照すればよい。

ここで判断材料となるのは、6.9 → 7.0 といったバージョン番号の見た目ではなく、実際の変更内容である。

影響が大きければバックアップと互換性を再確認する

サイトへの影響が大きい更新なら、更新前の状態へ戻せるバックアップがあるか再確認しておく。

テーマや主要なプラグインについて互換性情報が出ていれば、こちらも確認対象となる。

日常的にバックアップを取得しているサイトでも、影響範囲の大きな更新では、直近のバックアップが正常に取得されているかまで見ておきたい。バックアップの具体的な取得方法は、別のユニットで扱う。

WordPress本体を更新する

準備ができたらWordPress本体の更新を実行する。

手動更新では管理画面から開始し、処理の完了を待つ。自動更新の場合は操作そのものを必要としないため、更新後のバージョン確認が中心となる。

更新中はWordPressのファイルやデータベースが変更されることもある。処理が始まった後は、意図的な中断を避ける。

更新後の動作を確認する

更新後は、まずWordPressが目的のバージョンへ更新されたことを確認する。

続いて公開ページと管理画面を開き、普段使用している主要な機能を確認する。問い合わせフォームや検索などがあれば、実際に操作しておくと異常を発見しやすい。

変更範囲の大きな更新では、通常より確認範囲を広げる。

自動更新でも考え方は同じである。新しいバージョンになったことだけではなく、その後もサイトが正常に動作していることまで確認して更新完了とする。

まとめ

WordPress本体では定期的に脆弱性が発見されている。修正版が提供された後も古いバージョンを使い続ければ、攻撃者にも知られている脆弱性がサイトに残るため、本体の更新は必須である。

更新にはマイナーリリースとメジャーリリースがあるが、6.9 → 7.0 のように先頭の数字が変わること自体に特別な意味はない。更新の影響は、バージョン番号ではなく実際の変更内容から判断する。

また、自動更新を利用する場合も、設定しただけで管理が終わるわけではない。WordPress内部の設定やホスティング側の機能も含め、どの仕組みが更新を担っているのか把握しておきたい。

日常の更新は、次の流れで進める。

現在のバージョンと更新先を確認
        ↓
更新内容を確認
        ↓
影響が大きければ
バックアップ・互換性を再確認
        ↓
WordPress本体を更新
        ↓
バージョンと動作を確認