脆弱性の公表から、実際に悪用が始まるまでの時間は短くなっていると言われる。この記事では、公開されている調査の数字を出典と日付つきで確認したうえで、「月に1回まとめて更新する」という保守のタイミングをどう見直すかを整理する。煽るためではなく、落ち着いて運用を設計するための材料として書く。
まず、数字を確認する（2026-10-31 時点）
Patchstack が公開している「State of WordPress Security in 2026」（ページ更新日 2026-02-25）には、次の記述がある。
- 悪用の観測件数で重み付けした「最初の悪用までの時間」の中央値は 5 時間
- 影響の大きい脆弱性のおよそ半数が 24 時間以内 に悪用されている
- 開発者の修正が 公表に間に合わなかった 脆弱性が 46%
出典: Patchstack, State of WordPress Security in 2026
読むときの注意点がある。
- この「5 時間」は、数多くある脆弱性すべて の平均ではない。実際に悪用が多く観測された脆弱性を、観測量で重み付けした中央値だ。大半の脆弱性は、ここまで急には悪用されない
- 集計の仕方や期間は調査会社ごとに違う。二次的な解説記事では「6 時間以内に約 2 割」「12 時間以内に約 4 割弱」のように、区切りも数字も異なる表現が見られる。どれか一つを絶対視せず、桁（数時間〜1 日のオーダー）として受け取る のが安全だ
- 自分のサイトのプラグインが、その「悪用される側」に入っているかどうかは、この数字からは分からない
悪用までの時間が短いと、何が問題になるか
脆弱性が公表されると、修正版が出る。修正版と古い版の差分を比べれば、何が直されたのかを推測できる。この性質があるため、公表後に機械的な試行が増えやすい。
ここで問題になるのは、「月に1回まとめて更新する」運用の 空白期間 だ。
| 運用 | 公表から適用までの最長の空白 |
|---|---|
| 月1回まとめて更新 | 約 30 日 |
| 週1回 | 約 7 日 |
| 通知を受けたら当日〜翌営業日に確認 | 1〜2 日 |
悪用の中央値が数時間の脆弱性に対して、空白が 30 日あれば、その間ずっと無防備だったことになる。ただし、これは「そういう脆弱性が自分のサイトのプラグインに出たとき」の話だ。出なければ何も起きない。リスクは確率の問題であり、起きたときの窓の長さを運用側で選べる というのが論点になる。
公表の前から悪用されるケースもある
もう一つ、公表より前に悪用が始まっているケース（いわゆるゼロデイ）がある。この場合、更新を急いでも、公表の時点で既に試行が続いていた可能性がある。
ここでできることは限られる。
- 修正版が出たら、確認の優先度を上げる
- 入っているプラグインの数を減らしておく（前の記事で書いた棚卸し）
- 復旧できるバックアップを用意しておく
更新だけでは、公表前の悪用は防げない。だからこそ、「更新」と「持たない」と「戻せる」を組み合わせる。
「すべて急いで当てる」ではない
ここで誤解してはいけないのは、「悪用が速いのだから、あらゆる更新を即日当てよう」という結論にはならないことだ。
WordPress 本体のメジャー更新では、公開直後にプラグインやテーマとの互換性の問題が出ることがある。以前の記事（メジャー更新は少し待つ、失敗パターン）で書いたとおり、機能追加を伴う更新は、少し待ってから当てるほうがよい場合が多い。
この2つは矛盾しない。更新の種類で扱いを分ける と整理できる。
| 更新の種類 | 扱いの考え方 |
|---|---|
| セキュリティ修正（特に認証不要の重大なもの） | 待たずに確認し、早めに適用する |
| 通常のバグ修正・小さな更新 | 週次などの定例で適用する |
| 機能追加を伴うメジャー更新 | 少し待ち、検証してから適用する |
見分けるには、更新の changelog に「security」「vulnerability」といった記述があるか、脆弱性データベースに該当の登録があるかを見る。
運用に落とし込む
「月1回まとめて」を完全にやめる必要はない。次のように 二層 にするだけで、空白期間は大きく変わる。
- 定例: 週に1回、更新の一覧を確認して通常の更新を適用する
- 臨時: 自分が使っているプラグイン名で脆弱性情報を確認する手段を決めておき、該当があった日に臨時で対応する
更新の一覧は、読み取りだけのコマンドで確認できる。
# 更新が出ているプラグインとテーマ
wp plugin list --update=available
wp theme list --update=available
# WordPress 本体
wp core check-update
適用の前には、バックアップを取る。適用後は、トップページや主要な画面が表示されるか（HTTP ステータスが 200 か）を確認する。
自動更新との関係
プラグインの自動更新を有効にすれば、空白期間を短くできる。ただし、自動更新は 壊れた更新も自動で入る という面を持つ。サイトの重要度に応じて、「セキュリティ更新のみ自動」「それ以外は手動」といった使い分けを検討するとよい。複数のサイトを預かっているなら、サイトごとの設定を表にしておくと、影響範囲を後から追える。
まとめ
- 公開されている調査では、悪用が多く観測された脆弱性の「最初の悪用までの時間」の中央値は 5 時間と報告されている（Patchstack・2026-02-25 更新・2026-10-31 時点で確認）。ただし全脆弱性に当てはまる数字ではない
- 数字は調査ごとに異なる。桁として受け取り、一つの数字を絶対視しない
- 空白期間の長さは運用で選べる。「月1回」を「週次の定例＋臨時の対応」の二層にする
- セキュリティ更新は早く、メジャー更新は少し待つ。更新の種類で扱いを分ける
- 公表前の悪用は更新で防げない。数を減らす・戻せるようにしておく、を併用する
今日できる一手は、wp plugin list --update=available を実行して、出てきた更新の changelog にセキュリティ関連の記述がないか見ること。