2026年8月12日（米国現地時間）、WordPress 7.0.4が公開されました。

今回の7.0.4は、新機能の追加や一般的な不具合修正を目的としたアップデートではなく、セキュリティ上の問題を修正するためのリリースです。WordPress公式も、セキュリティリリースであることを理由に、サイトを速やかに更新するよう推奨しています。

修正されたのは、特定の環境において、投稿者以上の権限を持つユーザーが悪意のあるファイルをアップロードすることで、リモートコード実行（RCE）につながる可能性がある脆弱性です。

WordPress 7.0.2、7.0.3とセキュリティ関連の更新が続いていることもあり、「7.0系にまた問題が見つかったのか」と感じる方もいるかもしれません。

しかし今回の問題は、WordPress 7.0で新しく発生したものではありません。7.0.3と同様にWordPress 4.7までさかのぼって修正版が提供されており、かなり以前から存在していた問題が新たに発見されたものと考えるのが適切です。

この記事では、WordPress 7.0.4で修正された脆弱性について、できるだけ分かりやすく解説します。

公式情報

英語

• Version 7.0.4 – Documentation – WordPress.org
• WordPress 7.0.4 Release – WordPress News
• Remote code execution vulnerability via malicious file upload by an Author level user or higher · Advisory · WordPress/wordpress-develop · GitHub

従前：WordPress 7.0.2・7.0.3 での修正ポイント

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

WP Pilot

【メモ】WordPress 7.0.2／6.9.5／6.8.6で修正された脆弱性について

WP Pilot

WordPress 7.0.4はセキュリティリリース

WordPress 7.0.4は、2026年8月12日に公開されました。

WordPress公式ドキュメントでは、今回のリリースについてセキュリティ修正を含むことが案内されており、サイトを直ちに更新することが推奨されています。

今回公表されている主な問題は、ImagickとGhostscriptを利用しているサイトにおいて、認証済みの投稿者以上のユーザーが悪意のあるファイルをアップロードすることで、リモートコード実行が可能になる問題です。

脆弱性には「CVE-2026-65640」という識別番号が割り当てられています。GitHub Security Advisoryでは深刻度が「High」と評価され、CVSSスコアは8.8 / 10です。

CVSSとは、脆弱性の危険度を数値化するために広く使われている指標です。10に近いほど重大な問題と考えられます。

WordPress 7.0.4での修正ポイント

今回問題になった「RCE」とは？

今回の脆弱性で特に注目しておきたいのが、RCE（Remote Code Execution：リモートコード実行）です。RCEとは、外部からサーバー上で本来想定されていない命令やコードを実行できてしまう問題を指します。

脆弱性を悪用される条件やサーバーの設定によって被害は異なりますが、RCEが成立すると、以下のような被害につながる可能性があります。

• サーバー内のファイルを読み取られる
• ファイルを書き換えられる
• 不正なプログラムを設置される
• 不正経路（バックドア）を設置される
• サイトを改ざんされる
• 情報を盗まれる
• サイトやサーバーを停止させられる

GitHub Security Advisoryでも、今回の脆弱性について「機密性」「完全性」「可用性」のすべてへの影響がHighと評価されています。

つまり、攻撃が成立するためにはいくつか条件が必要なものの、成立した場合の影響は大きい脆弱性と考えてよいでしょう。

ImagickとGhostscriptが関係する脆弱性

今回の脆弱性を理解するうえで重要なのが、「Imagick」「Ghostscript」という2つの仕組みです。

Imagickは、PHPからImageMagickという画像処理ソフトウェアを利用するための拡張モジュールです。WordPressでは画像をアップロードした際に、「サムネイルを生成する」「画像サイズを変更する」「画像を編集する」といった処理で利用される場合があります。

一方、Ghostscriptは、PostScriptやPDFなどのファイルを処理するために広く使われているソフトウェアです。

GitHub Security Advisoryによると、今回問題となっている環境では、ImagickとGhostscriptの両方がサーバーで使用されていることが攻撃成立の前提条件となっています。

さらに、問題そのものについては、Ghostscriptが特定の埋め込みファイルを処理する方法に弱点があると説明されています。

大まかな流れを整理すると、次のようになります。

1. WordPressへ悪意のあるファイルをアップロード
2. WordPressがImagickを使って画像処理
3. ImagickからGhostscriptが呼び出される
4. 細工されたファイルがGhostscriptによって処理される
5. サーバー上で意図しないコードが実行される可能性

WordPress単体の単純なPHPの不具合というよりも、WordPressのファイルアップロード処理と、サーバー側の画像処理ソフトウェアが組み合わさることで成立する問題と見ると分かりやすいでしょう。

悪意のあるPostScriptファイルが利用される

今回のセキュリティ情報では、悪意のあるPostScriptファイルのアップロードが攻撃手段として説明されています。

PostScriptは、ページや印刷データの内容を記述するために使われる言語・ファイル形式です。

一般的なWordPressサイトでは、「JPEG」「PNG」「WebP」「GIF」「AVIF」などと比較すると、PostScript形式のファイルを日常的に扱うことは少ないでしょう。

しかし、「普段PostScriptを使わないサイトなら問題ない」という意味ではありません。攻撃者が意図的に細工したファイルをWordPressへアップロードし、サーバー側に処理させることが問題となります。

そのため、WordPress側でも危険なファイルが処理されないよう対策する必要があります。

誰でも攻撃できるわけではない

今回の脆弱性には、もう一つ重要な条件があります。

攻撃者には、WordPressへファイルをアップロードできる権限が必要です。GitHub Security Advisoryでは、upload_files 権限を持つ悪意のあるユーザーが前提とされています。

WordPress標準の権限では、おおむね次のようになります。

• 購読者： 不可
• 寄稿者： 不可
• 投稿者： 可能
• 編集者： 可能
• 管理者： 可能

つまり今回の脆弱性は、WordPressにアクセスしてきた未ログインの第三者が、いきなり攻撃できるタイプではありません。原則として、投稿者以上の権限を持つ認証済みユーザーが必要です。

この点は、今回の危険度を考えるうえで重要です。

運用状況によって悪用のハードルは異なる

例えば、以下のような一般的な個人ブログの場合、今回の脆弱性を直接悪用するためのハードルは高くなります。

• WordPressユーザーが自分一人しかいない
• 管理者アカウントしか作成していない
• 第三者へ投稿者権限を与えていない

攻撃者がPostScriptファイルをアップロードするためには、まずアップロード権限を持つアカウントを利用できなければならないためです。

一方で、特に注意しておきたいのが複数ユーザーで運用しているWordPressサイトです。

