「WordPress 7.0.3」セキュリティアップデート：7.0.2との違いと12件のセキュリティ修正を解説

2026年8月6日（米国現地時間）、WordPress 7.0.3が公開されました。こちらも追加機能の搭載が伴わない「セキュリティアップデート」の位置づけとなっています。

WordPress 7.0.2が公開されたのは2026年7月17日だったため、わずか3週間ほどで再びセキュリティアップデートが行われたことになります。

「7.0.2は重大な脆弱性を修正したばかりなのだから、7.0.3は急いで更新しなくてもよいのでは？」と思う方もいるかもしれません。

しかし、WordPress 7.0.2と7.0.3では修正対象となっている脆弱性がまったく異なります。7.0.2へ更新していても、7.0.3で新たに修正された12件の問題は残ったままです。そのため、WordPress公式も7.0.3について「直ちにサイトを更新すること」を推奨しています。

今回はWordPress 7.0.2との違いを確認しながら、7.0.3で修正されたセキュリティ上の問題をできるだけ分かりやすく解説します。

まずはこちらを：参考リンク

• WordPress 7.0.3リリース – WordPress.org 日本語
• WordPress 7.0.2リリース – WordPress.org 日本語

英語の資料はこちらから

• Version 7.0.3 – Documentation – WordPress.org
• WordPress 7.0.3 Released: 12 Vulnerabilities Found and Fixed – Patchstack
• Ninety minutes: watching attackers weaponize the WordPress core RCE – Patchstack

WordPress 7.0.3は12件のセキュリティ問題を修正したアップデート

WordPress 7.0.3は、新しいブロックや管理画面機能を追加するためのアップデートではありません。セキュリティ問題を修正することを目的としたリリースです。

WordPress公式が公表している修正内容は全部で12件あります。「XSS（クロスサイトスクリプティング）」「権限昇格」「情報漏えい」「CSSインジェクション」「メールアドレス確認処理の回避」「SSRF（サーバーサイドリクエストフォージェリ）」など、多岐にわたります。

特に目立つのがXSSで、ログイン画面から投稿、ブロック、クイック編集まで複数の場所で問題が修正されています。

WordPress 7.0.2とは何が違う？

まず、直前のWordPress 7.0.2との違いを整理しておきましょう。

WordPress 7.0.2は「2件の非常に重大な脆弱性」への対応

7.0.2で修正されたのは主に次の2件でした。1つはSQLインジェクションを容易にする問題。もう1つはREST APIのバッチ処理におけるルートの混同とSQLインジェクションを組み合わせ、最終的にRCE（リモートコード実行）へつながる可能性がある問題です。

RCEとは、離れた場所にいる攻撃者がサーバー上で任意のコードを動かせる状態を指します。

WordPress公式は7.0.2について、1件を「Critical（深刻）」、もう1件を「High（重要）」として扱い、影響を受けるサイトには自動更新システムによる強制更新まで実施しました。Patchstackも、この2件を組み合わせることでサイト全体の乗っ取りにつながることを確認し、実際の悪用も確認されていると報告しています。

つまり7.0.2は「非常に危険な特定の攻撃経路を緊急で塞ぐアップデート」だったと考えると分かりやすいでしょう。

WordPress 7.0.3は「広い範囲のセキュリティ問題」を修正

一方の7.0.3では12件もの問題が修正されています。

対象となる場所も、ログイン画面、投稿、ブロック、コメント、マルチサイト、メールアドレス確認、URL検証など非常に広範囲です。修正の入った箇所もWordPress 7.0.2とは異なります。

そのため、「7.0.2に更新したから安全」ということにはなりません。7.0.2は7.0.1以前で見つかった問題を修正したバージョンであり、7.0.3はさらに別の問題を修正したバージョンです。

WordPress 7.0.3 の修正箇所12点

ここからは、WordPress 7.0.3 で修正された箇所について、それぞれ詳しく見ていきます。

1．ログイン画面の認証前・反射型XSS

今回もっとも注意したい問題のひとつです。

WordPressのログイン画面に、ログインしていない攻撃者でも利用できる反射型XSSが存在していました。XSSとは、Webページ上で本来意図していないJavaScriptなどを実行させる攻撃です。

