WordPress を更新しても直らない「PHP2Shell」― 検証環境のログで見る確認・暫定策・更新後の点検

2026 年 10 月 21 日の夜、国内の Web サイトが次々と自らサービスを止めました。PHP 本体に見つかった 2 件の重大な脆弱性、通称「PHP2Shell」への予防措置です。この記事は、隔離した検証環境で 2026 年 10 月 22 日に動かした結果をもとに、自分のサイトが対象かの確かめ方、更新までの間の暫定策とその限界、更新したあとにログで見るべき痕跡をまとめます。攻撃の手順や悪用の方法は書きません。

公式の注意喚起は「何を確認すべきか」を挙げています。この記事は、それが実際の画面とログでどう見えるかを、自分の検証環境で確かめた結果で示します。事件の全体像と各社の対応は piyolog のまとめが詳しいので、あわせて読んでください。

要点は次の 5 つです。

• PHP 本体の脆弱性が 2 件。どちらも認証なしで、PHP を動かすプロセスの権限でコードを実行されうる。深刻度は開発元の評価で CVSS v4.0 の 9.2
• WordPress などアプリの更新では直らない。土台の PHP 本体を更新する
• 修正版は PHP 8.5.12・8.4.27・8.3.36・8.2.35。8.1 以前は PHP から更新が出ない
• 更新できないときは session.upload_progress.enabled=0 などの暫定策がある。ただし完全ではなく、更新だけが根本対策
• 修正版が出る前日に詳細が漏れていた。更新したら、その前に攻撃されていないかをログで確かめる

検証の様子は YouTube にもまとめています。

##今すぐやること

この節は、サイトやサーバーを運用している人向けです。急ぐ場合は、次の 4 つだけ押さえれば動けます。各項目は後ろの節にリンクしています。

1. 自分のサイトの PHP の版を確かめる
2. 修正版より古ければ更新する（8.1 以前は 8.2 以降への移行を計画する）
3. すぐ更新できないなら暫定策の設定を入れる
4. 更新したら、ログで 3 つの痕跡を確かめる

一般の利用者がすることは、ほぼありません。使っているサービスのメンテナンスは、この対応のためです。

##自分のサイトが対象か確かめる

この節は、サイトやサーバーを運用している人向けです。まず、動いている PHP の版を調べます。

対象の版

次の版より前が対象です。修正版に上げれば直ります。

8.1 以前は、PHP 本体からは更新が出ません。開発者が 7.4・8.0・8.1 向けに最小限の暫定策をソースで用意しただけです。根本的には、サポート中の版（8.2 以降）へ移ります。

共用のレンタルサーバーの場合

多くの事業者が、利用者に代わって修正を適用しています。まず事業者のお知らせを確かめてください。自分のサイトの版は、次の場所で見られます。

• WordPress：管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」。WordPress.org も、この問題のために WordPress 自体を更新する必要はないと明記しています
• レンタルサーバーの管理画面（コントロールパネル）

VPS・クラウドで自分で管理している場合

コマンドで版を確かめます。コマンドラインの PHP の版を見るには、次を実行します。

php -v

ここで注意が 1 つあります。コマンドラインの PHP と、Web で動く PHP は別のことがあります。Web 側が mod_php（Apache 組み込み）か PHP-FPM かで、確かめる場所が変わります。見分けるには、Web から動く PHP で次を実行します。

php -r "echo PHP_SAPI, PHP_EOL;"

apache2handler と出れば mod_php、fpm-fcgi と出れば PHP-FPM です。最もリスクが高いのは mod_php で、既定の設定のまま、アプリのコードが動く前に攻撃が成り立つことが実証されています（GHSA-w8hw-w9fx-j79w）。

OS が配布するパッケージ（Ubuntu や RHEL など）を使っている場合、版の番号が上の数字と違っても修正済みのことがあります。修正を元の版に取り込む（バックポート）ためです。この場合は、OS のセキュリティ情報で CVE 番号を探します。

