2026年7月中旬から8月中旬にかけて、WordPress本体のセキュリティリリースが3回続きました。7月17日の7.0.2、8月6日の7.0.3、8月12日の7.0.4です。いずれも機能追加を含まないセキュリティ修正だけのリリースで、3回とも最終的にサーバー上で任意のコードを実行されうる問題が含まれていました。
この頻度は以前と明らかに違います。理由はWordPressの品質が急に落ちたことではありません。脆弱性の報告件数そのものが2026年に入って十数倍に増えており、その背景にはAIを使った脆弱性の探索があります。この記事では、3回のリリースで何が修正されたのかを整理したうえで、報告が急増している状況と、この頻度が続く前提でWebサイトの運用をどう組み直すかを書きます。
1か月でWordPressのセキュリティリリースが3回続いた
3回のリリースは、悪用に必要な条件がそれぞれ違います。自分のサイトにどれが当てはまるかは、この違いで判断できます。
7.0.2は認証不要のリモートコード実行を塞いだ
7月17日（日本語の告知は7月18日）に公開された7.0.2で修正されたのは、通称「wp2shell」と呼ばれる問題です。WP_Queryのauthor__not_inパラメータにあるSQLインジェクション（CVE-2026-60137）と、REST APIのバッチ処理ルート/wp-json/batch/v1のルート混乱（CVE-2026-63030）を組み合わせると、ログインしていない攻撃者が任意のコードを実行できました。CVSSは10点満点の9.8です。
深刻なのは、プラグインもテーマも関係なく、WordPressをインストールしただけの標準状態で成立する点です。影響を受けるのは7.0.0〜7.0.1と6.9.0〜6.9.4で、WordPress.orgは自動更新の強制適用に踏み切りました。米国CISAは公開されたエクスプロイトが出回る前の7月21日に、悪用が確認された脆弱性のカタログへ登録しています。日本でもIPAが7月22日に注意喚起を出しました。
発見したのはSearchlight Cyber傘下Assetnoteの研究者です。この発見の経緯が、後述する報告急増の引き金になりました。
7.0.3はログイン画面のXSSからサイト乗っ取りに届く経路を塞いだ
8月6日（日本語の告知は8月7日）の7.0.3で修正された「XSS2Shell」（CVE-2026-64638）は、WordPressのログイン画面wp-login.phpにあった反射型のクロスサイトスクリプティングです。WordPress側のサニタイズ処理とPHP側の解釈にズレがあり、無害なテキストとして通した入力が、後段のHTML処理で有効なマークアップとして扱われていました。
この1件が重いのは、そこで止まらないからです。報告したpwn.aiは、ログインに1回失敗させるだけでログイン画面に任意のDOMを差し込み、Same Origin Method Executionという手法を経由してアプリケーションパスワードを盗み、プラグインをアップロードしてPHPを実行するところまでの経路を実証しています。悪用には管理者に細工したURLを踏ませる必要がありますが、前提として必要な権限はゼロです。CVSS 4.0での評価は8.9でした。
7.0.4はImagickとGhostscriptを使うサイトだけが対象
8月12日（日本語の告知は8月13日）の7.0.4で修正されたのはCVE-2026-65640です。前の2件と違い、成立条件が限定されています。サーバーでImagickとGhostscriptの両方が動いていて、なおかつ投稿者以上の権限を持つ利用者が細工したファイルをアップロードした場合にだけ、リモートコード実行に至ります。CVSSは8.8で、報告者は7.0.3と同じpwn.aiです。
影響範囲の広さは別の意味で目を引きます。この問題はWordPress 4.7.0から7.0.3まで、およそ10年分のバージョンに存在していました。
7.0.4の脆弱性は拡張子と中身のズレを突いていた
3件の中では7.0.4の仕組みがいちばん分かりやすく、そして構造として根が深いものです。
WordPressの画像処理クラスWP_Image_Editor_Imagickは、ファイルをどう扱うかを拡張子で判断していました。一方のImagickは、渡されたファイルの中身を読んで形式を推定します。holiday.pngという名前でPostScriptのプログラムを送り込むと、WordPressは拡張子を見て画像として処理を任せ、Imagickは中身を見てPostScriptだと判断し、Ghostscriptを呼び出してプログラムとして実行します。Ghostscriptは以前から任意コード実行につながる問題を繰り返してきたソフトウェアなので、そこへ攻撃者が用意した内容が届いた時点で勝負がつきます。
判断基準がレイヤーごとにズレていることが入口になる。この形は画像に限った話ではありません。7.0.4の修正はload()でImagickへ渡す前に内容を検査し、PostScriptらしきファイルを手前で弾く方向で入っています。
自分のサーバーでImagickとGhostscriptが動いているか確認する
該当するかどうかは、WordPressの管理画面から確認できます。「ツール」の中の「サイトヘルス」を開き、「情報」タブのメディア処理の項目を見ると、ImageMagickが有効かどうかとそのバージョンが表示されます。共有レンタルサーバーではImagickが標準で有効になっている環境が多いため、画像を大量に扱っているWebサイトほど優先度を上げて対応する価値があります。
なお、この修正は4.7ブランチまでバックポートされ、次のメジャーである7.1のRC3にも含まれています。
WordPressの脆弱性報告はAIで急増している
ここからが、この1か月をどう受け止めるかという話です。
月20〜30件が450件になった
WordPressのHackerOneプログラムに寄せられる報告は、10年ほどにわたって月20〜30件で安定していました。それが2026年に入って跳ね上がり、7月には約450件に達したとコアコミッターが報告しています。この450件はWordPress本体だけの数字ではなく、WordPress.orgのインフラ、プロジェクトのGitHub、公式プラグインを含めた全体の件数です。有効な報告だけでなく、AIが生成した中身のない報告や重複も混ざっています。
それでも十数倍という変化は、報告を受ける側の処理能力を確実に超えます。コア開発者のJohn Blackbourn氏は、AIに支えられたセキュリティ研究のまったく新しい時代に入ったと述べています。
wp2shellは25ドルで見つかった
火がついたきっかけは、7.0.2のwp2shellです。この脆弱性はOpenAIのSol Ultraを使い、およそ25ドルの費用で発見されたと報じられています。10年以上見つかっていなかった、標準構成で成立する認証不要のリモートコード実行が、その金額で出てきた。この事実が公開された直後から、他の研究機関やペネトレーションテストの会社が同じことを実演しようと動き始めました。7月の450件はその結果です。
品質が落ちたのではなく発見が速くなった
複数の仕組みを組み合わせるチェーン型の脆弱性や、パーサーの解釈の差分は、人間のコードレビューでは見落とされやすい領域です。wp2shellのSQLインジェクションとREST APIの組み合わせも、XSS2Shellのサニタイズ処理と解釈のズレも、7.0.4の拡張子と中身のズレも、すべてその型に当てはまります。AIはこの種の差分を短時間で総当たりに近い形で洗い出せます。
つまり、WordPressのコードが急に悪くなったのではありません。これまで見つかりにくかった問題が表面化し、報告と修正のサイクルが速くなったと捉えるほうが実態に近いと考えています。大規模なソフトウェアで脆弱性が常にゼロという状態は現実的ではなく、見つかったときに速く直る仕組みが動いていること自体が、メンテナンスの継続を示す材料です。
ただし、この非対称性は攻撃側にも同じように働きます。修正が公開された時点で、どこに穴があったかは攻撃者にも公開されます。攻撃側のツールもAIで加速している以上、公開から悪用までの時間は今後さらに短くなります。
緊急リリースが続く前提でWordPressの運用を組み直す
月に複数回の緊急リリースが来る。これを例外ではなく通常として扱ったほうがよい状況になりました。運用側でいま確認しておくべきことは3つです。
自動更新が本当に動いているか確認する
WordPressのマイナーアップデートは既定で自動更新の対象です。それでも、独自のテーマを使っている、過去に更新で表示が崩れたといった理由で自動更新を止めているサイトは珍しくありません。今回の3回はいずれも機能変更を含まないため、止めておく理由はほとんどありません。
止めていないつもりのサイトも確認が必要です。サーバーの構成やファイルの権限設定によって自動更新が働かないことがあり、私は自動更新が途中で止まったまま気づかれていなかったWebサイトを何度も見ています。管理画面の「更新」を開き、バージョン番号が最新の状態まで上がっているかを目で見てください。
バックアップが戻せる状態か確認する
バックアップは取得していることではなく、戻せることに意味があります。サーバーの自動バックアップに任せている場合、保存されているのがファイルだけでデータベースが含まれていない、保持期間が短くて侵入に気づいたときには既に汚染後のデータで上書きされている、といった状態はよくあります。復元を一度も試したことがないなら、それはまだバックアップとして機能していません。
侵入されたときに何を見るか決めておく
私が実際に対応したWordPressの侵害では、復旧そのものより「どこから入られたのか」を突き止める作業に最も時間を取られました。そのときの侵入経路は、まさにwp2shellが悪用するREST APIのバッチエンドポイントへの集中的なリクエストで、Webサーバーのアクセスログを時系列で追って初めて特定できたものです。ログの保持期間が短ければ、この調査は成立しませんでした。
サーバーのアクセスログがどこに何日分残るのか、管理者アカウントが増えていないかをどう確認するのか。この2つを平時のうちに決めておくと、不正アクセスが発生したときの初動がまったく変わります。
件数で見ればプラグインとテーマのほうが多い
ここまで本体の話を書いてきましたが、報告される脆弱性の件数でいえば大半は本体ではなくプラグインとテーマです。本体の自動更新とは別に、プラグインとテーマの自動更新は個別に設定する項目なので、そちらも有効になっているかを見てください。使っていないプラグインを停止のまま残さず削除する、更新が2年以上止まっているプラグインを別のものに置き換える。この2つで、攻撃の対象になる面積がはっきり減ります。
脆弱性診断のサービスを導入するかどうかは、この土台ができてからの判断です。独自に開発した機能や会員システムを抱えるWebサイト、決済や個人情報を扱う企業サイトであれば費用に見合います。標準的なWordPressにプラグインを組み合わせただけのサイトなら、本体とプラグインを最新に保ち、管理者アカウントを絞り、ログを残す。この3つのほうが先です。
なお、7.0より前のバージョンで止まっているサイトも今回の3件の対象です。修正はセキュリティ修正の対象である4.7以降のブランチへ必要に応じてバックポートされているので、6系や5系にも更新は届きます。ただしWordPressが公式に動作を保証しているのは最新版だけで、古いブランチにとどまる運用は今回しのげても次のリリースで行き詰まります。
落ち着いている今のうちに見ておく
1か月で3回という数字を見て私が考えたのは、次の緊急リリースがいつ来るかではなく、来たときに自分が何もしなくて済む状態かどうかでした。自動更新が動いていて、バックアップが戻せて、ログが残っている。この3つが揃っていれば、リリースのたびに内容を追いかけて慌てる必要はありません。揃っていないサイトは、リリースが来てから確認することになりますので、順番が逆になってしまいます。いまのWebサイトが更新に耐える状態かどうかを確認してみてください。
