PHP脆弱性「php2shell」（CVE-2026-109618/109619）、パッチ公開前にWordPressサイトで確かめたこと【Xserver実例・随時更新】

10月21日の夕方、XserverのサーバーパネルでPHPの設定を1行だけ変えようとして、ログイン画面の先に進めませんでした。
変えたかったのは session.upload_progress.enabled という設定です。前の晩にPHPの開発チームが「重大な脆弱性の緊急修正を出す」と予告していて、その修正が出るまでの間、この設定を切っておくと被害を抑えられるかもしれない、という話が昼ごろから広まっていました。管理画面に入れないなら、ほかにどうやって確かめればいいのか。そこから考えたことを、順番に書いておきます。

先に書いておくと、私のサーバーでは、この設定はすでにOffになっていました。ただ、それで終わりにしていいかというと、そうでもなさそうです。

夕方、Xserverの管理画面に入れなかった

サーバーパネルが開けなかった理由は、Xserverのお知らせを見て分かりました。「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」というもので、10月21日16時から、サーバーパネル、アカウント管理画面、ファイルマネージャ、WEBメール、API・MCPなどがまとめて止められていました。再開の見込みは「21日深夜〜22日未明」です。

お知らせには「弊社システムで使用しているソフトウェアについて、セキュリティ上の問題（脆弱性）の詳細と修正版が本日公表される予定」とあり、ソフトウェアの名前は書かれていません。ただ、日付とタイミングからすると、PHPの件と見るのが自然だと思います。不正アクセスが起きたわけではない、とも明記されていました。

大事なのは、止まっているのが管理画面の側だけだという点です。お知らせにも「お客様のご利用サーバーへの影響はございません」「Webサイトの表示やメールソフトでの送受信は、通常どおりご利用いただけます」とあります。サイトは普通に表示されますし、FTPでファイルを置くこともできます。設定画面からphp.iniを変えることはできなくても、サーバーの中身を確かめる手段は残っている、ということです。
そしてお知らせには、もう一文ありました。「お客様のご利用サーバーについても、稼働を継続しながら、安全対策を進めております」。これを読んで、何かを変える前に、まず今の設定を見るべきだと思い直しました。

php2shellについて、いま分かっていること

確認の話の前に、そもそも何が起きているのかを整理しておきます。ここは、確かなことと、まだ推測でしかないことを分けて書きます。修正版が公開される前なので、ここが混ざっている記事が多いと感じたからです。

PHPの開発チームが公式に告知したこと

PHPのセキュリティチームは、10月20日（協定世界時）に、緊急のセキュリティリリースを予告しました。対象は「Critical」の脆弱性が2件で、CVSS v4.0の評価はどちらも9.2です。修正版の公開は10月21日14時（協定世界時）、日本時間では21日23時の予定です。詳細が漏れたり、悪用の証拠が見つかったりした場合は、前倒しする可能性があるとしています。
影響するバージョン、修正版の番号、技術的な詳細は、リリースと同時に公表されることになっています。公式の告知の時点では、回避策も示されていません。公式に言われているのは、ここまでです。

研究者やセキュリティ企業が推測していること

「php2shell」という呼び名や、CVE-2026-109618・CVE-2026-109619という番号は、研究者の投稿などで出回っているものです。18時の時点で、PHPの公式告知にはまだ載っていません。
中身については、外部から任意のコードを実行される（RCE）メモリ破壊系のバグだろう、という見方がされています。研究者が公開した動画では、Webサーバーの実行ユーザーの権限でコマンドが実行されていました。mod_php、PHP-FPM、WordPress、Laravel、Symfonyといった構成で再現した、とも書かれています。
国内では、GMO Flatt Securityが、既定で有効になっている「Session Upload Progress」という機能（PHPのセッション拡張の一部）が関係していると推定しています。1件目はここ、2件目はファイルアップロードの解析部分ではないか、という海外の分析もあります。どれも、公式の発表で確かめられるまでは推測です。

悪用はすでに始まっている、という報告もある

