ブログ作りの次の一手をあなたに。

お問い合わせ  |  お仕事の相談

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

WordPressメモ
タグ：
コメント (0)
  1. HOME
  2. WordPressメモ
  3. 【メモ】WordPress 7.0.2／6.9.5／6.8.6で修正された脆弱性について
この記事にはアフィリエイト広告が含まれている場合がございます。

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は問題の重大性から、影響を受けるサイトに対して自動更新システムによる強制更新も有効にしています。

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

目次

公式情報

強制自動更新について

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

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

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

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

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

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

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

今回の重要ポイント

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

脆弱性対象バージョン影響
WP_Queryのauthor__not_inに関するSQLインジェクション・6.8.0～6.8.5
・6.9.0～6.9.4
・7.0.0～7.0.1		不正なSQL処理を成立させる可能性
REST APIのバッチルート混同・6.9.0～6.9.4
・7.0.0～7.0.1		上記SQLインジェクションと組み合わさり、リモートコード実行につながる可能性

修正版は、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 ),
	)
);Code language: PHP (php)

ところが、修正前の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 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の個別アドバイザリでは次の評価になっています。

脆弱性GitHub上の評価
author__not_inのSQLインジェクションModerate
REST API経由でRCEにつながる問題Critical

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

考えられる整理としては、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コア自体を修正版に更新することが、今回の正式かつ最も確実な対策です。

お気に召しましたら是非ともシェアをお願いします！

この記事を書いた人

スクリーンネーム： Y.INABA

WordPress歴は約10年ほど、色々な形で触れてきました。
HTMLやCSS、PHPに至っては20年以上も触れ続けています。
現在も日々学習中。

プロフィール
お仕事のご相談はこちら
– 広告 –

当記事へのコメント

コメントの際の注意

  • コメントは承認制です。当方で承認されるまでは記事内に掲載されません。
  • 記載内容に問題がなければ承認しますが、過剰な煽り・加害性等が認められる場合や著しい事実誤認等が含まれている場合は承認しません。
  • 「記事中で話題として触れていないのに、他サイトでの関連性の薄い（主題とは異なる）話題を出す」行為もお控えください。
  • 承認後でも、問題があると判断した場合はこちらの判断により削除する可能性がございます。

コメントはこちらからどうぞ

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です


– 広告 –
Back to top