• 複数人で記事を投稿しているサイト
• 外部ライターへ投稿者権限を付与しているサイト
• 会員がコンテンツを投稿できるサイト
• 社内CMSとして使っているWordPress
• ユーザー投稿型サービス
• 不特定多数へ比較的高い権限を付与しているサイト

などでは、個人ブログよりもリスクが高くなります。

また、別の方法で投稿者アカウントが乗っ取られた場合に、今回の脆弱性を組み合わせて攻撃される可能性も考えられます。

何はともあれ、「ログインが必要だから安全」と判断するのではなく、更新できるのであれば修正版へ更新しておくことが基本です。

CVSS 8.8と評価されている理由

今回の脆弱性は、CVSS 3系で8.8と評価されています。

内訳は次のようになっています。

• Attack Vector（攻撃経路）： Network
• Attack Complexity（攻撃難易度）： Low
• Privileges Required（必要権限）： Low
• User Interaction（ユーザー操作）： None
• Confidentiality（機密性への影響）： High
• Integrity（完全性への影響）： High
• Availability（可用性への影響）： High

つまり、低い権限ながら何らかの権限は必要である一方、攻撃成立後の影響は非常に大きいという評価です。

未認証で簡単に攻撃できる脆弱性ほど危険ではありませんが、条件がそろった環境では深刻な被害につながる可能性があります。

WordPress 7.0.4で変更されたファイルは1つだけ

今回の更新で興味深いのが、WordPressコアで変更されたファイルの少なさです。

WordPress 7.0.4で変更されたファイルとして公式ドキュメントに記載されているのは、/wp-includes/class-wp-image-editor-imagick.phpの1ファイルだけです。これは、WordPressでImagickを利用した画像処理を担当しているファイルです。

また、WordPress公式によれば、今回変更されたパッケージはありません。

つまり7.0.4は、WordPressの機能を広く変更するアップデートではなく、Imagick周辺のセキュリティ問題を修正するための非常に限定的な更新と考えられます。

更新による影響範囲という意味では、比較的小さなリリースといえるでしょう。

WordPress 7.0だけの問題ではない

過去バージョンについても修正版が提供されている

今回特に注意したいのが、WordPress 7.0で新しく発生した脆弱性ではないことです。

WordPress公式では、WordPress 6.9、6.8、6.7……と過去のバージョンについても修正版を公開しています。前回同様、WordPress 4.7まで修正がバックポートされています（WordPress 4.6以前については、セキュリティアップデートの対象外です）。

ここからも、今回の脆弱性がWordPress 7.0特有の新しい機能によって発生した問題ではなく、長期間存在していた処理に関係する問題だったことが分かります。

なお、WordPress公式は古いブランチにも修正版を提供していますが、現在積極的にサポートされているのは最新バージョンであることも案内しています（この辺りもいつも通りですね）。

可能であれば、古いWordPressを修正版へ更新するだけでなく、最新系列への移行も検討した方がよいでしょう。

7.0.2・7.0.3の問題とは別物

WordPress 7.0系では、短期間にセキュリティアップデートが続いています。そのため、「7.0.2や7.0.3で修正した問題を、7.0.4でもう一度修正したのでは？」と思われるかもしれません。

しかし、修正された箇所はそれぞれ全く異なります。

例えば、WordPress 7.0.2では、WP_Queryのauthor__not_inパラメータに関係するSQLインジェクションと、REST APIのバッチルートに関係する問題などが修正されました。これらが組み合わさることで、特定のバージョンではRCEにつながる可能性も指摘されていました。

一方、今回の7.0.4は、「悪意のあるファイルアップロード」「Imagick・Ghostscript・PostScript」「投稿者以上の権限」「リモートコード実行」という、まったく異なる経路の脆弱性です。

また、今回の問題も7.0.3と同様にWordPress 4.7まで影響するため、WordPress 7.0で追加された新機能が直接の原因とは考えにくいでしょう。

そのため、「7.0.2や7.0.3の修正が不十分だったので7.0.4が必要になった」と理解するのは適切ではありません。むしろ、それぞれ別々に発見されたセキュリティ問題に対して、修正版が順次提供されていると考えた方が実態に近いでしょう。

「WordPress 7.0は不具合だらけ」という意味ではない

7.0.2、7.0.3、7.0.4と短期間にバージョン番号が増えると、「WordPress 7.0は品質に問題があるのではないか」と感じる方もいるかもしれません。

しかし、セキュリティリリースの回数だけを見て判断するのは少し注意が必要です。

今回の脆弱性やWordPress 7.0.3で修正された箇所のように、過去のバージョンにも長期間存在していた問題が、新しいバージョンの公開後に発見されるケースもあります。その場合、現在の最新版だけでなく、影響する旧バージョンにも修正が提供されます。今回もWordPress 4.7まで修正版が用意されています。

したがって、「WordPress 7.0にしたことで脆弱性が増えた」というより、以前から存在していた問題が発見され、現在利用されているWordPressへ修正が適用されたという面が大きいと考えられます。

セキュリティアップデートが公開されること自体は、脆弱性への対応が行われているという意味でもあります。

WordPress 7.0.4には更新した方がよい？

基本的には、7.0.4への更新をおすすめします。WordPress公式も、今回がセキュリティリリースであることから速やかな更新を推奨しています。

特に、以下のような環境では、優先度を高めに考えた方がよいでしょう。

• 複数ユーザーでWordPressを運営している
• 投稿者権限を第三者へ付与している
• 会員投稿機能を設けている
• Imagickを利用している
• サーバーでGhostscriptが利用されている

一方、自分一人だけが管理者として利用している個人ブログでは、攻撃成立の条件を満たしにくいため、今回の脆弱性だけを見ればリスクは比較的低いと考えられます。

それでも、7.0.4で変更されているWordPressコアファイルはImagick関連の1ファイルだけであり、7.0.3へとどまり続ける積極的な理由はほとんどありません。普段どおりバックアップを確認したうえで、7.0.4へ更新しておくのがよいでしょう。

更新後はサイトの基本動作も確認しておこう

今回の変更範囲は限定されていますが、WordPress本体を更新した後は簡単な動作確認をおすすめします。

特に、以下の部分を確認すると安心です。

• 管理画面へログインできるか
• 投稿・固定ページを編集できるか
• 画像をアップロードできるか
• サムネイルが正常に生成されるか
• JPEG・PNG・WebPなどが正常に処理されるか
• フロントページが正常に表示されるか
• エラーログに異常が出ていないか

今回はclass-wp-image-editor-imagick.phpが変更されているため、特に画像アップロードや画像生成周辺を軽く確認しておくとよいでしょう。