昼ごろまでは「実際の悪用は確認されていない」という報道が多かったのですが、夕方には状況が変わりました。WordPressのセキュリティ企業Patchstackは、21日7時34分（協定世界時、日本時間16時34分）の更新で、実際の悪用が複数確認されたと追記しています。詳細の一部が事前に漏れたことが原因だ、という見立てです。
海外の掲示板でも、「攻撃の手順がSNSに流れた」として、パッチが出るまでWebサーバーを止めたり、インターネットから切り離したりしたという書き込みが見られました。こちらは裏付けのない話ですが、運用している人たちがそれだけ身構えている、ということは伝わってきます。修正版を待つ数時間を「まだ何も起きていない時間」と考えないほうがよさそうです。

まだ誰にも分からないこと

影響するバージョンの範囲が分かっていません。「PHP 5以降すべて」という見方もあれば、「PHP 8系だけ」という報道もあります。
修正版が出るのは、PHPがいまサポートしている8.2〜8.5だけだろう、という報道もあります。もしそうなら、8.1以前で動いているサイトは、修正版を当てるという選択肢がありません。バージョンを上げるか、外から隔離するかになります。
修正版の番号として「8.5.12」「8.4.27」などの数字も出回っていますが、これも推測で、公式の番号ではありません（23時の公開で、この番号どおりだったことが確認できました。次の項目を参照）。

23時、修正版が出た

予定どおり、日本時間の21日23時に修正版が公開されました。PHPのChangeLogでは、どの系列も日付が10月22日になっています。

セキュリティ修正は、4系列とも同じものです。ChangeLogの「Core」の項目に、GitHubのセキュリティアドバイザリ番号が2つ（GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）並び、説明は「Avoid state corruption via bailout（bailoutによる状態の破損を防ぐ）」の一行だけです。
bailoutというのは、PHPがメモリの上限超えのような致命的なエラーに当たったとき、処理を途中で打ち切って抜け出す仕組みのことです。打ち切った時点の内部の状態が壊れたまま残り、そこを突かれた、という種類の不具合だと読めます。ただ、これはChangeLogの一行からの私の読み取りで、アドバイザリの本文はまだ読めていません。

気になったのは、修正が「Core」に入っていて、セッション（Session）の項目には、アップロード進捗に関する修正が見当たらないことです。事前に言われていた「Session Upload Progressが原因」という推測とは、少なくとも修正箇所の書き方は合っていません。
また、ChangeLogにはCVE番号が載っていません。事前に出回っていたCVE-2026-109618・CVE-2026-109619という番号と、この2つのアドバイザリがどう対応するのかは、23時15分の時点では公式に確認できていません。

8.3と8.2は、PHPの開発チームがセキュリティ修正だけを入れる段階の系列なので、今回の修正だけが入っています。アップデートで動きが変わる心配は小さい、ということでもあります。8.1以前には修正版が出ていません。8.1以前で動いているサイトは、8.2以降に上げるか、ディストリビューションやホスティング会社が独自に修正を取り込むのを待つことになります。

暫定策として言われているのは、設定を1行変えることだった

修正版が出るまでの暫定策として、GMO Flatt Securityが挙げているのが、php.iniで次のように設定することです。

ただし、Flatt自身も「一定の効果は期待できるが、100%防げるとは言えない」としています。2件のうち1件にしか効かない、という分析もあります。推定された原因にもとづく対策なので、推定が外れていれば効果はありません。修正版の代わりにはならない、というのが正確なところです。

（23時15分追記）修正版が出る前後で、この暫定策への評価は厳しくなりました。Tenableのまとめによると、PHPの開発者のGina Peter Banyard氏は「唯一の緩和策はパッチを当てること、PHPをアップグレードすることだ」と述べていて、アップロード進捗の設定変更には効果がない、という見方も出ています。上で書いたとおり、公式の修正箇所もセッションの機能ではありませんでした。この設定を切っておくことに害はありませんが、これで守られていると考えるのはやめておいたほうがよさそうです。

WordPressのサイトに限っていえば、この設定を切っても困ることは、まずないはずです。この機能は、ファイルをアップロードしている最中の進み具合を、PHPのセッションに記録するためのものです。WordPress本体はPHPのセッションを使っていませんし、メディアのアップロードのときに出る進捗表示は、ブラウザ側のJavaScriptでやっています。
一方で、気になる点もあります。WordPressがセッションを使っていなくても、この機能はPHPがリクエストを受け取る段階で動きます。サイトのコードが何もしていなくても、初期設定のままなら有効になっている、ということです。「うちはセッションを使っていないから関係ない」とは言えません。