今回の問題では、攻撃者が細工したURLを用意し、それをWordPress管理者にクリックさせることで、管理者のブラウザ上で不正なスクリプトを実行できる可能性があります。

WordPress公式は、この問題について「PHPコード実行につながる可能性がある」と説明しています。CVE-2026-64638としても登録されています。

ただし、「サイトへアクセスされただけで直ちに乗っ取られる」というタイプではありません。攻撃を成立させるには、攻撃対象となるサイトの管理者に対して細工されたURLを送り、その管理者自身にクリックさせる必要がある、とPatchstackは説明しています。

管理者が攻撃を受けた場合には、そのセッションを悪用してプラグインやコードを追加するなど、最終的にRCEへ発展する可能性があります。つまり、フィッシング攻撃などと組み合わせて管理者を狙う可能性がある脆弱性です。

2．絵文字設定を利用した保存型XSS

投稿内の絵文字設定に関する要素を利用して、保存型XSSを引き起こせる問題も修正されています。こちらはContributor（寄稿者）以上の権限が必要です。

保存型XSSとは、不正なコードが一時的にURLなどへ含まれるだけではなく、WordPress側に保存されてしまうXSSです。その投稿を管理者や他のユーザーが表示した際に、不正なスクリプトが実行される可能性があります。

自分ひとりだけで運営しているブログでは悪用条件が限定されます。一方で、複数ライターを抱えるメディア、外部ライターへ寄稿者権限を与えているサイト、会員が投稿できるサイトなどでは重要度が高くなります。

3．コンテンツ（Post Content）ブロックの保存型XSS

「コンテンツ（Post Content）」ブロックにも、Contributor以上のユーザーが利用できる保存型XSSが存在していました。

「コンテンツ」ブロックは、特にブロックテーマで重要なブロックです。テンプレート内に配置し、「現在表示している投稿や固定ページの本文をここへ表示する」ために使用します。

ブロックが最終的にHTMLを生成するときの処理に不備があると、不正な内容が安全に処理されない可能性があります。一見すると普通の投稿本文に見えるようであっても、不正な内容がそのまま出力されてしまう可能性があります。

現在のWordPressでは多くの画面がブロックによって生成されているため、こうしたブロックの出力時に適切な無害化を行うことは非常に重要です。

4．クイック編集の保存型XSS

投稿一覧画面にある「クイック編集」に関係する保存型XSSも修正されました。こちらもContributor以上の権限が必要ですが、WordPress公式は特にユーザー数が多いサイトで発生する問題として説明しています。

クイック編集は、「タイトル」「スラッグ」「カテゴリー」「タグ」「公開状態」などを投稿一覧から変更できる機能です。多数のユーザーを抱えているニュースサイトや投稿型サービス、大規模なメディアサイトでは、特に更新しておきたい修正です。

5．投稿日（Post Date）ブロックの保存型XSS

投稿日を表示する「投稿日（Post Date）」ブロックにも保存型XSSが存在していました。こちらもContributor以上のユーザーによって悪用できる問題です。

WordPressのブロックは単に文字を表示するだけでなく、HTMLの属性値なども生成します。こうした属性値に想定外のデータを挿入できると、HTML構造から抜け出して別のコードとして扱わせる「属性注入」のような攻撃につながることがあります。

「コンテンツ」と「投稿日」の両方でXSSが修正されている点を見ると、今回の7.0.3ではブロックによって生成されるHTMLの安全性も重点的に見直されたことが分かります。

6．マルチサイトでの権限昇格

マルチサイト機能にも問題が見つかっています。

対象となるのは、ユーザー登録を有効にしているマルチサイトです。一定の条件下で、本来サイトを作成できないユーザーが新しいサイトを作成できてしまう問題でした。このように、本来は使えないはずの高い権限を、普通のユーザーが不正に取得できてしまう欠陥のことを「権限昇格」と呼びます。

なお、通常のWordPressを1サイトだけ運営している場合には、この問題の影響を受けません。

