先に結論
- 2026年7月17日から8月12日までの27日間で、WordPressのセキュリティリリースは3回出ました（7.0.2 / 7.0.3 / 7.0.4）。
- ただしこれは「WordPressが急に脆くなった」という話ではありません。リリースノートを読むと、見つける側の顔ぶれと速度が変わったことのほうが読み取れます。
- 経営判断として大事なのは頻度そのものではなく、3回のうち自社サイトはどれが該当したのかを誰が判断しているかです。
この1か月で、実際に何が起きたのか
まず事実を並べます。すべてWordPress.orgの公式リリースノートに書かれている内容です。
| バージョン | 日付 | 修正件数 | 主な中身 |
|---|---|---|---|
| 7.0.2 | 2026年7月17日 | 2件（重大1・高1） | SQLインジェクションと、REST APIの経路解釈のズレ。2つをつなぐと未認証でのリモートコード実行に至る |
| 7.0.3 | 2026年8月6日 | 12件 | ログイン画面の未認証XSS、投稿まわりの格納型XSS、マルチサイトの権限昇格、SSRF ほか |
| 7.0.4 | 2026年8月12日 | 1件 | ImagickとGhostscriptを使うサーバーで、投稿者権限以上によるリモートコード実行 |
このうち7.0.2の2件は、のちに「wp2shell」という通称がつきました。7月21日には、米国CISA（サイバーセキュリティ・インフラセキュリティ庁）の「悪用が確認された脆弱性カタログ（KEV）」に登録されています。リリースからわずか4日後です。
WordPress.org側も、影響を受けるバージョンに対して自動更新を強制的に走らせるという異例の対応を取りました。3回のうち1回は、「更新してください」ではなく「こちらで更新します」というレベルの事案だった、ということです。
なぜ更新頻度が上がったのか？
WordPressのリリースノートには、脆弱性を報告した人の名前が全員分書かれています。ここを読むと、3つの変化が見えてきます。
1. 報告している顔ぶれが変わった
7.0.3の12件を報告したのは、pwn.ai、Aikido Security、HDWSec、amosec、そしてAnthropic（AI開発企業）といった顔ぶれでした。7.0.4を報告したのも pwn.ai です。従来のような個人リサーチャーだけでなく、AIを使って大量のコードを機械的に読む主体が、報告者として定着しつつあります。
検索の側でAIが当たり前になったのと同じことが、脆弱性を見つける側でも起きている。断定はできませんが、報告者名という事実からは、そう読むのが素直だと思います。
2. 報告の受け口が整備されている
WordPressは HackerOne 上でバグバウンティ（脆弱性報奨金プログラム）を運用しています。受け口があるから報告が集まり、集まるから修正が出る。これは「脆弱性が増えた」というより、表に出るまでの時間が短くなったということです。
3. 攻撃側の反応も速くなっている
wp2shellは、修正リリースから数日で実際の攻撃が観測され、実証コードも出回りました。CISAのKEV入りが4日後だったことからも、その速さがうかがえます。修正を溜めてまとめて出す、という余裕がないのが、いまの前提条件です。
補足すると、2026年8月16〜19日のWordCamp USで WordPress 7.1 が公開される予定です。次期メジャー版のリリース直前は、開発者もリサーチャーもコードを見る密度が上がる時期にあたります。この1か月という区切りには、そうした時期要因も乗っていると考えられます。
これは「WordPressが危険になった」ということか？
宮崎の見解
私はむしろ逆だと考えています。
「見つかっていないだけの脆弱性」と「見つかって直された脆弱性」を比べたら、危険なのは前者です。1か月で3回というのは、3回ぶんの穴が新しく空いたのではなく、3回ぶんの穴が塞がれたという数字です。
本当に怖いのは更新頻度が高いことではなく、その更新が届いていないサイトが世の中に大量にあることのほうです。7.0.2でWordPress.orgが強制自動更新にまで踏み切ったのは、それが分かっているからだと思います。
自動更新に任せておけば十分か？
半分は正解で、半分は危険。これが私の答えです。
7.0.2のように、全サイトが該当し、実際に攻撃されていて、強制更新まで走る事案であれば、自動更新は正しく機能します。何もしなくても守られます。
問題は7.0.4のような事案です。今回の条件は「ImagickとGhostscriptが有効なサーバー」かつ「投稿者権限以上のユーザーがいること」。国内の共用サーバーはGhostscriptが有効なことが多く、複数人で記事を書いている会社なら該当します。逆に、一人で運用していて他に権限を配っていないサイトなら、緊急度は下がります。
この「うちは該当するのか、しないのか」は、自動更新が判断してくれる部分ではありません。サイトの構成を知っている人間が読む必要があります。
宮崎の見解
正直に書きます。私自身、8月9日の時点で7.0.3（8月6日リリース）を捕捉できていませんでした。毎朝WordPressまわりの情報を追っている人間でも、3日遅れることがあります。
だからこそ、「気づいた人が気づいたときに対応する」という体制では、いずれ抜けます。そして抜けたことに気づかないのが、いちばん怖い。私が保守を人の注意力ではなく仕組みとして持っているのは、自分の注意力を信用していないからです。
今日できる3つの確認
- バージョンを確認する｜管理画面の「ダッシュボード → 更新」、または管理画面右下の表示。「7.0.4」になっていれば本記事時点で最新です。
- ユーザー一覧を見る｜投稿者以上の権限を持つ人が何人いるか。退職者や外注先のアカウントが残っていないか。7.0.4はここが該当条件です。
- 自動更新の設定を確認する｜マイナーリリースの自動更新が無効になっていないか。過去に不具合を避けるため止めたまま、という現場は珍しくありません。
3つとも管理画面から確認でき、合わせて5分ほどで終わります。
宮崎の意見｜保守の価値は「価格」から「判断」へ
WordPressの保守は長いあいだ、「月額いくらで、何をどこまでやってくれるか」という作業量の比較で選ばれてきました。バックアップ、更新、死活監視。作業の一覧が並び、条件が同じなら安いほうが選ばれる。私自身、その土俵で見積もりを書いてきた時期があります。
ただ、1か月に3回の判断が求められる世界では、この比べ方はもう成り立ちません。今回の3回で実際に必要だったのは、次のような判断でした。
- 7.0.2｜全サイト該当・即時。自動更新が実際に効いたかを確認する
- 7.0.3｜全サイト該当。ログイン画面が対象なので、管理画面を持っている以上は全員が対象
- 7.0.4｜条件付き。サーバー構成とユーザー権限を見て、該当・非該当を分ける
作業としては3つとも「更新する」で片付きます。けれど、顧客に説明できるかどうかはまったく別の話です。「全部やっておきました」と言うのは簡単で、「今回、御社は該当しませんでした。理由はこれです」と言えるかどうかに、専門家の値打ちがあると思っています。
作って終わりにしない、と言い続けてきましたが、その中身はここ数年で明確に変わりました。壊れないように見張る仕事から、判断を代わりに引き受ける仕事へ。更新頻度が上がったこの1か月は、その変化を分かりやすく示してくれた出来事だったと受け止めています。
よくある質問
投稿者以上の権限を持つユーザーが自分以外にいる場合は、今日中の更新をおすすめします。一人で運用していて他に権限を配っていない場合は緊急度は下がりますが、次の作業のついでに上げておくのが安全です。
管理画面の「ダッシュボード → 更新」、または各管理画面の右下に表示されています。本記事の時点では7.0.4が最新です。
マイナーリリースの自動更新が有効であれば、多くの場合は自動で適用されます。ただし過去に無効化していたり、サーバー側の設定で止まっていることがあるため、実際にバージョンが上がっているかを一度は目で確認してください。
セキュリティリリースは機能変更を含まないことが多く、比較的リスクは低めです。それでも不安な場合は、更新前にバックアップを取り、更新後にトップページと問い合わせフォームの動作を確認する、という運用にしておくと安心です。
2026年8月16〜19日に開催されるWordCamp USでの公開が予定されています。メジャーリリースはマイナーリリースと違って機能変更を含むため、本番環境への適用は少し様子を見るのが一般的です。
まとめ
- 2026年7月17日〜8月12日の27日間で、WordPressのセキュリティリリースは3回出ました
- 増えたのは「穴」ではなく「見つけて塞ぐ速度」です。報告者にAI関連の企業が並び始めたことが、その背景を示しています
- 7.0.2は全サイト該当かつ実際に攻撃されており、CISAのKEVにも登録されました。7.0.4は条件付きで、該当・非該当の判断が必要です
- 自動更新は前者には強く、後者には効きません。判断できる人がいるかどうかが、これからの保守の分かれ目になります
まずはご自身のサイトのバージョンを確認するところから。5分で終わります。