【PHP】追加の脆弱性CVE-2026-115560の影響を、WordPressサイトでどう確かめたか｜grep 1回で判断できた理由

php2shell（CVE-2026-109618 / CVE-2026-109619）の修正版が公開された2日後の2026年10月23日、PHP公式から別の脆弱性CVE-2026-115560の情報提供のアドバイザリが出ました。

「また緊急対応か」と身構えましたが、発生条件を読み解いて担当しているサイトのコードを確かめた結果、緊急の対応は要らないと判断しました。この記事では、その確かめ方と判断の根拠をまとめます。

この記事の内容は2026年10月時点のものです。

php2shellへの対応は、PHPの緊急脆弱性に、Xserver上のWordPressで一晩対応した記録 と PHPを自分で上げられない環境でどう備えたか にまとめています。

この記事の要点

• CVE-2026-115560は、php2shellの修正版（8.2.35、8.3.36など）では直っていない、別の問題
• ただし、特殊な設定とアプリのコードがそろったときだけ起きる。PHP公式も「起こりにくい」としていて、修正は次の定例リリースで行われる
• WordPress本体はPHPのセッション機能を使っていないので、通常は当てはまらない
• 念のため、サーバー上のすべてのPHPファイルをserialize_handlerで検索し、当てはまるコードがないことを確かめた

脆弱性の概要

セッションのアップロード進捗機能（session.upload_progress）を悪用して、リモートでコードを実行できる可能性がある脆弱性です。

PHP公式によると、次の条件が すべて そろったアプリだけが対象です。

1. 設定ファイルでsession.serialize_handlerをphp_binaryかphp_serializeにしている
2. アプリのコードの中で、ini_set()を使ってそれをphpに切り替えてからsession_start()を呼んでいる
3. セッションのアップロード進捗機能が有効になっている（初期設定では有効）

公式の位置づけは次のとおりです。

• 「起こりにくい（unlikely）」攻撃の経路とされている
• 攻撃の報告はない
• 緊急リリースはせず、次の定例リリースで修正し、詳しいアドバイザリもそのときに出す
• 修正までの対策としてsession.upload_progress.enabled=0を推奨。php2shellのときにこの設定をすでに入れていれば、追加の対応は要らない

影響の確かめ方の考え方

3つの条件のうち、アプリ側で決まるのは条件2だけです。条件1と3はサーバーの設定なので、共用サーバーやマネージドホスティングでは事業者が管理しています。

条件2を満たすには、コードの中に必ずserialize_handlerという設定の名前が書かれます。そこで、この文字列がコードに1つもなければ、条件2は満たされないと判断できます。

なお、WordPress本体はPHPのセッション機能（session_start()）を使っていません。気にする必要があるのは、プラグインやテーマが独自にセッションを使っている場合だけです。

実際の確かめ方

サーバーにSSHで入り、WordPressを置いているフォルダの中のすべてのPHPファイル（本体、テーマ、プラグイン）を検索しました。

cd <WordPressを置いているフォルダ>
grep -rn "serialize_handler" --include='*.php' .

何も表示されなければ、当てはまるコードはありません。担当しているサイトは、どれも何も表示されませんでした。

SSHが使えない環境では、FTPなどでwp-contentフォルダを手元にダウンロードし、手元で同じgrepを実行しても確かめられます。WordPress本体は使っていないので、wp-contentだけで十分です。

環境ごとの判断

サーバーの設定を自分で見られない環境では、事業者に次の点を問い合わせておくと確実です。

• session.serialize_handlerとsession.upload_progress.enabledの設定の状況
• 公式が推奨するsession.upload_progress.enabled=0を入れる予定があるか
• 次の定例リリースで修正を適用する予定と、適用後の知らせ方

この記事を書いた時点では、問い合わせた事業者からの回答はまだありません。回答が来たら、この記事に追記します。

「明日になったら影響あり」になる可能性

今回の判断は、その時点の情報とコードにもとづくものです。状況が変わりうるのは、主に次の3つの場合です。

次の定例リリースの日付は、この記事を書いた時点ではまだ公式に発表されていません。PHP 8.5系はここ数か月、ほぼ4週間ごとの木曜日にリリースされているので、11月19日ごろと見込んで、その時期にもう一度確かめる予定です。

振り返り

• 条件を読んでから動く：「リモートでコードを実行」という言葉だけで慌てず、発生条件を分解すると、確かめるべきことは「コードにserialize_handlerがあるか」の1点に絞れました
• 事業者の発表を確かめる：共用サーバーやマネージドホスティングでは、利用者が触れないサーバーの設定を、事業者が先に手当てしていることがあります。ステータスページの更新通知に登録しておくと、続報にすぐ気づけます
• 判断に期限を付ける：今回の「影響なし」は暫定の判断です。詳しいアドバイザリが出たときにもう一度確かめることを、最初から決めておきました

参考

• PHP: News Archive – 2026（Informational advisory: Session upload progress）
• Canadian Centre for Cyber Security：AL26-026 Critical vulnerabilities impacting PHP
• The Hacker News：Urgent: PHP Warns of Another Unpatched…
• PHP releases（php.watch）