WordPress、投稿者権限以上でRCEにつながる脆弱性を修正-CVE-2026-65640

セキュリティニュース

投稿日時: 更新日時:

WordPress、投稿者権限以上でRCEにつながる脆弱性を修正-CVE-2026-65640

WordPressプロジェクトは2026年8月12日、セキュリティアップデートとなるWordPress 7.0.4を公開しました。修正されたCVE-2026-65640は、悪意のあるファイルのアップロードを起点として、サーバー上で任意コードを実行される可能性がある脆弱性です。GitHub Security AdvisoryではCVSS 8.8、深刻度Highと評価されています。

ただし、インターネットから誰でも直ちに悪用できる未認証RCEではありません。悪用には投稿者(Author)以上、またはファイルをアップロードできる権限を持つアカウントと、ImagickおよびGhostscriptを使用するサーバー構成が必要です。WordPress 7.0.3以前を利用している管理者は、条件に該当するかにかかわらず7.0.4への更新を優先してください。

WordPress 7.0.4とCVE-2026-65640のサマリー

  • WordPressは2026年8月12日、セキュリティ修正版となるWordPress 7.0.4を公開しました
  • 対象の脆弱性はCVE-2026-65640、GitHub Security AdvisoryはGHSA-8vr3-7mxf-gx8wです
  • CVSS v3の基本値は8.8で、深刻度はHighと評価されています
  • 悪意のあるPostScriptファイルのアップロードを起点として、リモートコード実行に至る可能性があります
  • 悪用には投稿者権限以上、または upload_files 権限を持つアカウントが必要です
  • サーバーでImagickとGhostscriptが使われていることも成立条件です
  • WordPress 7.0系では7.0.0から7.0.3が影響を受け、7.0.4で修正されました
  • 修正はWordPress 4.7系までの旧ブランチにもバックポートされています
  • WordPressが公式に推奨する対応は、修正版への速やかなアップデートです
  • 2026年8月17日時点で、実際の攻撃での悪用や公開PoCは一次情報から確認できませんでした
  • 同日時点でCISAのKnown Exploited Vulnerabilities(KEV)Catalogには掲載されていません
  • WordPressおよびGitHubのアドバイザリでは、固有のIOCや公式な暫定回避策は公表されていません
項目 内容
公表日 2026年8月12日
対象製品 WordPress Core
CVE番号 CVE-2026-65640
GitHub Security Advisory GHSA-8vr3-7mxf-gx8w
脆弱性 悪意のあるファイルアップロードを起点とするリモートコード実行
CWE CWE-434:危険な種類のファイルの無制限アップロード
CVSS 8.8(High、CVSS v3)
必要な権限 投稿者以上、または upload_files 権限を持つユーザー
必要なサーバー構成 ImagickとGhostscriptを使用している環境
WordPress 7.0系の影響バージョン 7.0.0~7.0.3
WordPress 7.0系の修正版 7.0.4
悪用確認 2026年8月17日時点で確認できませんでした
PoC公開 2026年8月17日時点で一次情報から確認できませんでした
CISA KEV 2026年8月17日時点で未掲載
IOC 公式情報では公表されていません
暫定回避策 公式には公表されていません。修正版への更新が必要です

悪意のあるPostScriptファイルの処理からコード実行につながる

WordPressのGitHub Security Advisoryによると、CVE-2026-65640は、悪意のあるPostScriptファイルをアップロードした際の処理を通じて、リモートコード実行につながる脆弱性です。問題はGhostscriptが特定の埋め込みファイルを処理する際の挙動に関係し、WordPress側では危険なファイルの処理を防ぐ修正が行われました。

成立には次の2条件が必要です。

  • サーバーでImagickとGhostscriptが使われていること
  • 攻撃者が upload_files 権限を持っていること

WordPressの標準権限では、投稿者以上のユーザーがファイルをアップロードできます。ただし、権限をカスタマイズしているサイトでは、役割名ではなく upload_files 権限の付与状況を確認する必要があります。

攻撃が成功した場合、WebサーバーやPHPの実行ユーザーが持つ権限の範囲でコードを実行される可能性があります。その結果、Webサイトの改ざん、認証情報や設定情報へのアクセス、バックドアの設置、マルウェア配布や別サイトへの誘導などにつながるおそれがあります。

未認証RCEではないが、投稿者アカウントの侵害を軽視できない

CVE-2026-65640のCVSSベクトルは、ネットワーク経由、攻撃の複雑さは低い、低い権限が必要、利用者の追加操作は不要という条件です。したがって、管理者権限までは必要ありませんが、有効なアカウントとファイルアップロード権限が必要です。

この条件から、脆弱性単体を未認証の第三者が悪用できると説明するのは不正確です。一方、次のような環境ではリスクが高まります。

  • 外部ライターや委託先へ投稿者権限を付与している
  • 長期間使われていない投稿者アカウントが残っている
  • 複数人でアカウントを共有している
  • 多要素認証を導入していない
  • パスワードの使い回しやフィッシングにより投稿者アカウントが侵害されている
  • 権限管理プラグインで、本来不要な利用者へ upload_files 権限を追加している

攻撃者が投稿者アカウントを取得した場合、通常は記事投稿やメディアアップロードに限られる権限が、サーバー上のコード実行へ拡大する可能性があります。権限の低いアカウントだから影響も限定的とは判断できません。

影響バージョンと修正版