まとめ：7.0.4は対象条件が限定されるものの、重要なセキュリティ更新

WordPress 7.0.4では、ImagickとGhostscriptを利用する特定の環境において、投稿者以上のユーザーが悪意のあるファイルをアップロードすることで、リモートコード実行につながる可能性がある脆弱性が修正されました。

今回のポイントをまとめると、以下のような内容になります。

• WordPress 7.0.4は2026年8月12日に公開されたセキュリティリリース
• 悪意のあるPostScriptファイルが攻撃に利用される可能性がある
• ImagickとGhostscriptを利用している環境が前提
• 攻撃にはupload_files権限が必要
• 標準環境では投稿者以上のユーザーが主な対象
• 成立するとRCEにつながる可能性がある
• WordPress 4.7以降の広いバージョンが影響を受ける
• 7.0.4で変更されたWordPressコアファイルはImagick関連の1ファイル
• 7.0.2や7.0.3のセキュリティ問題とは基本的に別件

特に覚えておきたいのは、「WordPress 7.0で新たに生まれた問題ではない」という点です。

WordPress 4.7まで修正版が提供されていることからも分かるように、以前から存在していた処理に関係する脆弱性が新たに発見されたものです。

7.0.2、7.0.3、7.0.4とセキュリティリリースが続いていますが、それぞれを一括して「7.0の品質問題」と見るのではなく、どの機能にどのような脆弱性が発見されたのかを個別に確認することが大切です。

今回については攻撃成立の条件こそ限定されていますが、RCEという性質上、成立した場合の影響は小さくありません。

WordPress 7.0.3以前を利用している場合は、バックアップと基本的な動作確認を行いつつ、WordPress 7.0.4へ更新しておくことをおすすめします。

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で修正されたセキュリティ上の問題をできるだけ分かりやすく解説します。

【追記】追加のセキュリティアップデートが実施されました

2026年8月12日には、WordPress 7.0.4 / 6.9.7 / 6.8.8 などの追加のセキュリティアップデートが実施されました。そのため、早急に現行バージョンにアップデートいただくことをおすすめいたします。

「WordPress 7.0.4」セキュリティアップデート――Imagick・Ghostscriptを悪用したRCE脆弱性を修正

WP Pilot

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

• 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.2／6.9.5／6.8.6で修正された脆弱性について

WP Pilot

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

2026年7月、WordPress本体に関する深刻な脆弱性「wp2shell」が公表されました。

wp2shellは、第三者がWordPressの管理画面にログインしていない状態でも、条件を満たすサイトを外部から攻撃できる可能性がある脆弱性です。

WordPress本体の更新によって問題は修正されていますが、「実際に被害は発生しているのか」「具体的に何をされたのか」が気になる方も多いのではないでしょうか。

結論から言うと、wp2shellを悪用した実際の侵入や、不正なプログラムの設置はすでに確認されています。

一方で、本日2026年7月30日時点では、被害を受けた企業や団体の名前、個人情報の漏えい件数、金銭的な被害額などを明らかにした事例は、ほとんど公表されていません。

この記事では、セキュリティ企業などから公表されている代表的な攻撃事例を、できるだけ分かりやすく紹介します。

wp2shellとは？

wp2shellは、WordPress本体に見つかった複数の問題を組み合わせることで、外部の攻撃者がWordPressサイトを乗っ取れる可能性がある脆弱性です。

主に、次の2件の脆弱性が関係しています。

• CVE-2026-60137
• CVE-2026-63030

これらを組み合わせることで、攻撃者がWordPressの管理者権限を取得し、最終的にはサーバー上で不正なプログラムを動かせる可能性があります。このように、離れた場所からサーバー上でプログラムや命令を実行できる問題を「リモートコード実行」、略してRCEと呼びます。

wp2shellが特に深刻なのは、特定のプラグインやテーマを導入していなくても、WordPress本体だけで影響を受ける可能性がある点です。

発見者であるSearchlight Cyberは、初期の案内において、プラグインを追加していない標準的なWordPress環境でも、ログインしていない第三者から攻撃できる問題だと説明しています。

wp2shellによる攻撃はすでに確認されている

wp2shellは、単に「理論上は攻撃できる」という段階ではありません。

クラウドセキュリティ企業のWizは、2026年7月20日、実際のWordPress環境に対してwp2shellが悪用されていることを確認したと発表しました。

Wizの調査では、複数の攻撃者がクラウド上で運用されているWordPressサイトへの侵入に成功し、その後、不正なプラグインやWebシェルを設置していたとされています。Webシェルとは、攻撃者が外部からサーバーを操作するために設置する、不正なプログラムの一種です。

簡単に表現すると、WordPressの玄関から侵入した攻撃者が、その後も自由に出入りできるよう、サーバー内に別の裏口を作るようなものです（一般にこの「不正に設置された裏口経路」のことを「バックドア」と言います）。

被害事例1：不正なプラグインを設置された

Wizが確認した代表的な事例の一つが、不正なWordPressプラグインの設置です。

攻撃者はWordPressのプラグインアップロード機能を利用し、不正なプログラムを含むプラグインをサイトに追加していました。

通常、WordPressの管理者は、管理画面の「プラグイン」からZIP形式のプラグインをアップロードできます。

wp2shellによって管理者権限を取得されると、この正規の機能が攻撃者に悪用される可能性があります。

不正なプラグインが設置されると、攻撃者はWordPressの脆弱性を修正した後も、別に作られた裏口から再びサーバーを操作できるおそれがあります。

そのため、wp2shellの影響を受ける期間にサイトを公開していた場合は、WordPressを更新するだけでなく、身に覚えのないプラグインが追加されていないかも確認する必要があります。

被害事例2：簡単なPHP製のバックドアを設置された

Wizは、非常に短いPHPコードで作られたWebシェルの設置も確認しています。PHPとは、WordPressを動かすために使われているプログラミング言語です。

確認されたWebシェルは、攻撃者から特定の命令を受け取ると、その命令をサーバー上で実行する仕組みになっていました。

また、通常のアクセスに対しては「ページが見つからない」という404エラーを返すことで、不正なファイルの存在を隠そうとしていたとされています。

このようなWebシェルは非常に短いコードで作れるため、ファイルの名前や保存場所によっては、目視だけで発見することが難しい場合があります。

被害事例3：「CMSmap」を装った大規模な攻撃ツール

Wizが確認した中には、「CMSmap」という名前を使用した、約150KBの不正なWebシェルもありました。

CMSmap自体は、WordPressなどのCMSを調査するために使われる正規のセキュリティツールです。しかし、今回発見されたものは、正規のツールやプラグインに見せかけながら、内部に本格的な攻撃機能を備えていました。

