現役フロントエンドエンジニアの実務ノート
運営者情報 ご依頼 お問い合わせ
CMS・WordPress

【php2shell】PHPを自分で上げられない環境で、緊急脆弱性にどう備えたか｜マネージドホスティングと静的配信のWordPress

農添 広晃 公開

PHPの緊急脆弱性php2shell（CVE-2026-109618 / CVE-2026-109619）は、PHPを自分で上げられる環境なら「修正版に上げる」で終わります。

ところが、マネージドホスティングや静的配信型のWordPressでは、PHPを管理しているのは事業者です。利用者は自分で上げられません。この記事では、そういう環境で私が何を確かめ、何を判断したかをまとめます。

この記事の内容は2026年10月時点のものです。担当している環境が特定できないよう、事業者名や構成の細部は伏せています。

php2shellの中身と、Xserver（Apache）での具体的な対応は PHPの緊急脆弱性に、Xserver上のWordPressで一晩対応した記録 にまとめています。

スポンサーリンク

この記事の要点

  • 修正版は8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。8.1以前には公式の修正版が出ない
  • まず「どこでPHPが動いているか」と「そのPHPの細かい番号」を洗い出す。ローカルの検証環境が、サポート切れのPHP 8.1のまま放置されていたのが見つかった
  • 静的配信型のWordPressは、公開サイトが閲覧時にPHPを実行しないので、影響は編集環境だけに絞れる
  • Nginxで動くホスティングでは、.htaccessでのメンテナンス表示は効かない。止める手段がないときは、事業者の対応と自分たちの備えを確かめて「待つ」と判断した
  • 修正の適用後、WP-CLIのverify-checksumsなどで改ざんがないことを点検した

環境ごとに、影響の範囲を整理する

最初にやったのは、担当している環境を「どこでPHPが動くか」で分けることです。

環境 配信のしかた 影響 PHPを管理しているのは
静的配信型のWordPress（公開サイト） 書き出したHTMLをCDNから配信 閲覧時にPHPを実行しないので、直接の影響なし ―
静的配信型のWordPress（編集環境） PHPで動く 影響あり 事業者
マネージドホスティングのWordPress PHPで動的に配信 影響あり 事業者
ローカルの検証環境（Docker） 自分のPCで動く 影響あり。外には公開していない 配布元のイメージ

どの環境も、PHPそのものは事業者か配布元のイメージが管理していて、自分で上げられる場所はほとんどありませんでした。そのため、やることは次の3つに絞られます。

  1. どこが影響を受けるかを、正確に把握する
  2. 事業者の修正の適用を確かめる
  3. 適用されるまでのリスクを、どう扱うかを決める

1. PHPの細かい番号を洗い出す

ホスティングの管理画面では「PHP 8.2」のような大まかな表示しか見られないことが多いです。修正済みかどうかは8.2.35のような細かい番号で決まるので、別の方法で確かめました。

  • WordPressのサイトヘルス：管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」の「PHPバージョン」。サイトを実際に動かしているPHPの番号が出るので、これを正としました
  • Dockerのローカル環境：docker compose exec wp php -v

確かめた結果、ローカルの検証環境がPHP 8.1.28（2024年5月のビルド） のままでした。サポートが切れたバージョンです。

Dockerfileは配布元のイメージの:latestを参照していましたが、2年以上取り込み直していなかったのが原因です。docker compose build --pullで作り直して、8.3系になりました（この時点では、配布元のイメージ自体がまだ修正前でした）。

FROM xxx:latestと書いていても、--pullを付けて作り直さない限り、手元のイメージは古いままです。

2. 静的配信型：影響は編集環境だけ

静的配信型のWordPressは、編集用のWordPressで記事を書き、書き出したHTMLをCDNから配信する仕組みです。公開サイトは閲覧時にPHPを実行しないので、php2shellの入口になりません。

影響を受けるのは、PHPで動く編集環境だけです。今回は事業者が緊急メンテナンスで修正を当てる、と告知していました。メンテナンスの間は、WordPressの起動や記事の編集、静的な書き出しが止まりますが、公開サイトへの影響はありません。

私がやったのは次の2つだけです。

  • メンテナンスの時間帯に、サイトの更新を予定しないよう関係者に共有する
  • メンテナンス後に、サイトヘルスで修正版（今回は8.3系の修正版）になったことを確かめる

公開サイトを静的に配信していると、影響の範囲を「編集環境だけ」に絞れるのは、今回いちばん効いたことでした。

3. マネージドホスティング：止めるか、待つか

PHPで動的に配信しているサイトは、修正が当たるまでは直接攻撃を受ける可能性があります。そこで、修正が当たるまでサイトを止める方法を検討しました。

