【WordPress】7.1.3で7件のセキュリティ修正！コメントと非公開情報も確認

WordPress.orgは2026年10月6日、WordPress 7.1.3を公開しました。公式発表では7件のセキュリティ修正と4件の不具合修正を含み、サイトの速やかな更新を勧めています。普段のプラグイン整理とは別に、WordPress本体の更新結果を確認したいニュースです。

本稿は10月18日に公式発表を読み直して整理したものです。18日の新しい被害報告ではなく、6日に公表された修正情報を扱います。確認した告知にないCVE番号、CVSS、すべての旧系列の対応版は推測しません。実際の悪用や攻撃開始日も、この発表だけからは確定できません。

出典：WordPress.org：7.1.3 Maintenance and Security Release。

修正された経路を業務の操作に置き換える

公式発表には、保留中のコメントを経由してコメント管理画面へ影響する保存型XSS、非公開・未公開投稿のコメント情報の認証不要での開示、WXRエクスポートの二次的なSQLインジェクションなどが挙がっています。閲覧ページだけでなく、管理や出力の経路も対象です。

ほかに、WP_Http::make_absolute_url()のDoS、Authorロールによる投稿固定、Imgur埋め込みのXSS、状態と投稿タイプに関するフックへ渡す偽造可能なパラメーターによるアクション名衝突が記載されています。いずれも条件や影響は異なり、全件が認証なしのコード実行という意味ではありません。

本サイトでは、各問題をコメント、非公開情報、書き出し、外部通信、投稿権限、埋め込み、独自連携へ対応付けて読むことを提案します。用語だけを一覧にするより、実際に担当する業務と結び付けることで、更新後にどこを確かめるか決めやすくなります。

コメントを承認していなくても管理画面が経路になる

保存型XSSは一般に、保存された値が後から画面へ表示されるとき、意図しないスクリプトとして扱われる問題です。今回の発表はコメント管理画面と保留中コメントの経路を明記しています。公開承認をしていないから、その入力は管理者へ届かないとは考えないでください。

本サイトの運用案として、更新までは不審なコメントを日常の管理作業で無理に開かず、対応担当と扱いを決めます。ただし、これを公式に保証された回避策として紹介するものではありません。必要な本体の修正を優先し、コメントの承認設定だけで修正済みとみなさないことが重要です。

更新後の互換性確認では、通常のテキストを使ったテスト用コメントで、保留、一覧、編集、承認、削除の経路を確かめます。攻撃用の文字列を本番へ投稿する必要はありません。通知メールや管理画面補助のプラグインがあるなら、正常な処理も合わせて確認します。

非公開の投稿とその周辺情報を分けて点検する

非公開本文が表示されないことと、その投稿に付随する情報が外部から得られないことは同じではありません。今回の修正はコメント情報の開示に触れています。本文の公開設定だけを確認して、周辺情報もすべて保護されていると判断しないことが必要です。

説明用の仮想例として、社内向けの投稿に運用上の相談をコメントで残しているサイトを考えます。守る対象には本文だけでなく、コメントの内容や関連情報も含まれます。これは特定のサイトで漏えいを確認した例ではなく、更新後の受け入れ条件を考えるための例です。

検証用環境では、未ログイン利用者、通常会員、編集者など、必要な立場で許される範囲を確認します。対象のデータへアクセスできるべき人と、拒否されるべき人を対で扱い、管理者として見えたことだけで公開側の状態を判断しない方法を提案します。

エクスポートは閲覧と異なるデータ処理の入口

WXRはWordPressのエクスポートで使われる形式です。公式の修正一覧にこの経路が含まれることは、普段のページ表示で問題がなくても、保守や移行の操作を確認する理由になります。更新の動作試験をトップページだけで終えないでください。

運用上は、書き出しを実施する担当者と、取得したファイルの保管先を把握します。テストは許可された環境とデータで行い、本番の全投稿や利用者情報をむやみに手元へ持ち出す方法を避けます。書き出せることと、出力物を必要な人だけが読めることを別に確認します。

「二次的」という名称だけから、今回の問題の詳しい攻撃手順を推定することはしません。一次資料が示す範囲の修正を適用し、実際に使うエクスポートや移行の処理が継続できるかを検証します。独自ツールで出力を取り込む場合は、その取り込み側の安全性も別の課題です。

本体の更新とプラグインの更新は別の証拠で確認する