具体的には、次のような機能が含まれていたと報告されています。

• サーバー内のファイルを閲覧・変更する
• WordPressのデータベースへアクセスする
• ネットワーク上のポートを調べる
• 複数のファイルへ一括で不正なコードを埋め込む
• サーバー内でより強い権限を取得しようとする

さらに、不正なコードは圧縮や文字列の変換によって読みにくくされていました。これは、不正なプログラムであることを管理者やセキュリティ製品から見つかりにくくするための処理と考えられます。

単なる実験的な攻撃ではなく、侵入後にさまざまな操作を行うための本格的な攻撃ツールが持ち込まれていたことが分かります。

被害事例4：攻撃者専用のREST APIを作られた

別の事例では、不正なプラグインによって、攻撃者専用のREST APIがWordPress内に追加されていました。

REST APIとは、外部のプログラムとWordPressがデータや命令をやり取りするための仕組みです。

正しく使用すれば便利な機能ですが、不正なプラグインによって攻撃者専用の入口を作られると、外部から自由に命令を送れるようになります。

Wizが確認した不正プラグインでは、攻撃者が特定のURLへ命令を送ることで、サーバー上のコマンドを実行し、その結果を受け取れる仕組みが作られていました。

つまり、WordPressの管理画面へログインしなくても、攻撃者が外部からサーバーを操作できる状態になっていたということです。

被害事例5：管理者のユーザー名やメールアドレスを収集された

wp2shellによる侵入後、WordPressのユーザー情報を取得するREST APIへアクセスする動きも確認されています。攻撃者は、WordPressの管理者ユーザー名やメールアドレスを収集しようとしていました。

管理者のユーザー名やメールアドレスが知られただけで、すぐにサイトへ侵入されるとは限りません。しかし、次のような別の攻撃に利用される可能性があります。

• 管理者を狙ったフィッシングメール
• パスワードの総当たり攻撃
• 他のサービスで使い回しているパスワードの悪用
• 本物の管理会社を装った偽メール
• WordPressの更新通知を装った詐欺

特に、管理者メールアドレスが一般に公開されていない場合は、攻撃によって取得された情報が、その後の標的型攻撃に利用される可能性があります。

被害事例6：wp-config.phpを狙った攻撃

攻撃者が、WordPressの重要な設定ファイルであるwp-config.phpを読み取ろうとした動きも報告されています。

wp-config.phpには、一般的に次のような重要情報が記載されています。

• データベース名
• データベースのユーザー名
• データベースのパスワード
• データベースサーバーの情報
• WordPressの認証用キー

Wizが確認した攻撃では、別のファイルを読み込む仕組みを悪用し、wp-config.phpの情報を取得しようとする試みが行われていました。これらの情報を取得されると、WordPressの投稿やユーザー情報が保存されているデータベースへ、直接アクセスされる可能性があります。

ただし、Wizは2026年7月20日の報告時点で、実際のデータ流出や他のサーバーへの侵入拡大までは確認していないと説明しています。

したがって、「設定ファイルを狙う攻撃は確認されたものの、情報が実際に持ち出されたことまで確認されたわけではない」という点には注意が必要です。

Wordfenceでも公表直後から攻撃を観測

WordPress向けセキュリティプラグインを提供するWordfenceも、wp2shellの公表直後から攻撃とみられる通信を確認しています。

Wordfenceによると、WordPressの修正版が公開された2026年7月17日のうちに、REST APIのバッチ処理機能を調査するようなアクセスが始まりました。

その後、同日のうちにSQLインジェクションを試みる明確な攻撃が確認されたとされています。

SQLインジェクションとは、データベースへの命令を不正に操作し、本来は取得できない情報を読み取ったり、データを書き換えたりする攻撃方法です。

Wordfenceの報告では、次のような流れが示されています。

• 2026年7月17日：WordPressの修正版を公開
• 同日中：REST APIのバッチ処理機能を調べる通信を確認
• その約13分後：SQLインジェクションを狙う通信を確認
• 7月18日から19日：脆弱性を再現するコードが広まり始める
• 7月20日：詳しい技術情報や確認用ツールが公開される

WordPressの修正版が公開されてから、非常に短い時間で攻撃が始まっていたことが分かります。

被害を受けた企業やサイトの実名は公表されている？

2026年7月30日時点では、wp2shellによって被害を受けた企業、自治体、学校、個人サイトなどの具体的な名前は、広く公表されていません。

また、次のような情報も、現時点では確認できる範囲が限られています。

• 個人情報が何件漏えいしたのか
• クレジットカード情報が盗まれたのか
• サイトが改ざんされた具体的な件数
• 金銭的な被害額
• ランサムウェア攻撃につながった事例
• 日本国内で発生した具体的な被害

そのため、「○○社で何万人分の情報が漏れた」というような、社会的に広く知られた被害事例は、まだ表に出ていない状況です。

ただし、被害者の名前が公表されていないからといって、被害が発生していないわけではありません。

セキュリティ企業の監視データでは、実際の侵入、不正プラグインのアップロード、Webシェルの設置、管理者情報の収集などがすでに確認されています。

サイト訪問者にも影響する可能性がある

wp2shellによってWordPressサイトが乗っ取られると、被害はサイト管理者だけにとどまらない可能性があります。

攻撃者がサイトの内容を自由に変更できるようになった場合、次のようなことが行われるおそれがあります。

• 不正なサイトへ自動転送する
• 偽のログイン画面を表示する
• マルウェアをダウンロードさせる
• 詐欺広告や偽の警告画面を表示する
• 投稿本文やリンクを書き換える
• 通販サイトの決済画面へ不正なコードを入れる

ただし、これらはWordPressサイトが完全に乗っ取られた場合に起こり得る被害です。

2026年7月30日時点では、「wp2shellによって侵害された特定のサイトから、多数の閲覧者がマルウェアに感染した」といった具体的な事例は、広く公表されていません。

Malwarebytesも、侵害されたWordPressサイトを訪問した利用者に起こり得る危険を説明していますが、すべてが実際に確認されたwp2shellの被害事例というわけではありません。

WordPressを更新すれば、それだけで十分なのか

wp2shellへの基本的な対策は、WordPress本体を修正版へ更新することです。

【メモ】WordPress 7.0.2／6.9.5／6.8.6で修正された脆弱性について

WP Pilot

WordPressでは、2026年7月17日に次の修正版が公開されました。

• WordPress 7.0.2
• WordPress 6.9.5
• WordPress 6.8.6

WordPress 6.9系と7.0系では、wp2shellの完全な攻撃経路につながる問題が修正されています。