GitHub Security Advisoryでは、WordPress 7.0系だけでなく4.7系までの各ブランチが影響対象として示されています。修正は旧ブランチにもバックポートされました。

ブランチ 影響を受けるバージョン 修正版
7.0 7.0.0~7.0.3 7.0.4
6.9 6.9.0~6.9.6 6.9.7
6.8 6.8.0~6.8.7 6.8.8
6.7 6.7.0~6.7.6 6.7.7
6.6 6.6.0~6.6.6 6.6.7
6.5 6.5.0~6.5.9 6.5.10
6.4 6.4.0~6.4.9 6.4.10
6.3 6.3.0~6.3.9 6.3.10
6.2 6.2.0~6.2.10 6.2.11
6.1 6.1.0~6.1.11 6.1.12
6.0 6.0.0~6.0.13 6.0.14
5.9 5.9.0~5.9.15 5.9.16
5.8 5.8.0~5.8.14 5.8.15
5.7 5.7.0~5.7.16 5.7.17
5.6 5.6.0~5.6.18 5.6.19
5.5 5.5.0~5.5.19 5.5.20
5.4 5.4.0~5.4.20 5.4.21
5.3 5.3.0~5.3.22 5.3.23
5.2 5.2.0~5.2.25 5.2.26
5.1 5.1.0~5.1.23 5.1.24
5.0 5.0.0~5.0.26 5.0.27
4.9 4.9.0~4.9.30 4.9.31
4.8 4.8.0~4.8.29 4.8.30
4.7 4.7.0~4.7.34 4.7.35

WordPressは、積極的にサポートするのは最新のメジャーバージョンのみであり、旧ブランチへのセキュリティ修正は便宜上のバックポートだと説明しています。旧ブランチ向け修正版を適用すれば今回の脆弱性は修正できますが、長期的には最新のサポート対象バージョンへ移行する必要があります。

実悪用、PoC、CISA KEVの確認状況

2026年8月17日時点で、WordPressの公式発表、GitHub Security Advisory、報告者であるpwn.aiの公開情報から、CVE-2026-65640が実際の攻撃で悪用されたとの情報は確認できませんでした。脆弱性を再現するPoCの一般公開も、今回確認した一次情報には記載されていません。

CISAが公式GitHubで公開するKEVデータも確認しましたが、8月14日更新版のカタログにCVE-2026-65640は含まれていません。このため、現時点で「実際の攻撃で悪用されている」「CISA KEVへ掲載済み」と記載する根拠はありません。

ただし、KEV未掲載は安全性を意味するものではありません。WordPress Coreはソースコードが公開されており、修正差分の解析から攻撃方法が研究される可能性があります。実悪用の確認を待たず、修正版を適用することが必要です。

検出と防御で確認すべきポイント

WordPressとGitHubのアドバイザリは、本件固有のIPアドレス、ファイル名、ハッシュ値などのIOCを公表していません。このため、特定のIOCへの一致だけではなく、アカウント、アップロード、ファイル変更、プロセス実行を組み合わせて確認します。

  • WordPress本体が7.0.4、または利用ブランチの修正版へ更新済みか確認する
  • 自動更新を有効にしている場合も、実際のバージョンと更新失敗の有無を確認する
  • サーバーでPHPのImagick拡張とGhostscriptが使用されているか確認する
  • 投稿者以上のユーザーと upload_files 権限を持つユーザーを棚卸しする
  • 退職者、外部委託先、休眠アカウントを無効化し、多要素認証を適用する
  • 2026年8月12日以前を含むメディアアップロード履歴から、通常運用で扱わないファイルを確認する
  • WebサーバーやPHPの実行ユーザーによる不審なプロセス起動、外部通信、ファイル作成を確認する
  • WordPress Coreのチェックサム検証と、テーマ・プラグインのファイル差分確認を行う
  • uploadsディレクトリ内の実行可能ファイル、見覚えのない管理者、プラグイン、予約タスクを確認する

WordPressを更新しても、すでに侵害されている環境からバックドアが消えるわけではありません。不審なファイルやアカウントが見つかった場合は、サイトをネットワークから隔離し、ログとディスクの証拠を保全した上で、認証情報の変更とクリーンなバックアップからの復旧を検討します。

情報システム部門への示唆

情報システム部門は、自社で直接管理するWordPressだけでなく、広報部門、採用部門、事業部、海外拠点、制作会社が運用するサイトも対象に棚卸しする必要があります。脆弱性管理台帳にWordPress Coreのバージョン、ホスティング事業者、運用委託先、更新責任者を記録し、7.0.4または対応する修正版の適用結果を回収してください。

今回の脆弱性は、サーバー構成とユーザー権限が組み合わさることで成立します。バージョン情報だけで優先順位を決めず、Imagick・Ghostscriptの利用、外部投稿者の有無、アカウント保護の状況まで確認することが重要です。更新前の動作確認が必要な場合も、本番サイトを長期間未修正のままにせず、ステージング環境で短時間に検証できる手順を整備します。

また、WordPress Coreを更新してもプラグインやテーマの脆弱性は修正されません。過去には、セキュリティ対策LabでもWordPressプラグイン「Sneeit Framework」のRCE脆弱性を取り上げています。Core、プラグイン、テーマ、PHP、画像処理ライブラリを別々の資産として管理し、更新状況を継続的に確認する必要があります。

出典