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

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.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へ更新しておくことをおすすめします。