WordPress 6.8系では、完全なRCEにつながる条件は異なるものの、関連するSQLインジェクションの問題が修正されているため、6.8.6への更新が必要です。

ただし、脆弱な期間中にすでに侵入されていた場合は、更新しただけでは不十分な可能性があります。

攻撃者が不正なプラグインやWebシェルを設置していた場合、WordPress本体を更新しても、設置された裏口はそのまま残ることがあるためです。

サイト管理者が確認したいポイント

WordPress 6.8系、6.9系、7.0系を使用しているサイトでは、まず修正版への更新が完了しているか確認しましょう。

そのうえで、次のような点も確認することが推奨されます。

管理者ユーザーを確認する

「ユーザー」画面を開き、身に覚えのない管理者アカウントが追加されていないか確認します。

攻撃者が管理者アカウントを作成した場合、WordPressを更新した後も、そのアカウントから再びログインされる可能性があります。

不審なプラグインを確認する

最近追加されたプラグインや、名前に覚えのないプラグインがないか確認します。

ただし、見覚えがないという理由だけで、すぐに削除するのは避けた方がよいでしょう。制作会社や管理担当者が導入している可能性もあるため、必要に応じてバックアップを取得し、担当者へ確認してください。

最近変更されたPHPファイルを確認する

テーマやプラグインのPHPファイルが、管理者の操作なしに変更されていないか確認します。

特に、通常は使用していない場所に新しいPHPファイルが作られている場合は注意が必要です。

アクセスログを確認する

サーバーのアクセスログで、次のようなURLへの不審なアクセスがないか確認します。

• /wp-json/batch/v1
• ?rest_route=/batch/v1
• /wp-admin/update.php?action=upload-plugin
• /wp-json/wp/v2/users?context=edit

ただし、これらのURLへのアクセスがあるだけで、必ず侵入されたとは限りません。

セキュリティ調査や単なるスキャンでもアクセスされる可能性があるため、前後の通信内容や応答結果も含めた確認が必要です。

セキュリティスキャンを実施する

Wordfenceなどのセキュリティプラグインや、サーバー会社が提供するマルウェアスキャンを利用する方法もあります。

ただし、スキャンですべての不正ファイルを必ず発見できるとは限りません。

不審な管理者アカウントやファイルが見つかった場合は、制作会社、サーバー会社、セキュリティ専門業者への相談も検討しましょう。

まとめ

wp2shellについては、実際のWordPressサイトに対する攻撃がすでに確認されています。

公表されている代表的な事例には、次のようなものがあります。

• 不正なWordPressプラグインのアップロード
• 簡単なPHP製Webシェルの設置
• CMSmapを装った本格的な攻撃ツールの設置
• 攻撃者専用REST APIの作成
• 管理者のユーザー名やメールアドレスの収集
• wp-config.phpを狙った情報取得の試み
• WordPress管理画面への不正アクセス

一方で、被害を受けた企業やサイトの実名、情報漏えい件数、被害金額などは、2026年7月30日時点ではほとんど公表されていません。

つまり、現在の状況は次のように整理できます。

脆弱なバージョンを公開状態で使用していた場合は、直ちに最新バージョンへ更新してください。また、そこで安心せず、不審な管理者、不正なプラグイン、最近変更されたファイルなども確認しておくことが大切です。

参考情報

日本語の情報

• IPA：WordPressの脆弱性対策について（CVE-2026-60137、CVE-2026-63030）
• WordPress 7.0.2リリース – WordPress.org 日本語

海外の情報（英語）

• Version 7.0.2 – Documentation – WordPress.org
• wp2shell: Pre Authentication RCE in WordPress Core › Searchlight Cyber
• Exploitation in the Wild of wp2shell | Wiz Blog
• wp2shell Aftermath: The First Critical Unauthenticated WordPress Core RCE in Nearly a Decade
• Malwarebytes：What happens if you visit a WordPress site hacked through wp2shell?

2026年7月17日（米国現地時間）、「WordPress 7.0.2／6.9.5／6.8.6」が緊急リリースされました。

今回のWordPress 7.0.2／6.9.5／6.8.6は、通常の小さな不具合修正ではなく、優先して適用すべきセキュリティ更新です。

特にWordPress 6.9以降では、2つの問題が組み合わさることで、最終的にサーバー上で不正なコードを実行される可能性があります。WordPress.orgは問題の重大性から、影響を受けるサイトに対して自動更新システムによる強制更新も有効にしています。

以下に詳細をまとめますので、ご参考いただけますと幸いです。

【追記】追加のセキュリティアップデートが実施されました

2026年8月6日には、WordPress 7.0.3 / 6.9.6 / 6.8.7 などの追加のセキュリティアップデートが実施されました。そのため、早急に現行バージョンにアップデートいただくことをおすすめいたします。

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

WP Pilot

公式情報

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

強制自動更新について

WordPress.orgは今回、影響を受けるバージョンに対して、自動更新システムによる強制更新を有効にしています。

このリリースはセキュリティアップデートのため、サイトをできるだけ早く更新することを推奨します。また、影響を受けるバージョンを使用しているサイトについては、問題の重大性を考慮し、WordPress.org チームが自動更新システムによる強制更新を有効にしています。

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

これは、通常の自動更新設定とは別に、重大なセキュリティ問題が発生した際、WordPress.org側が修正版の配信を強く促す仕組みです。

ただし、次のような環境では自動更新が失敗したり、実行されなかったりする可能性があります。

• WordPressからファイルを書き換える権限がない
• 自動更新関連の定数やフィルターで更新を止めている
• サーバー側で外部通信が制限されている
• WordPress.orgへの接続に失敗している
• ディスク容量やファイル数が不足している
• コアファイルを独自に変更している
• 管理型サーバー独自の更新システムを使っている

したがって、「強制更新があるから放置してよい」ということではなく、管理画面で実際のバージョンを確認することが重要です。

今回の重要ポイント

今回修正された問題は2件です。

修正版は、7.0系が7.0.2、6.9系が6.9.5、6.8系が6.8.6です。WordPress 6.8より前のバージョンは、今回の2件の問題については影響を受けないと公式に案内されています。

• WordPress 6.9は、今回の2件の脆弱性の影響を受けます。両方の修正を含む WordPress 6.9.5をリリースしました。
• WordPress 6.8は、1件目の脆弱性のみ影響を受けます。この修正を含む WordPress 6.8.6をリリースしました。
• WordPress 7.1 Beta 版は、今回の2件の脆弱性の影響を受けます。両方の修正を含む WordPress 7.1 Beta 2をリリースしました。
• WordPress 6.8より前のバージョンは、この問題の影響を受けません。

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