一方、企業、大学、学校、Webサービスなどでマルチサイトを使い、複数ユーザーにアカウントを発行している環境では注意が必要です。Patchstackも、この問題はマルチサイトのみが対象であると説明しています。

7．「最新のコメント」ブロックからパスワード保護投稿のコメントが漏れる問題

「最新のコメント（Latest Comments）」ブロックにも情報漏えいの問題がありました。具体的には、パスワードで保護された投稿につけられたコメントが表示されてしまう可能性があります。

WordPressでは投稿をパスワードで保護できます。当然ながら、その投稿を閲覧できないユーザーに対して、その中身を推測できる情報まで見せてしまうのは望ましくありません。コメントそのものから記事内容を推測できることもあります。

サイト乗っ取りのような問題ではありませんが、「非公開にしたつもりの情報が漏れる」という意味で修正が必要な問題です。

8．投稿スラッグを列挙できる問題

今回の修正には投稿スラッグの列挙（Enumeration）も含まれています。

スラッグとは、例えばexample.com/sample-post/であれば、sample-postの部分です。

本来公開されていない投稿であっても、スラッグの存在を外部から確認できてしまうと、「どのような非公開ページが存在するのか」を攻撃者に推測される可能性があります。

それだけで管理画面へ侵入できるわけではありませんが、攻撃者に余分な情報を渡すことになるため、情報収集の足掛かりとして利用される可能性があります。

9．コメントフィードからNotesが漏れる問題

コメントのフィードから、本来公開することを想定していないNotes（注記情報）が漏れる問題も修正されています。

こちらも直接サイトを乗っ取るタイプではありません。しかし、「データベースに存在している情報」と「外部へ公開してよい情報」は同じではありません。

WordPressではRSSなどのフィードを通して情報を外部へ配信するため、通常のWebページでは表示されていなくても、フィード経由で情報が見えてしまうことがあります。

7.0.3ではその境界も修正されています。

10．Author以上によるCSSインジェクション

Author（投稿者）以上のユーザーが、WordPressの安全なCSS属性フィルターを回避できる問題も修正されました。

CSSインジェクションとは、ページ内へ攻撃者が任意のCSSを挿入できてしまう問題です。JavaScriptを直接実行するXSSとは異なりますが、「表示を隠す」「別の要素を重ねる」「利用者を誤った操作へ誘導する」といった画面改ざんに利用される可能性があります。

特に複数人へ投稿権限を与えているサイトでは無視しにくい問題です。

11．メールアドレス確認処理を回避できる問題

WordPressのメールアドレス確認フローを回避できる問題も修正されています。

WordPressではメールアドレスの変更やユーザー関連処理などで、「本当にそのメールアドレスを所有しているのか」を確認する仕組みがあります。

今回、その確認フローを正常に完了していないにもかかわらず、処理を進められる可能性がある問題が修正されました。

単独で即座にサイト乗っ取りへ直結するとは限りませんが、認証・本人確認に関わる処理はセキュリティ上重要なため、修正しておくべき問題です。

12．URL検証を回避してlink-localアドレスへアクセスできるSSRF

最後はSSRFです。SSRFとは「Server-Side Request Forgery」の略で、簡単にいうと、攻撃者がWordPressサーバーを使って、本来アクセスできない場所へ通信させる攻撃です。

今回の問題では、WordPressのURL検証処理をすり抜けて、link-localと呼ばれるアドレス範囲へリクエストを送れる可能性がありました。

link-localとは、同じネットワークやサーバー内部など、限られた範囲で利用される特殊なIPアドレスです。一般ユーザーのブラウザから直接アクセスできない場所であっても、WordPressが動いているサーバーからならアクセスできる場合があります。

そのためSSRFを悪用すると、「WordPress → 内部ネットワーク → 内部サービス」という形で、WordPressを踏み台として内部システムへアクセスされる可能性があります。

Patchstackも今回のSSRFについて、攻撃対象をWordPressサイトだけでなく内部ネットワーク側へ広げる足掛かりになり得る問題として注意を促しています。

7.0.3では「WordPressの境界部分」が広く修正されている

12件を並べるとバラバラな問題に見えますが、共通点もあります。