製品の中に PHP が入っている場合

機器やパッケージ製品の中で PHP が動いていることもあります。この場合は、製品の開発元のお知らせを確かめます。

##検証：アプリの1行目より前で何が起きるか

この節は、仕組みを目で確かめたい人向けです。検証環境は、外部につながっていない仮想マシンです。修正前の PHP 8.4.26 を動かしています。画面の左がサーバー側のログ、右が検証用の端末です。攻撃の手順や送ったデータは載せません。見せるのは、サーバー側のログと結果だけです。

受け付けの段階でセッションの状態が作られる

セッション機能を呼んでいない、ただのページにリクエストを送ります。すると、アプリのコードが 1 行も動く前の、PHP が受け付けた段階で、セッションの状態が勝手に作られていました。

メモリ不足でワーカーが落ちる

次に、リクエストの解析中にメモリの上限を使い切らせます。すると、致命的エラーの直後に、処理を担当していたワーカーが落ちました。

検証から分かること

この検証から、よく言われる 2 つの勘違いがはっきりします。

• 「WordPress を更新すれば大丈夫」→ 問題はアプリの 1 行目より前、PHP 本体の受け付けの段階で起きています。アプリを更新しても、土台の PHP が古ければ穴は残ります
• 「古い PHP は対象外」→ 8.1 以前は修正が出ないので、むしろ更新できず危ない状態です

##更新できないときの暫定策

この節は、すぐに更新できない人向けです。暫定策は、どちらのアドバイザリも「完全ではない。更新だけが完全な対策」と明記しています。暫定策は、更新までの時間を稼ぐ応急処置と割り切ってください。

session.upload_progress を無効にする

検証では、この設定でセッションを使う経路はふさがりました（図4 の 4 番目）。php.ini か PHP-FPM のプール設定で、次のように設定します。

session.upload_progress.enabled = 0

この設定は session.upload_progress.enabled を変えるもので、php.ini・httpd.conf・.htaccess・.user.ini で変更できます。ただしアドバイザリは、ini_set() や .user.ini には頼らず、サーバー側の設定で入れるよう求めています。設定を変えたら、PHP-FPM を再起動します。現在の値は次で確かめられます（Web 側と CLI で値が違うことがあるので、Web から動く PHP で確かめます）。

php -i | grep session.upload_progress.enabled

公式が挙げる、ほかの暫定策

公式アドバイザリは、CVE ごとに複数の暫定策を挙げています。主なものを抜き出します。どれも一部の経路しかふさぎません。

10/23 の追加案内：更新したあとも設定を残す

PHP は 10 月 23 日に、session.upload_progress に関する別の脆弱性 CVE-2026-115560 を予告しました。次の定例のバグ修正リリースまで、session.upload_progress.enabled=0 を続けるよう勧めています（php.net の案内）。10 月 21 日にこの設定を入れた人は、そのままでよいとしています。つまり、更新したあとも当面はこの設定を残します。この CVE はまだ番号だけで、詳しいアドバイザリは次のリリースで出る予定です。起きるのは、セッションのシリアライズ方式を実行中に php へ切り替え、かつアップロード進捗の機能が有効なまま、という珍しい組み合わせのときだけとされています。

##更新したあとに攻撃の痕跡を探す

この節は、サイトやサーバーを運用している人向けです。修正版が出る前日の 10 月 20 日には、すでに詳細が漏れていました。更新しただけでは、その間に攻撃されたかは分かりません。

JPCERT/CC が挙げる3つの痕跡

JPCERT/CC の注意喚起は、過去のログから次の 3 点を確かめるよう挙げています。

図3 で見たワーカーの異常終了は、3 つ目の痕跡そのものです。JPCERT/CC が言葉で挙げている痕跡は、実際のログでは child 23 exited with code 70 のような 1 行で出ます。自分のログでも、同じ形の行を探せます。

ログの探し方