1件目：SQLインジェクションを容易にする問題

1件目は、WordPressの投稿取得に使われるWP_Queryのauthor__not_inというパラメーターに関係する問題です。

author__not_inは、特定の投稿者が書いた投稿を検索結果から除外するために使用します。

通常は、次のように投稿者IDを整数で指定します。

$query = new WP_Query(
	array(
		'author__not_in' => array( 3, 5, 8 ),
	)
);

ところが、修正前のWordPressでは、この部分に渡される値の処理が十分に厳しくなく、テーマやプラグインなどが外部入力を不適切に渡した場合、SQLインジェクションを成立させる余地がありました。

GitHubの公式セキュリティ情報では、この問題はWP_Queryのauthor__not_inパラメーターに存在するSQLインジェクションとして説明されています。影響範囲はWordPress 6.8.0以降で、7.0.2、6.9.5、6.8.6で修正されています。

SQLインジェクションとは

SQLインジェクションとは、データベースへ送る命令文に、不正な文字列を混ぜ込む攻撃です。

成立した場合、状況によっては次のような被害につながります。

• 投稿やユーザー情報の読み取り
• データベース内容の改ざん
• 管理者情報や設定情報の取得
• 本来表示されない情報へのアクセス
• 他の脆弱性と組み合わせた攻撃

ただし、今回の1件目だけで、すべてのWordPressサイトから無条件にデータベースを操作できるという意味ではありません。公式がfacilitated SQL injection、日本語では「SQLインジェクションを容易にする脆弱性」と表現している点が重要です。

つまり、WordPressコアの問題だけでなく、プラグインやテーマなどが外部入力をWP_Queryへ渡す処理と組み合わさることで、攻撃が成立しやすくなる問題と考えられます。

2件目：REST APIのバッチルート混同

2件目は、WordPress REST APIのバッチリクエストにおける「ルートの混同」です。

WordPress 6.9以降でこの問題が存在し、1件目のSQLインジェクションと組み合わさることで、リモートコード実行（Remote Code Execution、RCE）につながる可能性があります。

REST APIとは

REST APIは、WordPressの情報を外部のアプリケーションやJavaScriptから取得・更新する仕組みです。

例えば、次のような処理で使われます。

• ブロックエディターから投稿を保存する
• 投稿一覧を外部アプリに表示する
• ユーザーやコメント情報を取得する
• プラグインが管理画面と通信する
• ヘッドレスWordPressとして使用する

REST APIそのものが危険なのではありません。WordPressの標準機能として広く使われています。

今回問題になったのは、その中でも複数のAPI処理をまとめて送信する「バッチリクエスト」です。

バッチルートの混同とは

REST APIでは、リクエストされたURLやルートを見て、実行する処理を決定します。

例えば、投稿を取得する処理と、ユーザーを取得する処理は、それぞれ別のルートとして登録されています。

/wp-json/wp/v2/posts
/wp-json/wp/v2/users

バッチリクエストでは、複数のルートを一度に処理できます。

今回の問題では、バッチ内部のサブリクエストについて、WordPressが認識したルートと、実際に実行するルートの扱いに混同が生じる可能性がありました。

分かりやすく言えば、次のような問題です。

入力内容を確認したときの処理先と、実際に実行するときの処理先が一致しなくなる可能性があった。

これにより、本来適用されるべき入力値の検査、権限確認、エラー処理などが、正しい経路で行われない可能性があります。

リモートコード実行とは

リモートコード実行（Remote Code Execution、RCE）とは、攻撃者がインターネット経由でサーバー上のプログラムを実行できる状態です。

WordPressでRCEが成立すると、理論上は次のような被害につながります。

• 不正な管理者アカウントの作成
• プラグインやテーマの改ざん
• 不正なPHPファイルの設置
• 広告や別サイトへの不正転送
• 投稿内容の書き換え
• 個人情報や会員情報の取得
• 他サイトへの攻撃の踏み台化
• バックドアの設置

バックドアとは、攻撃者が後から再び侵入できるように設置する、隠れた侵入口のことです。そのため、RCEにつながる脆弱性は、一般的に非常に危険度が高いものとして扱われます。

2つの脆弱性が組み合わさる点が重要

今回の問題は、2件を完全に別々に考えるよりも、組み合わせて悪用できる可能性があることが重要です。

大まかな流れは次のように考えられます。

REST APIのバッチリクエストを送信
        ↓
ルートの認識や処理経路を混同させる
        ↓
WP_Queryへ不正な値を到達させる
        ↓
SQLインジェクションを成立させる
        ↓
データベースを書き換える
        ↓
WordPressが後から実行するデータや設定を改ざんする
        ↓
PHPコードなどの実行につながる

ただし、この流れは公表情報から整理した一般的な説明です。実際の攻撃手順については以下の記事にて詳しく解説しています。

【セキュリティ】WordPressの脆弱性「wp2shell」について、公表された攻撃事例を分かりやすく解説

WP Pilot

バージョンごとの影響範囲

今回の公式発表で特に重要なのは、バージョンごとに影響が異なる点です。

WordPress 7.0.0～7.0.1

2件とも影響を受けます。

• SQLインジェクションを容易にする問題
• REST APIのバッチルート混同
• 2件を組み合わせたリモートコード実行の可能性

更新先はWordPress 7.0.2です。

WordPress 6.9.0～6.9.4

7.0系と同様に2件とも影響を受けます。更新先はWordPress 6.9.5です。

WordPress 6.8.0～6.8.5

1件目のSQLインジェクションのみ影響を受けます。

REST APIのバッチルート混同はWordPress 6.9以降の問題であるため、6.8系では今回公表された組み合わせによるRCEの対象には含まれていません。

更新先はWordPress 6.8.6です。

WordPress 6.7以前

今回の2件については影響を受けないと公式発表されています。

ただし、これは「WordPress 6.7以前が安全」という意味ではありません。

古いバージョンには、過去に修正された別の脆弱性が残っている可能性があります。また、WordPress公式は最新バージョンのみを積極的にサポートすると案内しています。

As a courtesy, these fixes are also available in older affected branches of WordPress. As a reminder, only the most recent version of WordPress is actively supported.（注：強調は原文）

Version 7.0.2 – Documentation – WordPress.org

サイト運営者が行うべきこと

1．現在のWordPressバージョンを確認する

管理画面の「ダッシュボード → 更新」を開きます。

次のいずれかであれば、今回の修正は適用済みです。

• WordPress 7.0.2
• WordPress 6.9.5
• WordPress 6.8.6

2．未更新ならすぐ更新する

