WordPress 7.1.3は今すぐ更新すべき？セキュリティ修正7件の緊急度と影響

WordPressは7.1.3へ更新してください。2026年10月6日（日本時間では7日の未明）に公開された7.1.3は7件のセキュリティ修正と4件のバグ修正を含むリリースです。WordPress公式はすぐに更新するよう推奨しています。

Patchstackの技術解説によると7件のうち攻撃の起点が未ログインの訪問者になるのは2件です。残りは寄稿者や投稿者のアカウント、管理者の操作、プラグインの使い方といった条件が付きます。Patchstackの評価はできるだけ早く更新すべきだが他の作業を投げ出すほどの緊急事態ではない、というものです。

WordPress 7.1.3の更新内容と確認した情報源

WordPress 7.1.3はセキュリティ修正7件とバグ修正4件をまとめたメンテナンス兼セキュリティリリースです。英語の公式告知は2026年10月6日付、日本語の公式告知は10月7日付で公開されています。

公式のお知らせは7件の修正内容を1行ずつ並べているだけです。CVE番号も深刻度のスコアも実際に悪用されているかどうかも書かれていません。この記事で参照した公式告知とPatchstackの技術解説には今回の7件について実際の悪用を観測したという記載はありません。

そのためこの記事の攻撃条件はPatchstackがコードの差分をもとに整理した内容を使っていますが、これらは公式の評価ではないです。バグ修正4件はSearch Engine Journalの記事を参考にしています。

まず7.1.3へ更新する

更新前にWordPressのファイルとデータベースをバックアップし、復元方法も確認しておきます。そのうえで、管理画面から本体を更新します。

1. 管理画面の「ダッシュボード」→「更新」を開きます。
2. WordPress本体の更新が表示されていれば内容を確認して「今すぐ更新」をクリックします。
3. 更新後に「ダッシュボード」→「更新」を開き現在のWordPressバージョンが7.1.3になっているか確認します。

管理画面から更新できない場合はWordPress.orgのダウンロードページから手動で入手することもできます。公式は自動バックグラウンド更新に対応しているサイトでは更新が自動的に始まると案内しています。

自動更新を無効にしたつもりでも本体が更新される理由はWordPressの自動更新と強制更新の仕組みで詳しく説明しています。

セキュリティ修正7件を攻撃の起点で分ける

7件を攻撃に必要な条件で分けた図です。深刻度の評価ではなくPatchstackの整理にもとづいています。

未ログインの訪問者から始まる2件

非公開や未公開の投稿に付いたコメントが読めてしまう問題はログインなしで成立します。個別の投稿のコメントフィードを作る処理でWordPressは投稿を表示してよいかを確認する前にその投稿のコメントを読み込んでいました。確認の結果で消されるのは投稿だけでコメントは残り、しかもフィードは404を返さない仕組みのためそのまま出力されていたといいます。7.1.3ではコメントを読み込む処理を確認のあとへ移しています。

流出するのはコメントで記事本文が漏れるとは説明されていません。非公開や下書きの記事にコメントが付いていないサイトなら理屈の上では流出する中身がありません。

コメント管理画面のStored XSSは保留中のコメントに仕込まれたリンクをコメントを承認できる編集者以上がクリックすると成立します。原因は管理画面のwp-admin/js/common.jsにあります。ヘルプタブのクリック処理がリンクのhrefをjQueryの$()にそのまま渡していました。$()はHTMLに見える文字列を渡されるとHTMLとして組み立てるため、細工したリンクがスクリプトの入口になります。7.1.3では.find()に置き換えセレクターとしてしか読まないようにしています。

Patchstackの確認では保留中のコメントを使うこの攻撃の影響は7.1.0から7.1.2です。それより前の系列にも同じコードを強化する修正が入っています。

コメントを受け付けているサイトでは訪問者が送ったコメントが保留として管理画面に並びます。更新が終わるまではそうしたコメントの中のリンクをクリックしないでおくと安心です。攻撃の成立にはそのクリックが必要とされています。