今回重点的に修正されているのは、「どこまで信頼してよいのか」を判断する境界部分です。

たとえば、「未ログインユーザーと管理者」「寄稿者と管理者」「非公開情報と公開情報」「外部インターネットと内部ネットワーク」「安全なHTMLと危険なHTML」といった境界です。

7.0.2が「SQLインジェクションからRCEにつながる非常に危険な攻撃経路を緊急で閉じたリリース」だったとすれば、7.0.3は、「WordPressコアのさまざまな部分に残っていた信頼境界の問題を一斉に修正したリリース」と捉えると分かりやすいでしょう。

更新の重要性について

WordPress 7.0.2を使っていても7.0.3へ更新する必要がある

ここが今回もっとも重要なポイントです。WordPress 7.0.2と7.0.3は、同じ問題を二度修正したわけではありません。

7.0.2で修正されたのは、以下の2点です。

• SQLインジェクションを容易にする問題
• REST APIのバッチ処理とSQLインジェクションを組み合わせたRCEにつながる問題

7.0.3では、それとは別に今回紹介した12件の問題が修正されています。

したがって、WordPress 7.0.2を利用していても、7.0.3の脆弱性に対して安全になったわけではありません。WordPress公式も7.0.3について即時更新を推奨しています。

旧バージョンを使っている場合も更新が必要

今回の問題はWordPress 7.0だけのものでもありません。

公式HelpHubによると、影響する脆弱性の数は次のようになっています。

• WordPress 7.0： 12件
• WordPress 6.9： 11件
• WordPress 6.8 ～ 5.8： 8件
• WordPress 5.7 ～ 4.7： 7件

WordPress 6.9では6.9.6、6.8では6.8.7など、各ブランチ向けの修正版も公開されています。さらに4.7系についても4.7.34まで修正がバックポートされています。

つまり今回の脆弱性には、最近追加されたWordPress 7.0固有の機能だけでなく、かなり以前から存在するWordPressの仕組みに関係する問題も含まれていると考えられます。

ただし、古いWordPressを使い続けることが推奨されているわけではありません。WordPress公式は、積極的にサポートしているのは最新バージョンのみであることも明記しています。

特に更新を急いだ方がよいサイト

7.0.3は基本的にすべてのWordPressサイトで適用しておきたい更新ですが、特に、以下のようなWordPressサイトでは優先度が高くなります。

• 複数のライターへWordPressアカウントを発行している
• 寄稿者・投稿者権限を外部ユーザーへ与えている
• 会員制サイトを運営している
• マルチサイト機能を利用している
• パスワード保護投稿を利用している
• WordPressサーバーが社内・クラウドの内部ネットワークへアクセスできる

今回の保存型XSSはいずれもContributor以上の権限が攻撃条件となっています。Patchstackも、ゲストライターやフリーランス、制作会社などへContributor権限を渡しているサイトでは特に注意すべきとしています。

一方、ログイン画面の反射型XSSやSSRFなどは、単純に「投稿者アカウントを発行していないから関係ない」と言い切れる問題ではありません。

まとめ：7.0.2で安心せず7.0.3まで更新しておこう

WordPress 7.0.2は非常に重大なSQLインジェクションやRCEにつながる問題を修正した重要なアップデートでした。

しかし、7.0.3は7.0.2の補足修正ではありません。新たに12件のセキュリティ問題を修正した独立したセキュリティアップデートです。

ログイン画面の認証前XSSをはじめ、4件の保存型XSS、マルチサイトの権限昇格、情報漏えい、CSSインジェクション、メール確認の回避、SSRFなど、修正範囲はWordPress全体に及んでいます。

そのため、「7.0.2へ更新済みだから急ぐ必要はない」ではなく、「7.0.2で前回の脆弱性を塞ぎ、7.0.3で今回判明した別の12件も塞ぐ」と考えるのが適切です。特に今回の脆弱性はWordPress 6.xや5.x、さらには4.7系にまで影響するものが含まれています。

WordPress 7.0系を利用している場合は7.0.3へ、旧ブランチを事情があって継続利用している場合も、それぞれのブランチで提供されている最新のセキュリティ修正版へ早めに更新しておきましょう。