7.0.1以前の場合、6.9.4以前、6.8.5以前になっている場合は、更新前にバックアップを取り、現在使用中の系列の修正版へ更新します。

• 7.0.0～7.0.1 → 7.0.2
• 6.9.0～6.9.4 → 6.9.5
• 6.8.0～6.8.5 → 6.8.6

セキュリティ対応のために、7.0系から6.9系以前へ戻す必要はありません。

3．自動更新後も動作確認する

更新後は、例えば次のような事項の確認を行います。

• トップページが表示されるか
• 投稿や固定ページが表示されるか
• 管理画面へログインできるか
• ブロックエディターで保存できるか
• お問い合わせフォームが送信できるか
• 会員登録や決済が動作するか
• REST APIを使う機能が動作するか
• エラーログに新しいエラーがないか

4．不審な変更がないか確認する

未更新の状態でしばらく公開されていた場合は、念のため次も確認します。

• 身に覚えのない管理者ユーザー
• 不明なプラグインやテーマ
• 最近変更されたPHPファイル
• wp-content/uploads内のPHPファイル
• 不審なリダイレクト
• 投稿や固定ページの改ざん
• .htaccessの不審な変更
• wp-config.phpの不審な追記
• サーバーのアクセスログやエラーログ

ただし、公式発表では、現時点で実際の悪用が確認されているかどうかや、具体的な侵害の痕跡は明示されていません。更新が遅れたからといって、必ず侵入されたという意味ではありません。

対応の緊急性と対応方法について

「深刻」と「重要」の意味

日本語公式発表では、今回の2件について次のように説明されています。

• 深刻な脆弱性：1件
• 重要な脆弱性：1件

英語版ではone critical and one high severity security issueと表現されています。

ただし、GitHubの個別アドバイザリでは次の評価になっています。

この違いは、一見すると少し分かりにくい部分です。

考えられる整理としては、1件目のSQLインジェクション単体では成立条件が限定されるためModerateと評価される一方、WordPressのリリース全体としては、2件を組み合わせた攻撃や影響の大きさを考慮し、「CriticalとHigh」として強く注意を促している可能性があります。

ただし、公式発表とGitHubアドバイザリで評価表現が完全には一致していないため、現時点では無理にどちらか一方へ統一して説明しない方が適切です。

実務上は、RCEにつながるCritical相当の問題を含むため、緊急度の高い更新と考えればよいでしょう。

ログインしていない攻撃者でも悪用できるのか

現時点の公式発表だけでは、次の条件は明確ではありません。

• 未ログインでも攻撃できるか
• 購読者などのユーザーアカウントが必要か
• 特定のプラグインが必要か
• REST APIが通常どおり有効なら成立するか
• 特定のREST APIルートが必要か
• マルチサイトでも同様に成立するか

そのため、現段階で「誰でもログインなしで全サイトを乗っ取れる」と断定することはできません。

一方、WordPress.orgが強制自動更新を有効にしたことから、攻撃条件が完全に公開されていなくても、WordPress側は非常に高い優先度で対応すべき問題と判断していることが分かります。

REST APIを無効化すれば更新しなくてもよいのか

REST APIを制限しているサイトでも、更新は必要です。

理由は3つあります。

• 1件目のSQLインジェクションはREST APIだけに限定された問題ではありません。WordPress 6.8系も影響を受けていることから、REST APIのバッチルート混同がなくても、別のテーマやプラグインの処理から問題が利用される可能性があります。
• REST APIを完全に無効化すると、ブロックエディターやプラグイン、管理画面の一部が正常に動作しなくなる可能性があります。
• REST API制限プラグインを使用していても、すべてのルートや内部サブリクエストが完全に遮断されるとは限りません。

したがって、REST APIを止めることは、今回の正式な対策にはなりません。正式な対策はWordPressコアを修正版へ更新することです。

WAFやセキュリティプラグインがあれば大丈夫か

WAFやセキュリティプラグインの導入は、攻撃リクエストを遮断する補助策として有効な場合があります。ただし、これらが導入されていても、WordPressの更新を省略すべきではありません。

今回のような複数の処理を組み合わせる脆弱性では、既知の攻撃パターンだけを遮断するWAFでは、すべての変形パターンに対応できない可能性があります。

また、強制自動更新を有効にするほどの問題ですので、WAFはあくまで追加防御と考え、WordPress本体の更新を優先してください。

更新後にパスワード変更は必要か

通常は、更新しただけで全ユーザーのパスワードを変更する必要はありません。

ただし、次のような兆候がある場合は、パスワード変更や2段階認証導入のご検討をおすすめします。

• 不審な管理者アカウントがある
• ログイン履歴に不明なアクセスがある
• ファイルが改ざんされている
• 不審なプラグインが追加されている
• データベースが書き換えられた形跡がある
• セキュリティ製品が侵入を検知した

更新後も6.8.6や6.9.5を使い続けてよいか

今回の脆弱性への対応という意味では、それぞれの修正版で問題ありません。ただし、WordPress公式は、古い影響対象ブランチへの修正提供は便宜上のバックポートであり、積極的にサポートされるのは最新バージョンだけだと説明しています。

互換性の問題などで6.8系や6.9系を一時的に使用することはできますが、長期的には次の対応が望まれます。

• テーマやプラグインを最新版にする
• PHPの対応状況を確認する
• 検証環境でWordPress 7.0系を試す
• 問題がなければ最新系列へ移行する

今回のリリースをどう評価すべきか

今回の更新は、WordPressコアのセキュリティリリースとしても緊急度が高い部類です。

理由は次のとおりです。

• 公式がCriticalとHighの問題として発表している
• 2つの問題を組み合わせるとRCEにつながる
• WordPress.orgが強制自動更新を有効にしている
• 6.9系と7.0系が両方影響を受ける
• CVE番号とGitHub Security Advisoryが公開されている
• 7.1 Betaも修正版が再リリースされている

一方で、現時点では攻撃成立条件のすべてが公開されていません。そのため、「すべてのサイトが無条件に遠隔操作される」と過度に不安をあおるのも適切ではありません。

実務上の捉え方は、次のようになります。

まとめ

WordPress 7.0.2／6.9.5／6.8.6では、WP_Queryのauthor__not_inに関するSQLインジェクションと、REST APIのバッチルート混同が修正されました。

WordPress 6.9以降では、この2件を組み合わせることで、サーバー上のコード実行につながる可能性があります。WordPress 6.8系は1件目だけが対象で、6.8より前のバージョンは今回の問題の影響を受けません。

対象サイトでは、次の更新を速やかに行ってください。

