WordPress は 2026 年 9 月 22 日に 7.1.2 を公開しました。公式発表はこれを一文で説明しています。深刻度が critical（重大）のセキュリティ脆弱性の修正を含むセキュリティリリース、というものです。対応する GitHub のセキュリティアドバイザリは GHSA-7hp8-65ch-5whp、脆弱性番号は CVE-2026-87902、CVSS v4 のスコアは 9.2 です。3 日後の 9 月 25 日、米国の CISA は「実際に悪用されている証拠に基づき」これを既知の悪用された脆弱性カタログに追加し、連邦機関の対応期限を 9 月 28 日としました。

どんな脆弱性で、どんな条件でコード実行に至るのか

公式の説明によれば、認証されていない攻撃者が特定の条件の下で、ページテンプレートの解決処理に、有効なテーマのディレクトリの外にある、攻撃者が選んだ読み取り可能なローカル PHP ファイルを読み込ませることができます。サーバー環境と有効なテーマの両方で前提条件が満たされると、リモートコード実行につながります。アドバイザリが挙げる前提条件は 2 種類です。

  • テーマの条件：有効な子テーマまたは親テーマに、名前が page- で始まる最上位ディレクトリ（例：page-templates）があること。アドバイザリは旧来の Twenty Twelve と Twenty Fourteen、および Neve、Hestia、Sydney などの人気サードパーティテーマを挙げています。
  • サーバーの条件：Web サーバーのアカウントで読み取れる、悪用可能なローカル PHP ファイルが存在すること。例として挙げられているのは pearcmd.php で、register_argc_argv が On のときにこれを足がかりにコードを実行できます。アドバイザリは、公式の php Docker イメージが影響を受けること、PHP 8.5 より前のバージョンを使う既定の cPanel 構成も影響を受けることを明記しています。

影響を受けるバージョンと修正版

影響を受けるのは 4.7.0 から 7.1.1 までの各ブランチです。修正は、セキュリティ修正の対象となっているすべてのブランチにバックポートされています。7.1.2、7.0.6、6.9.9 から 4.7.37 までです。どのメジャーバージョンを使っていても修正版はあります。大事なのは、それが実際に適用されているかを確かめることです。

前後にもセキュリティ更新が 2 回

今回は単発ではありません。9 月 17 日の 7.1.1 には 11 件のセキュリティ修正が含まれ、10 月 6 日の 7.1.3 でさらに 7 件のセキュリティ問題が修正されました。3 つの発表はいずれも、バックグラウンドの自動更新に対応したサイトでは更新が自動的に始まると書いています。ただし自分で管理するサーバーでは、ファイルの権限や設定によって自動更新が無効になっていることがあるので、更新済みだと思い込まないでください。

VPS での確認方法

  • バージョンを確認：管理画面の「ダッシュボード → 更新」、またはサーバー上で WP-CLI の wp core version を実行します。自分のブランチの修正版（7.1 ブランチなら 7.1.2）より古ければ、すぐに更新してください。7.1.3 がすでに出ているので、7.1 ブランチは 7.1.3 まで一気に上げると手間が省けます。
  • テーマのディレクトリを確認：wp-content/themes/ の下で、有効なテーマ（とその親テーマ）のルートに page- で始まるディレクトリがないか調べます。
  • PHP の設定を確認：サイトが実際に使っている PHP（コマンドラインではなく FPM または Apache モジュール）の register_argc_argv の値と、サーバー上に不要な pearcmd.php がないかを確認します。公式の php Docker イメージでサイトを動かしている場合は特に注意してください。
  • 悪用が疑われる場合：9 月 22 日以降に更新したサイトは、侵害後のチェックリストに沿って、見覚えのない PHP ファイル、スケジュールされたタスク、管理者アカウントがないか調べることをおすすめします。

WordPress の基本的な構築は VPS で WordPress サイトを構築するを、更新前のバックアップは VPS のバックアップ戦略を参照してください。あわせて ufw ファイアウォールと SSH 鍵ログインも見直しておきましょう。