方法 結果
.htaccessで503のメンテナンス表示にする 効かない。Nginxで動いていて、.htaccessを読まない
WordPressのメンテナンスモード系のプラグインを使う 対策にならない。プラグイン自体がPHPで動くので、リクエストはPHPに届いてしまう
Nginxの設定で503を返す 有効。ただ、利用者はNginxの設定を変えられず、事業者への依頼が必要
管理画面の「IP制限」で、決まった場所からのアクセスに絞る 有効。ただ、作業する側の出口のIPが固定されていなかったので、許可するIPを正しく決められず見送った

Xserverでは使えた.htaccessの緊急メンテナンスが、ここでは使えません。同じ「止める」でも、WebサーバーがApacheかNginxかで、打てる手がまったく変わります。

結局、私は 事業者の修正の適用を待つ と判断しました。判断の材料は次のとおりです。

  • 事業者が「利用者側の対応は不要。暫定の緩和策を展開中で、修正版は検証後に適用する」と公式に案内していた
  • 手前にCDNのWAFを通しているサイトだった。CloudflareのCTOは、Cloudflare配下のPHPサイトには既知の攻撃手法を防ぐ初期のWAFルールを、無料プランを含む全利用者向けに入れたと発言していた。ただし、手前のCDNのWAFがこの攻撃をどこまで止めるかは、自分では確かめられていない
  • 待つ間に、管理画面から手動のバックアップを取っておいた
  • 「待つ」という判断を、関係者とセキュリティの担当者に共有した

事業者は翌日に全サイトへ修正を適用し、私が見ているサイトもサイトヘルスで修正版（今回は8.2系の修正版）になったことを確かめました。

PHPの脆弱性への対策として意味があるのは、PHPに届く前の層（Webサーバー、WAF、IP制限）で止める方法だけです。PHPで動くプラグインでメンテナンス表示にしても、守りにはなりません。

4. 修正前の期間に、改ざんされていないかを点検する

修正が当たっただけでは、その前に入り込まれていた場合を見逃します。そこで、マネージドホスティングのサイトにSSHで入り、次の点検をしました。WP-CLIが最初から使えるホスティングが多いです。

公開日以降に変わったPHPファイルを、フォルダごとの件数で確かめます。

find . -type f -name '*.php' -newermt '2026-10-20' | cut -d/ -f1-5 | sort | uniq -c

WordPress本体とプラグインが、WordPress.orgの公式の配布物と一致するかを確かめます。

wp core verify-checksums
wp plugin verify-checksums --all

管理者ユーザーの一覧を確かめます。

wp user list --role=administrator

ファイルの更新日時は攻撃者が偽装できます。そのため、findの結果だけで判断せず、verify-checksumsで中身を公式の配布物と照らし合わせました。なお、verify-checksumsで確かめられるのはWordPress.orgで配布されているものだけで、有料のプラグインやテーマは対象外です。

結果は次のとおりで、改ざんの形跡はありませんでした。

  • 変わっていたのは、プラグイン2つの更新によるファイルだけ（数百のファイルが同じ時刻にまとめて変わる、更新のときの典型的な形）
  • WordPress本体とプラグインは、すべて公式の配布物と一致
  • 管理者ユーザーは想定どおりの人数だけ

あわせて、バックアッププラグインのUpdraftPlusに、外部の管理ダッシュボード（UpdraftCentral）がつながっていないかも確かめました。php2shellとは別の事件ですが、ちょうど同じ時期に、UpdraftCentralの接続キーが開発元から盗まれ、WordPressのサイトに裏口を仕込むのに使われたと報じられていたためです。

5. 見落としやすい、間接的な影響

担当している環境には、別のサイトから、WordPressのwp-contentに置いたCSS・JS・画像を読み込ませている構成がありました。

静的なファイルを読み込むだけならPHPは動かないので、読み込むこと自体は脆弱性の入口になりません。ただ、置いているサーバーが乗っ取られると、JSを書き換えられて、読み込んでいる別のサイトの訪問者のブラウザで悪意のあるコードが動く、という形で被害が広がる可能性があります。

対策として、次の2つを進めています。

  • 手元の元のファイルと、サーバー上のファイルのハッシュ値を照らし合わせる
  • 読み込みのタグにSRI（integrity属性）を付ける。別のドメインから読み込むので、配信する側でCORSのヘッダーの設定も必要

振り返り

良かったこと

  • 公開サイトを静的に配信していたので、影響の範囲が編集環境だけで済んだ
  • サイトヘルスで細かい番号を確かめたので、「修正済みかどうか」をはっきり判断できた
  • 修正後にverify-checksumsで、改ざんがないことを確かめられた

改善したいこと

  • ローカルの検証環境のイメージを、定期的に取り込み直す運用にする
  • Dockerのポートの公開を127.0.0.1:8443:443のように自分のPCだけに限る。初期設定では、同じネットワークのほかの機器からもつながってしまう
  • 緊急時にサイトを止める手段を、ホスティングごとに前もって決めておく（Nginxの環境では誰に何を依頼するか、IP制限に使える固定のIPがあるか）
  • PHP 8.2は2026年12月31日 でサポートが終わる。8.2で動いているサイトは、年内に8.3以上へ切り替える

参考