余談ですが、この設定はPHPのコードの中から ini_set() で変えることができません。マニュアル上は「PHP_INI_PERDIR」という区分の設定で、php.iniか、ディレクトリ単位の設定ファイルでしか変えられないことになっています。だから、WordPressのプラグインで対策する、ということもできません。そもそもこの処理は、PHPのスクリプトが動き始める前、リクエストの本文を読み込む段階で走るので、プラグインの出番が来る前に終わってしまいます。プラグインを作っている身としては、こういうときに手を出せる範囲が意外と狭いことを、あらためて思い知らされます。

phpinfoを見たら、すでにOffになっていた

管理画面に入れないので、FTPで小さなPHPファイルを置いて、phpinfoを表示させました。sessionの項目までスクロールすると、session.upload_progress.enabled はOffになっていました。

ここで見ておきたいのは、右の2列です。phpinfoの設定の表には「Local Value」と「Master Value」が並んでいます。Master Valueは、サーバー全体のphp.iniに書かれている値。Local Valueは、そこに .user.ini などのディレクトリ単位の設定を重ねたあとの、実際に効いている値です。
今回は、Master ValueもOffでした。私が自分で何かを設定したわけではなく、サーバー全体の設定の段階でOffになっている、ということです。PHPの既定値はOnなので、Xserverが予防策の一つとして切り替えたのだろうと思います。ただ、以前からOffだったのかどうかは、この画面からは分かりません。お知らせにも、具体的に何を変えたかは書かれていませんでした。

もう一つ、見落としやすい点があります。この設定は、サーバー全体のphp.iniでOffにしてあっても、ディレクトリに置いた .user.ini でOnに戻せてしまいます。ディレクトリ単位で上書きできる種類の設定だからです。海外のホスティング会社の担当者も、掲示板で同じ点を注意していました。
つまり、本当に見るべきなのはMaster Valueではなく、Local Valueのほうです。昔どこかで置いた .user.ini や、プラグインが書き出した設定ファイルが残っていると、Master ValueはOffなのにLocal ValueはOn、ということが起こりえます。私のサーバーでは両方Offだったので、ここは問題ありませんでした。

なお、これは私のサーバー（raplsworks.comを置いているXserverのサーバー）で見た結果です。Xserverのすべてのサーバーで同じとは限らないので、Xserverを使っている方も、自分のサーバーで一度確かめておくのが確実です。

自分のサーバーで確かめるなら、こうする

phpinfoを表示するファイルを置く

中身はこの1行だけです。ファイル名は、推測されにくいものにしておきます。

これをFTPで公開ディレクトリに置き、ブラウザで開きます。見るのは3か所です。まず session.upload_progress.enabled の Local Value がOffかどうか。Master Valueではなく、実際に効いているLocal Valueのほうを見ます。Offなら、ひとまずこの設定については終わりです。Onだった場合に備えて、表の上のほうにある「Server API」と「user_ini.filename」も見ておきます。

見終わったら、すぐ消す

phpinfoは、PHPのバージョン、読み込んでいる拡張、サーバーのパスなど、攻撃する側にとっても役に立つ情報をまとめて表示します。確認が終わったら、置いたファイルはすぐに削除してください。

ターミナルの php -i では確かめられない

SSHが使える方は、php -i で同じ情報が見られると思うかもしれません。ただ、あれはコマンドライン（CLI）用のPHPの設定で、Webサーバーが使っているPHPの設定とは別のことがあります。Webサイトに効いている値を知りたいなら、ブラウザからphpinfoを見るのが確実です。

Onのままだったときに、管理画面なしで試せること

.user.ini を置いてみる

phpinfoの「Server API」がCGI/FastCGIで、「user_ini.filename」が .user.ini になっていれば、WordPressの index.php と同じ場所に、次の1行だけを書いた .user.ini を置く方法があります。