寄稿者や投稿者のアカウントが必要な3件

この3件は攻撃する側に寄稿者（Contributor）や投稿者（Author）以上のアカウントが必要です。自分しかログインしないサイトでは攻撃の入口が限られます。

WP_Http::make_absolute_url()のDoSは相対パスからsegment/../の組を取り除くループがa//../bのようなパスで終わらなくなる問題です。取り除く対象に一致しないためパスが変わらずループを抜けられません。寄稿者はブロックエディターのリンクプレビューに自分が管理するページを指定して引き起こせます。7.1.3では1回の処理で何も置換されなかった時点でループを抜けるようにしています。

Imgur埋め込みのXSSはoEmbed（URLを貼るだけで埋め込み表示にする仕組み）の扱いが原因です。WordPressは信頼できない提供元が返すHTMLをフィルターに通してサンドボックス化したiframeにします。ところが信頼済みの一覧に載っている提供元はこのフィルターを通りません。Imgurがその一覧に入っていたため、Imgurが返す内容に含まれる画像やアルバムをアップロードした人が書ける文字列がそのまま出力されていました。7.1.3はImgurを信頼済みの一覧から外しフィルターを通すようにしています。

更新前に保存されたoEmbedのキャッシュは7.1.3への更新だけでは削除されません。WordPressのデータベースに保存される _oembed_* の投稿メタデータや oembed_cache の投稿が対象です。悪意のある埋め込みが保存されていると、更新後もその内容が表示される可能性があります。

Imgurを埋め込んでいる場合は該当するoEmbedキャッシュの削除・再取得を確認してください。データベース内にもキャッシュがあるため、そちらも留意する必要があります。

過去にImgurのURLを貼ったことがなければこのキャッシュを気にする必要は小さいはずです。投稿一覧の検索にimgur.comと入れると、埋め込んだ記事の見当がつきます。

投稿を先頭に固定表示する操作は投稿者でも通ってしまう状態でした。REST APIはedit_others_postsとpublish_postsの両方を持たないユーザーの要求だけを拒否する条件になっていました。投稿者はpublish_postsを持つため、そのまま通過できました。7.1.3ではどちらか一方でも持たなければ拒否するように修正されています。本来は編集者以上の権限が必要な操作を投稿者が行えてしまう権限の問題です。

管理者の操作やプラグインの使い方が条件になる2件

WXRエクスポートのSQLインジェクションはエクスポート機能がアイキャッチ画像のID（_thumbnail_idのメタデータ）を整数かどうか確かめずにSQLへ連結していた問題です。いったんデータベースに保存された値があとから別の処理で悪用されるため、セカンドオーダー型と呼ばれます。攻撃が成立するにはデータベースにすでに不正な値が入っていて、そのうえで管理者がエクスポートを実行する必要があります。

該当するコードは6.5.0以降にあり、通るのは「投稿」や「固定ページ」のようにコンテンツの種類を1つだけ選んだときです。既定の「すべてのコンテンツ」では通りません。7.1.3はabsint()を3か所に加えました。更新が終わるまでは種類を1つだけ選ぶエクスポートを避けておくと無難です。

{status}_{type}フック名の衝突はプラグインとの組み合わせで起きる問題です。フックはプラグインが処理を差し込むためのWordPressの仕組みです。WordPressは投稿のステータスが変わると{新しいステータス}_{投稿タイプ}という名前のアクションを実行します。投稿を公開すればpublish_postです。ところがdelete_post（投稿の削除時）やcomment_post（コメント投稿時）も同じ形の名前で、7.1.2ではステータスと投稿タイプが登録済みかを確認せずにアクション名を組み立てていました。ステータスがdelete、投稿タイプがpostの投稿を保存すると本物の削除と同じdelete_postが実行されます。そこに処理を登録したプラグインが投稿が削除されたと誤って動いてしまうわけです。