• WordPress 7.0.0～7.0.1 → WordPress 7.0.2
• WordPress 6.9.0～6.9.4 → WordPress 6.9.5
• WordPress 6.8.0～6.8.5 → WordPress 6.8.6

WAFやセキュリティプラグイン、サーバー運営側の対応だけに頼らず、WordPressコア自体を修正版に更新することが、今回の正式かつ最も確実な対策です。

WordPressでブログを作るとき、ログインするときの入り口（ログイン画面）はみんな同じで、https://サイトのアドレス/wp-login.phpというアドレスになっています。

でもこのままだと、世界中の誰でもログインページにアクセスできてしまいます。つまり、悪意のある人が「総当たりでパスワードを試す攻撃（ブルートフォース攻撃）」を仕掛けやすい状態となっています。

そこで役立つのが WPS Hide Login（ダブルピーエス・ハイド・ログイン） というプラグイン。このプラグインを使うと、ログインページのアドレスを自分だけが知っている秘密のURLに変えられます。

どうやって使うの？

1. WordPressの管理画面から「プラグイン」→「新規追加」で WPS Hide Login をインストールして有効化。
2. 左のメニューから「設定」→「一般」を開くと、「ログインURL」「リダイレクトURL」という項目が増えています。
3. そこに好きな文字を入れるだけでOK。

設定項目について

例えば、「ログインURL」欄で以下のように設定すると、次からは「mydoor」と入力しないとログイン画面が出てこなくなります。

• 変更前： https://example.com/wp-login.php
• 変更後（例）： https://example.com/mydoor

また、上記を設定した状態で「wp-login.php」にアクセスを試みた場合には「リダイレクトURL」で指定したURLに転送されてしまいます（そのため、「リダイレクトURL」は404などのよくある名前でOKです）。

注意してほしいこと

• 新しいログインページのアドレスを 必ずメモしてブックマーク してください。忘れると自分も入れなくなります。
• これはあくまで「セキュリティを強化する一つの手段」。強力なパスワードや、二段階認証も一緒に使うとさらに安心です。

その他詳しいことは、プラグインの公式情報をご覧くださいませ。

• WPS Hide Login – WordPress プラグイン | WordPress.org 日本語

まとめ

• 「WPS Hide Login」は、WordPressのログインページを自分だけのURLに変えられるプラグイン。
• 設定はとっても簡単で、1分あれば終わります。
• 不正アクセス対策として、初心者さんにもおすすめのセキュリティ強化方法です。

WordPressはバージョン6.8で、パスワードの暗号化（正確にはハッシュ化）方式に大きな変更が加えられました。これによりセキュリティは強化されましたが、誤って6.8にアップデートした後、旧バージョン（6.7以前）に戻した場合、ログインに支障が出る可能性があります。

本記事ではその詳細と対処法を簡単に説明します。

目次

パスワード処理内容の変更事項

WordPress 6.8では、これまで使われていたphpassというパスワードハッシュ方式から、業界標準のbcryptに移行しました。

phpassとは？

phpassは、PHPで使われるパスワードハッシュライブラリで、WordPressを含む多くのPHPアプリケーションで長年使われてきました。

特徴

• ポータブル性が高い：PHP環境であればどこでも動作可能。
• ソルトを使用：ハッシュ化の際にソルト（乱数）を加えることで、同じパスワードでも異なるハッシュを生成。
• 運用が軽量：比較的処理が軽く、低スペックなサーバーでも安定して動作。

デメリット

• セキュリティの限界：ハッシュ処理のコスト（時間的負荷）が固定で、現代の高性能CPUには脆弱。
• ブルートフォース（総当たり）攻撃に弱くなりつつある：計算が速いため、パスワードを総当たりで破る攻撃に対して十分な防御ができなくなってきている。

bcryptとは？

bcryptは、元々UNIX系のセキュリティ強化のために開発されたハッシュ関数で、現在ではパスワードハッシュの標準として広く採用されています。

特徴

• スローハッシュ：意図的にハッシュ処理に時間をかける設計（時間コストを調整可能）。
• 自動ソルト生成：ソルトを自動的に付加し、さらに安全性を向上。
• 適応的セキュリティ：コンピュータの性能向上にあわせて、ハッシュ処理をより重くすることができる（cost値で調整）。
• 多くの言語・ライブラリで標準対応：セキュリティ指針に準拠した設計。

デメリット

• 処理がやや重い：パフォーマンスが重要な大規模システムでは工夫が必要な場合もある。

phpassとbcryptの違い（まとめ）

なぜWordPressはbcryptに移行したのか？

近年は、ユーザー情報漏洩リスクが高まりつつあり、単なるソルト付きハッシュでは不十分とされています。phpassは、当時としては十分安全でしたが、現在のセキュリティ基準にはやや古くなっており、今後の安全性を見据えてbcryptへの移行が決定されました。

実際、他のCMS（たとえばLaravelやDjango）ではすでにbcryptやArgon2が標準になっており、WordPressもその流れに合わせて進化しています。

• WordPress Core Dev Blog: WordPress 6.8 will use bcrypt for password hashing
• WordPress Trac #21022: Use bcrypt for password hashing
• Kinsta Blog: What’s New in WordPress 6.8

ダウングレード時に発生する問題

6.8でハッシュ（暗号化）されたパスワードは、6.7以前のWordPressでは認識できません。これは旧バージョンがbcryptに非対応のためです。

※6.7以前から6.8にアップグレードした場合は、アップグレード後に初めてログインする時にパスワードがbcrypt化されますので、特別な操作は不要です。

具体的な症状

• WordPress 6.8でパスワードを変更またはログイン → パスワードがbcrypt化
• その後、6.7以前に戻す → bcryptに非対応のためログイン不可

解決策と回避法

• パスワードの再設定：ログインできないユーザーには、「パスワードをお忘れですか？」からリセットしてもらう方法が一番安全です。
• 管理者による対応：管理者がログインできる場合は、対象ユーザーのパスワードを管理画面から再設定することも可能です。
• データベースの手動編集：上級者であれば、wp_usersテーブル内のuser_passカラムを手動でMD5()などで再ハッシュする方法もありますが、これは推奨されません。

ダウングレードの前に

• ユーザーデータのバックアップは必須
• 可能であれば、ダウングレードせず対応策を模索

まとめ

WordPress 6.8は、セキュリティ強化の観点から非常に大きな前進でしたが、旧バージョンへのダウングレード時には注意が必要です。

• bcrypt化されたパスワードは6.7以前では認識できません
• ログインできない場合はパスワードの再設定が必要です
• 可能な限りダウングレードは避けるか、慎重な対応が求められます

この記事が、トラブル回避やセキュリティ理解の助けになれば幸いです。