WordPress 7.0.3が2026年8月6日に公開されました。日本語の告知は8月7日に出ています。新しい機能を追加するリリースではなく、セキュリティの修正だけを目的としたWordPressのマイナーアップデートです。修正された脆弱性は12件あります。
WordPressの管理画面に更新の通知が出ていても、何が直ったのか分からないまま更新ボタンを押すのは気持ちのよいものではありません。この記事では、7.0.3で修正された12件を「誰が悪用できるのか」で4つに分けて解説し、自分のWebサイトがどれくらい急いで対応すべきかを判断できるように整理します。あわせて、WordPress本体を安全に更新する手順と、うまくいかなかったときの戻し方も書きます。
WordPress 7.0.3は何のリリースなのか
WordPressのバージョン番号は3つの数字でできています。7.0.3であれば、7がメジャー、0がマイナー、3がその中の更新回数です。今回上がったのは3つ目の数字なので、機能は増えていません。
メジャーアップデートとマイナーアップデートの違い
WordPressのメジャーアップデートは、編集画面や管理画面の仕様が変わるリリースです。2026年5月に公開された7.0がこれにあたり、管理画面の見た目が変わったことで戸惑った運用者は多かったはずです。テーマやプラグインとの互換性が崩れる可能性があるため、事前の確認が必要になります。
マイナーアップデートは、その裏返しです。目的はセキュリティホールの修正とバグの修正に絞られており、見た目や機能は変わりません。だからWordPressはマイナーアップデートを既定で自動更新の対象にしています。7.0.3はこのマイナーアップデートです。
自分のサイトのWordPressバージョンを確認する方法
確認する方法は2つあります。まずWordPressの管理画面にログインし、ダッシュボードの右下または「更新」の画面を開くと、現在のバージョン番号が表示されます。「WordPressの最新版が利用可能です」という表示が出ていれば、まだ7.0.3が当たっていません。「最新バージョンです」と出ていれば、自動更新で当たり終わっています。
「ツール」の中にある「サイトヘルス」を開くと、WordPress本体だけでなくプラグインやテーマ、サーバーのPHPのバージョンまで一覧で見られます。更新の判断をするときは、こちらの画面を見るほうが確実です。サーバー環境が古いままだと本体の新しいバージョンが求める条件を満たせないことがあるため、PHPの表示もあわせて確認してください。
7.0.3で修正された12件の脆弱性
WordPress 7.0.3が修正した12件は、種類も深刻度もばらばらです。公表された評価では、12件のうち3件が比較的深刻で、最も高いものは10点満点の8.9で「高」に分類されています。ただし点数の高さだけで自分のサイトの緊急度は決まりません。悪用するために攻撃者が何を持っていなければならないかで、リスクの大きさはまったく変わります。
誰でも到達できる1件
最も深刻なのは、WordPressのログイン画面に見つかった反射型のクロスサイトスクリプティングです。CVE-2026-64638として公開されており、報告したのはpwn.aiのチームです。
これが他の11件と決定的に違うのは、悪用にログインが要らない点です。ログイン画面はどのWebサイトでも外部に開いています。攻撃者は細工したURLを管理者に踏ませることで、条件が揃えばPHPのプログラムを実行できるところまで到達しうると説明されています。管理者を狙った標的型のフィッシングと組み合わせる必要はありますが、前提として必要な権限がゼロという点で、今回のリリースの緊急度を決めているのはこの1件です。
記事を書ける人だけが悪用できる5件
次の5件は、投稿を作成できる権限を持った利用者でなければ悪用できません。絵文字の設定要素を経由した保存型のクロスサイトスクリプティング、投稿コンテンツブロックの保存型クロスサイトスクリプティング、クイック編集機能の保存型クロスサイトスクリプティング、投稿日ブロックの保存型クロスサイトスクリプティング、そしてCSS属性のフィルターを回避できる問題です。前の4件は寄稿者以上、CSSの1件は投稿者以上の権限が必要です。
このグループのリスクは、サイトの運営形態で大きく変わります。管理者が自分ひとりだけで、外部の誰にもアカウントを配っていないサイトであれば、悪用できる人間がそもそも存在しません。一方、社内の複数部署に寄稿者アカウントを配っている、外部ライターに記事の投稿権限を渡している、会員が記事を投稿できる仕組みを持っているといったサイトでは、実際に踏まれうる問題として扱う必要があります。
見えてはいけない情報が漏れる3件
3つ目のグループは、権限がなくても情報が読み取れてしまう問題です。WordPressの最新コメントブロックがパスワード保護した投稿のコメントを表示してしまう問題、投稿スラッグを外部から総当たりで列挙できる問題、コメントフィードに非公開のはずのメモが出てしまう問題の3件です。
サイトが乗っ取られる種類の問題ではありません。ただ、パスワードをかけた投稿や公開前の下書きで社外に出せない情報を扱っているなら、実害の可能性は具体的です。会員限定ページや採用の内定者向けページをパスワード保護で運用しているWebサイトは、この3件を軽く見ないほうがよいと考えています。
特定の設定をしているサイトだけが該当する3件
残る3件は、条件に当てはまるサイトだけの問題です。WordPressのマルチサイト機能を使っていてユーザー登録を開けている場合に、登録した利用者が本来作れないはずのサイトを作れてしまう権限昇格が1件。ユーザー登録時のメールアドレス確認の流れを回避できる問題が1件。URLの検証に起因して、サーバーが内部向けのアドレスへ意図せずリクエストを飛ばしてしまうSSRFが1件です。
自社の1サイトだけをマルチサイトなしで運用していて、会員登録も受け付けていないなら、このグループは該当しません。逆に、複数のサイトを1つのWordPressで束ねている場合や、会員登録フォームを開けている場合は、該当する前提で急いだほうがよい内容です。
自分のサイトはどれくらい急いで更新すべきか
12件の中身を踏まえると、判断はサイトの状態で3つに分かれます。
WordPressの自動更新を有効にしたまま運用しているサイトは、放っておいても順次7.0.3が当たります。それでも、管理画面を開いてバージョンが上がりきったかを目で確認してください。サーバーの構成によって自動更新が働かないこともあり、過去には自動更新が途中で止まったまま気づかれていなかったサイトを何度も見ています。
WordPressの自動更新をあえて止めているサイトは、いま手を動かす必要があります。独自に作り込んだテーマを使っている、更新で表示が崩れた経験があるといった理由で自動更新を切っている運用は珍しくありません。今回はマイナーアップデートで機能変更を含まないため、止めておく理由はほとんどありません。認証前に到達できる脆弱性が含まれている以上、後回しにする判断は取りにくいところです。
7.0より前のWordPressバージョンを使い続けているサイトも対象です。今回の修正は、セキュリティ修正の対象になっている4.7以降のすべてのブランチに必要に応じてバックポートされています。6系や5系のまま止まっているサイトにも、対応するバージョンの更新が出ています。ただし、WordPressが公式にサポートし動作を保証しているのは最新版だけです。古いブランチにとどまり続ける運用は、今回しのげても次のリリースで行き詰まります。
なお、次のメジャーである7.1のリリース候補版にも今回の修正はすべて含まれています。7.1を待ってから一気に上げようと考える必要はありません。
WordPressのアップデートを安全に進める手順
WordPressのマイナーアップデートは失敗しにくいリリースですが、手順を省くと戻せなくなります。作業はアクセスが少ない時間帯に、時間の余裕を持って始めてください。
1. バックアップを取る
WordPressのデータベースとファイルの両方を取ります。サーバーの管理画面に自動バックアップの機能があるなら、直近の取得日時を確認したうえで、作業前の手動バックアップを1つ追加しておくのが安全です。バックアップがない状態での更新は、問題が起きたときに打つ手がなくなります。
2. テーマとプラグインの状態を確認する
7.0.3は機能を変えないため、互換性の問題は起きにくいです。それでも、長く更新されていないプラグインを抱えているサイトでは、WordPress本体側の内部の変更で動作が変わることがあります。サイトヘルスで警告が出ているプラグインがあれば、先に目を通しておきます。
制作会社に作ってもらった独自テーマを使っているサイトも、7.0.3であれば独自テーマが原因で壊れる可能性は低いです。ただし親テーマのファイルを直接書き換えている場合は、更新でその変更が消える種類の作業をしていないかを事前に確認してください。wp-content内のテーマを子テーマで管理していれば影響を受けません。
3. WordPress本体を更新して表示を確認する
「更新」の画面から「今すぐ更新」をクリックするだけです。更新中は一時的にメンテナンス画面が表示され、通常は1分ほどで完了します。終わったら管理画面ではなく、実際の公開ページを見てください。トップページ、記事ページ、問い合わせフォーム、会員向けのページなど、自分のサイトで大事な導線を順に開いて表示と動作を確認します。
更新そのものは1分で終わりますが、時間がかかるのは前後の作業です。バックアップの取得と更新後の表示確認を含めると、小規模なサイトでも30分程度は見ておくとよいでしょう。
4. 不具合が発生したときは戻す
画面が真っ白になった、エラーが表示された、メンテナンス画面から切り替わらないといった症状が発生したときは、原因を探すより先に落ち着いて切り分けます。メンテナンス画面から戻らないだけであれば、FTPやサーバーのファイルマネージャーでWordPressのディレクトリ直下にある.maintenanceファイルを削除すれば表示が戻ります。表示が崩れている場合は、プラグインをすべて停止して1つずつ有効化していけば、原因のプラグインが特定できます。それでも戻らないときに使うのが、手順1で取ったバックアップです。
アップデート前に押さえておく注意点
注意点として押さえておきたいのは、作業の順番です。WordPress本体を先に上げてからテーマとプラグインを最新版にするか、逆にするかで結果が変わることがあります。本体が求める条件にプラグインが追いついていないケースを避けるため、本体を上げたあとにプラグインとテーマを更新し、そのつど表示を確認する順番をおすすめします。
管理画面から更新できないときは手動で置き換える
管理画面のワンクリック更新が使えない環境もあります。その場合はWordPress.orgから最新版をダウンロードし、FTPでファイルを置き換える方法があります。更新が途中で止まってしまうサイトでも使える方法ですが、置き換えてはいけないディレクトリがあるため、通常は管理画面からの更新で済ませるほうが安全です。
WordPressのアップデートを放置するリスク
脆弱性の情報は、修正版が出た時点で公開されます。つまり更新をしないまま置いておくと、「どこに穴があるか」を攻撃者が知っている状態で運用を続けることになります。修正が出てから悪用されるまでの時間は年々短くなっており、いまは日ではなく時間の単位で数えるべきだという指摘も出ています。
アクセス数の少ないサイトだから狙われないという考え方は、ここでは当てはまりません。攻撃は人が1つずつサイトを選んで行うものではなく、自動化されたプログラムの巡回で行われます。古いバージョンが表に出ているだけで対象になります。
実際に侵入されると、サイトの改ざん、外部サイトへの誘導、管理者アカウントの追加、迷惑メールの送信元にされるといった被害が発生します。復旧には、侵入経路の特定、汚染されたファイルの洗い出し、バックアップからの復元、パスワードの全面的な入れ替えが必要になり、更新を1回当てる手間とは比較にならない時間と費用がかかります。私が実際に対応した侵害では、復旧そのものより「どこから入られたのか」を突き止める作業に最も時間を取られました。
更新の判断を毎回自分で背負わないために
今回のリリースを読んで改めて思ったのは、12件という数字よりも「そのうちどれが自分のサイトに当てはまるのか」を判断できる状態が大事だということです。会員登録を開けているか、外部に投稿権限を渡しているか、マルチサイトかどうか。この3つを知っていれば、今回のように内訳を追う時間はほとんど要りません。逆に、自分のサイトの構成を把握していないと、WordPressのリリースがあるたびに同じ調べ物を繰り返すことになります。