PHPは、実行するファイルのあるディレクトリから公開ディレクトリまでさかのぼって .user.ini を探すので、WordPressのルートに置けば管理画面（wp-admin）の下にも効きます。反映には最大5分ほどかかります。少し待ってから、もう一度phpinfoで、Local ValueがOffになったかを確かめます。
正直に書くと、XserverでWebサーバーがこのファイルを読むかどうかは、私の環境ではもともとOffだったので試せていません。読まれなかった場合も、効かないだけでサイトが壊れることはないはずなので、試す価値はあると思います。

.htaccess の php_flag は使わない

ネットで調べると、.htaccessに php_flag で書く方法も出てきます。ただ、これが効くのはPHPがApacheのモジュール（mod_php）として動いている場合だけです。CGI/FastCGIの環境で書くと、サイト全体が500エラーになることがあります。共用サーバーでは避けたほうが安全です。

どれも効かなければ、待つしかない

サーバー全体の設定を変えられるのは、サーバーの管理者だけです。共用サーバーなら、ホスティング会社のお知らせを待つことになります。Xserverのように、ホスティング会社の側で対策を進めている場合もあります。

Offだったからといって、終わりではない

ここまで確かめて、ひとまずは落ち着きました。ただ、この設定はあくまで推定にもとづく暫定策で、2件のうち1件にしか効かないかもしれない、という見方もあります。本当の対策は、修正版をサーバーに当てることです。23時に出た修正版は、8.5.12、8.4.27、8.3.36、8.2.35でした。修正箇所がセッションの機能ではなかったことを考えると、Offになっていたことは、なおさら安心材料になりません。
共用サーバーの場合、PHP本体を更新できるのはホスティング会社だけです。Xserverなら、管理画面が再開したあとのお知らせと、phpinfoに出るPHPのバージョンで、修正版が入ったかどうかを確かめることになると思います。自分でサーバーを管理している方は、ディストリビューションのパッケージが更新されたら、PHP-FPM（またはApache）の再起動まで済ませて、はじめて反映されます。

もう一つ、書いておきたいことがあります。この脆弱性の「攻撃コード（PoC）」と称するものが、GitHubなどにすでに出回っています。詳細が公開される前に出てくる攻撃コードは、試した人のパソコンを乗っ取るためのマルウェアが仕込まれた偽物であることが少なくありません。確かめたくなる気持ちは分かりますが、手元のマシンで動かすのはやめておいたほうがいいです。

raplsworks.comのサーバーはPHP 8.3系で動いているので、私が待っているのは、Xserverで8.3.36（あるいは同じ修正を取り込んだ版）に上がることです。
修正版が出た20分後の23時20分に、もう一度phpinfoを見てみました。PHPのバージョンは8.3.35のままでした。9月に出た、今回の修正が入る前の版です。
ホスティング会社が修正だけを古い番号のまま取り込む、ということもあるので、番号だけで「未対応」と言い切ることはできません。ただ、Xserverからそういう案内はまだ出ておらず、管理画面も止まったままなので、いまは未適用と考えて待つしかありません。共用サーバーでは、PHP本体の更新はホスティング会社にしかできないからです。

参考にした情報は次のとおりです。

• PHP 8 ChangeLog（php.net） ── 8.5.12／8.4.27／8.3.36／8.2.35の修正内容
• php2shell FAQ（Tenable／Security Boulevard）
• PHPの重大な脆弱性「php2shell」（CVE-2026-109618、CVE-2026-109619）の概要と対応指針（GMO Flatt Security）
• PHP公式の事前告知（php.net）
• 「PHP」に“致命的”な脆弱性2件、日本時間21日深夜に緊急のセキュリティリリースへ（窓の杜）
• PHP緊急脆弱性「php2shell」パッチ今夜11時公開、その前にできる対策は（ITmedia NEWS）
• Disabling session.upload_progress Before the php2shell Patch Lands（lilting.ch）
• Major security alert: PHP vulnerable to critical RCE, attacks ongoing（Patchstack）
• PHP CVE-2026-109618 and CVE-2026-109619: What We Know about php2shell?（PentestIT）

Rapls Works のその他の記事

• Ghostscriptの脆弱性CVE-2026-39919と、WordPressでPDFサムネイルを作るサイトがやること ── 同じくサーバー側のソフトの脆弱性。WordPressのどこを通って届くのかを整理しています。

最後に追記した21日23時20分の時点で、PHPの修正版は公開済み、raplsworks.comのサーバーのPHPは8.3.35のままです。