管理画面にプラグインの更新完了が表示されても、WordPress本体の修正を適用した証明にはなりません。本体、テーマ、プラグイン、PHPなどの構成を分けて記録します。7.1系列を利用しているなら、7.1.3またはそれ以降の適切な公式修正版を確認します。

別の系列を維持している場合は、対応する公式の修正情報を確認します。本記事に記載していない系列の番号を推測して一律に案内しません。レンタルサーバーが管理する範囲も契約によって異なるため、サーバー全体の保守とWordPress本体の更新を同一視しないでください。

公式発表は、バックグラウンド自動更新を支えるサイトでは更新処理が自動で始まると説明しています。それでも、本サイトが勧める完了条件は、設定が有効なことではなく、実際に期待する版で動いていることです。失敗通知の受信先と、失敗時に作業する担当を確認します。

独自フックや投稿権限の試験を追加する

状態・投稿タイプに関わるフックを独自連携に使っている環境では、記事の保存、公開、予約、公開取消などの代表操作を検証します。外部通知や二重実行の防止が関わるなら、テスト用の宛先で確認し、実際の顧客へ通知が出ないようにしてください。

投稿の固定機能については、利用者のロールに応じて許可する操作を明確にします。管理者の操作が成功する試験だけでなく、投稿者が許可されない変更をできないことも確認します。画面にボタンがないことと、サーバー側で制限されることは同じ証拠ではありません。

これらは本サイトの検証案であり、すべてのサイトに同じ不具合が生じるという説明ではありません。独自コードを持つ場合は、その責任者と変更内容を照合します。問題が出たときに、修正を外して旧版へ戻す前に、限定された機能停止や連携停止で業務を維持できるかを検討します。

コメントを使わないサイトでも機能単位で判断する

説明用に、記事のコメント欄を非表示にしている企業サイトを考えます。画面に入力欄がないことと、すべての投稿経路や管理処理が停止していることは同じではありません。本サイトでは、テーマの表示、WordPressの設定、外部連携の有無を分けて確認することを勧めます。

また、コメントに関係する問題が自サイトで成立しないとしても、7.1.3の修正一覧にはエクスポートや埋め込みなど別の経路が含まれます。一つの未使用機能を根拠にリリース全体を不要としないでください。対象の本体修正を反映し、利用機能に合う検証を選ぶ方が、推測による対象外判定を減らせます。

保守を依頼する場合は、修正を含む本体の稼働版と、確認した機能を尋ねます。「コメントを止めた」という回答と「本体を更新した」という回答を同じ意味で受け取らないようにします。更新で独自連携へ影響が出たなら、対象機能を限定して調査し、サイト全体を脆弱な状態へ戻す前に代替の運用を検討します。

複数サイトを持つ場合は、同じサーバーにあることだけで一括して対応済みとしません。管理画面の接続先、実体のディレクトリ、WordPress本体の稼働版をサイトごとに照合します。旧サイトや検証サイトに認証情報や下書きが残っているなら、公開サイトと同様に担当を割り当てます。

対応票に残す確認項目

以下は本サイトが提案する対応票の例です。すべてを同じ担当へ任せる必要はありませんが、対象環境と結果を対応付け、未完了の行には責任者と次の実施予定を残します。確認できなかった項目を、正常という結果で埋めないことが大切です。

確認箇所	残す内容	完了の判断
本体の版	各サイトの導入系列と稼働版	プラグイン更新の結果と区別
コメント	保留・管理・通知の経路	通常の試験データで業務の継続を確認
非公開情報	本文と付随するコメントの公開条件	許可・拒否される利用者を対で検証
書き出し	担当・対象データ・保存先	正常な出力と出力物の権限を確認
独自連携	フックと外部通知の利用箇所	本番の顧客へ試験通知を送らず確認

更新の完了と過去の情報露出を分けて判断する

更新後に必要な機能が動作しても、過去に情報が取得されたかは別の調査です。今回の告知だけで自サイトの被害を断定することも、更新成功を根拠に被害なしと断定することもできません。異常なアクセスや利用者からの報告があれば、対応担当へつなぎます。

調査時は、対象機能を使っていた期間、ログの保存範囲、データの公開設定、保守作業の履歴を記録します。コメントや下書きに含まれる機密情報を確認する際も、必要な担当者に限定し、調査のためのコピーが新たな露出を起こさないようにします。

今回の7.1.3は、画面に見える公開記事だけを守れば十分ではないことを示す更新です。コメント、出力、埋め込み、独自連携のような周辺経路まで含めて、本体の修正が反映された状態と業務の動作を確認してください。