この状態になるのは生のステータスや投稿タイプをwp_insert_post()に渡すプラグインがある場合です。7.1.3では、登録済みのステータスと投稿タイプのときだけアクションを実行します。Patchstackはプラグイン依存の補強（ハードニング）と位置づけています。

更新はどのくらい急ぐべきか

直前の7.1.2で修正されたCVE-2026-87902との違いを表にしました。

7.1.3の更新を後回しにしてよいという意味ではありません。公式は即時の更新を推奨していますし、未ログインで始まる2件は攻撃する側にアカウントが要らないからです。一方で寄稿者や投稿者のアカウントを他人に渡していないサイトでは、残りの攻撃の起点が限られます。

7件の修正はWordPress本体を7.1.3へ更新するとまとめて適用されます。修正ごとに更新の順番を選ぶ必要はありません。

サイトごとに違うのは攻撃が成立する条件です。コメントを受け付けているサイトでは未ログインの訪問者が送ったコメントを通じた攻撃に注意が必要です。他の人に寄稿者や投稿者のアカウントを渡しているサイトではその権限を使う攻撃も考慮します。

バグ修正4件の中身

Search Engine Journalによるとバグ修正4件のうち2件は特定の2つのサービスのoEmbedエンドポイントが404を返す問題です。1件は管理バーのサイトアイコンが極端に大きく表示されることがある問題で残る1件が少し重要です。

重要な1件はPHPのDOM拡張（ext-dom）がないサーバーで画像のアップロードが致命的エラーで失敗する問題です。WordPress 7.0で追加されたコードが拡張の有無を確認せずにDOMDocumentを使っていました。チケットでの重大度は高く設定されています。

画像のアップロードでエラーが出ていたサーバーでは更新後に一度アップロードを試しておくと安心です。なお4件の内容は公式のチケット一覧を直接確認できなかったためSearch Engine Journalの記事にもとづいています。

7.1.2以前のままだとどうなるか

7.1.2以前を使っている場合の影響を、確認できた範囲で整理します。

影響するバージョンと攻撃条件は修正ごとに異なります。7.1.2には今回の7件の修正が含まれていないため、7.1系列を使っている場合は7.1.3へ更新してください。

旧系列にも修正版が公開されています。2026年10月8日に確認した公式バージョン一覧では、7.0系列は7.0.7、6.9系列は6.9.10、6.8系列は6.8.11、6.7系列は6.7.10、6.6系列は6.6.10が掲載されています。旧系列を使っている場合は利用中の系列に対応する修正版を確認してください。

直前の7.1.2に対応する修正版だけでは今回の修正まで適用したことにはなりません。WordPressが積極的にサポートしているのは最新バージョンなので、旧系列への修正提供を確認しつつ最新版への移行も検討してください。

更新後に確認したいこと

更新が終わったら次の3点を見ておくと安心です。

• 画像のアップロードが問題なくできるか。
• Imgurを埋め込んだ記事がある場合は該当するoEmbedキャッシュを確認・再取得し、ページキャッシュやCDNのキャッシュも消去してから表示を確認する。
• 寄稿者以上の権限グループのアカウントに見覚えのないものがないか。Patchstackも今回の修正の多くはそうした権限で届く範囲に関わるとしてアカウントの棚卸しを勧めています。

見覚えのないアカウントや不審な挙動がある場合は、ユーザー一覧に加えてプラグイン・テーマ・ファイル・アクセスログも確認してください。確認する順番と怪しい形跡を見つけた場合の対応は次の記事にまとめています。

あわせて読みたい

WordPressが乗っ取られていないか確認する方法｜改ざん・不正ユーザー・ログのチェック手順 WordPressの乗っ取りが疑われるときに、管理者ユーザー、プラグイン・テーマ、改ざんファイル、アクセスログを確認する手順と、異常発見後の初動対応を解説します。

迷いやすいポイント

WordPressの更新やセキュリティに関する関連記事は次のまとめページから探せます。

あわせて読みたい

WordPressまとめ WordPressの新機能、更新とセキュリティ、自作プラグイン開発の記事を目的別に探せるまとめページです。