• VPS など、サーバーログを見られる場合：PHP-FPM のエラーログで、ワーカーが exited した行を探します。終了コードの番号は環境で違うかもしれないので、番号ではなく exited で絞ります。ログの場所は環境によって違います

  grep "exited" PHP-FPMのエラーログのパス

  見つかった行の時刻の前後で、Web サーバー（nginx・Apache）のアクセスログと突き合わせ、不審な multipart/form-data の POST や HTTP 500 がないかを見ます

• 共用のレンタルサーバーの場合：アクセスログで、POST リクエストと HTTP 500 エラーが連続している箇所に注目します

痕跡がなくても安心はできない

JPCERT/CC は、悪用の経路が複数あり、単一のルールですべてを検出できるとは限らず、痕跡が残らない場合もあると書いています。痕跡が見つからなくても、攻撃を受けていないとは断定できません。

侵害が疑われるとき

不審なファイルの生成など、侵害の疑いがあるときは、慌ててファイルを消したり上書きしたりしないでください。ログや環境を保全したうえで、ネットワークから切り離して調べます。焦って初期化すると、どこから侵入されたかの証拠まで消えます。

##仕組み：2件の脆弱性

この節は、技術的な中身を知りたい人向けです。どちらも認証なしで、PHP を動かすプロセスの権限でのコード実行につながりうる脆弱性です。

CVE-2026-109618（RCE via OOM corruption）

PHP はメモリ不足になると、その時点の処理を打ち切ってリクエストを中断します。この打ち切りを想定していない処理の途中で中断が起きると、リクエスト用のメモリが不正な状態のまま残り、後片付けの処理がそれを使うことがあります。メモリ不足を起こす手法は複数あり、この状態を安定して引き起こせるとされています。

CVE-2026-109619（RCE via stale global state）

PHP のワーカーは、エラーやセッションなどの状態を保持し続けており、その一部はリクエストのメモリを指しています。リクエストの終了時にこの状態がリセットされないままメモリが解放されると、同じワーカーが処理する次のリクエストで、初期化の前に動く処理がこの古い状態を使うことがあります（解放後使用）。

問題はどの層で起きるか

実行環境ごとの影響

公式が影響を受けるとするのは、Web リクエストを処理するすべての PHP です。実行環境ごとに、確認されている状況が違います。

深刻度の評価は分かれる

深刻度は、評価する組織によって分かれます。報道の一部にある CVSS 10.0 は、公式の評価ではありません。

##悪用の状況

悪用を観測したかどうかは、情報源で分かれています。本文を書いた 2026 年 10 月 25 日時点で、米 CISA の悪用された脆弱性の一覧（KEV）には、どちらの CVE も載っていません。日本国内での実際の被害は、確認できていません（未確認）。

##経緯

発見から公表まで

時刻は日本時間です。出典によって時刻が食い違うものは、その旨を書いています。

国内の動き

国家サイバー統括室と高市首相が X で、修正版の適用と、すぐ当てられない場合のサイトの一時停止を呼びかけました。予防のためサイトを止めた国内の組織は、piyolog の集計（10/24 時点）で 246 にのぼります。分類ごとの数は次のとおりです。各組織の一覧は piyolog の記事にまとまっています。

##まとめ

アップデートすべきは、WordPress ではなく土台の PHP です。そして「更新して終わり」ではなく、事前の侵害がなかったかを確かめるまでが一連の作業です。

1. 確認：PHP の版を確かめる
2. 更新：修正版より古ければ上げる（8.1 以前は 8.2 以降への移行を計画）
3. 設定：session.upload_progress.enabled=0 を入れ、更新後も当面残す
4. 点検：10 月 20 日以降のログで 3 つの痕跡を確かめる

##関連動画

• 長尺：なぜ一夜で 200 以上のサイトが止まったのか（検証環境で解剖）
• Shorts：日本中のサイトが緊急停止した「PHP2Shell」、隔離ラボで動かしてみた