WordPress 7.1.2配信、criticalの脆弱性1件を修正

ニュース

ニュースの概要

WordPress.orgのニュースは、2026年9月17日に「WordPress 7.1.1 メンテナンス＆セキュリティリリース」、その5日後の9月22日に「WordPress 7.1.2」を公開しました。7.1.1は11件のセキュリティ修正を含み、7.1.2は重大度が最高の「critical」とされる脆弱性1件を修正するリリースです。7.1.2で直された問題は、認証なしの攻撃者が、特定の条件下で、有効なテーマのディレクトリ外にある読み取り可能なローカルPHPファイルを、ページテンプレートの解決に含められるというものです。サーバー環境と有効なテーマの前提条件がそろった場合には、リモートコード実行（RCE）につながる可能性があると説明されています。公式の記事は、この脆弱性の報告者としてRobert Ressl氏の名を挙げています。

何が変わるのか

まず7.1.1の内容です。公式の記載では、次のようなセキュリティ上の問題が修正されました（条件の細部は原文をご確認ください）。

  • wpautop()における保存型XSS（コメントの承認が前提となる、認証なしの訪問者によるスクリプト挿入）
  • HTML APIのset_modifiable_text()でのコメント脱出の問題
  • カスタムヘッダーに対応した一部のテーマに関連する保存型XSS
  • 特別に細工されたURLによる、WordPress.orgの未有効化テーマの自動インストールとプレビュー
  • サイト管理者が、インストール済みのネットワーク専用プラグインをネットワーク全体で有効化できる問題
  • WP RESTのテンプレートコントローラーにおける、認証済みユーザーのパストラバーサル
  • XML-RPCによるcustomize_changeset投稿の公開（edit_cssの権限チェックの回避）
  • Contributor以上の権限による任意投稿の上書き
  • attachment_submitbox_metadata()でのread_postチェック漏れ
  • 下書き・保留中の投稿のスラッグが、Contributor以上に開示される問題
  • ログイン中のユーザーであれば、誰でもコメントの親を付け替えられる問題

メンテナンス面では、コアの17件とブロックエディターの19件のバグ修正が含まれます。7.1.2の脆弱性は、CVE-2026-87902、GitHubのセキュリティアドバイザリではGHSA-7hp8-65ch-5whpとして案内されています。セキュリティ修正は、4.7までさかのぼる対象ブランチにバックポートされます。ただし7.1.2の記事には、これは厚意による対応であり、積極的にサポートされるのは最新版のみだと書かれています。次のメジャーリリースは7.2（12月予定）と案内されています。

読者への影響

テーマやプラグインを自作する開発者を含め、WordPressを動かしている全てのサイトの管理者が対象です。7.1.2の問題はコア側のテンプレート解決処理にあり、テーマのコードを書き換えても防げません。公式の説明では、RCEにつながるかどうかはサーバー環境と有効なテーマの前提条件に左右されます。ただし、自分のサイトが条件に当てはまるかを正確に判定するのは難しいため、コアを更新して解消するのが唯一の確実な方法です。

7.1.1の修正は、多くが特定の権限やコメント承認を前提とします。Contributor以上のユーザーや寄稿者がいるサイト、コメントを受け付けているサイトは、優先して更新したほうがよいでしょう。独自のブロック、カスタムテンプレートの出力処理、REST連携をしているサイトは、更新後に動作を確認しておくと安心です。

確認しておきたいこと

  • 管理画面のダッシュボードの「更新」から、WordPressのバージョンが7.1.2になっているか確認する（自動バックグラウンド更新に対応しているサイトは更新処理が自動で始まりますが、完了したかの確認は必要です）
  • 自動更新が止まっているサイトや、手動管理のサイトは、バックアップを取ったうえで「今すぐ更新」を実行する
  • 更新後に、テンプレートの表示、REST API、ブロックエディターの動作を確認する
  • 4.7系など古い系列で止めているサイトは、最新系列への移行計画を立てる

公式のアナウンスには、WordPress.orgからダウンロードして更新する方法と、ダッシュボードの「Updates」から「Update Now」を押す方法が案内されています。複数のサイトを運用している場合は、管理サイトの一覧を作り、各サイトのバージョンを順に確認していくのが確実です。なお、CVEやGHSAの個別ページに載る詳細な評価（CVSSの点数など）は、私は開いて確認していません。

筆者の見解

私見では、今回の2本を「同じ週に二度更新が要った」と見るより、「重大度で更新までの猶予を変える」運用基準を作るきっかけと捉えるべきだと考えます。基準の一つ目は、criticalで、しかも認証なしで悪用できるもの（今回の7.1.2）なら、ステージングでの検証を待たずに本番を即日更新し、動作確認は後に回すことです。二つ目に、7.1.1のようにContributor以上やログインが前提の脆弱性が中心のときは、ユーザー登録や寄稿者がいるサイトから優先して更新し、閲覧専用のサイトは通常の確認手順を踏んでもよいと考えます。また、バックポートはあくまで厚意で、正式にサポートされるのは最新版だけなので、古い系列で止めているサイトは、修正が届いていても安心材料にはならず、最新系列への移行計画を立てるべきだと考えます。最後に、今回の問題はコアの処理にありテーマ側では防げないため、テーマを見直す前に、全サイトのコアの版を確実に把握できる体制を整えることが、最も効く対策だと私は考えます。

出典

2026年10月6日時点の情報です。

コメント

タイトルとURLをコピーしました