PHPの緊急脆弱性「PHP2Shell」。自分のサイトは大丈夫？　今すぐ確認することと、当夜に実際にやった対応

結論から。 2026年10月21日の夜、PHP に「ログインなしでサーバーを乗っ取られる」深刻な脆弱性2件（通称 PHP2Shell）の修正版が公開されました。WordPress や EC-CUBE など、PHP で動くサイトはほぼすべてが対象です。完全な対策は修正版への更新だけで、それまでの時間稼ぎとして公式の一時対策があります。レンタルサーバーなら事業者の対応を待ちつつ、できる範囲の一時対策と改ざんの監視をします。サポートが切れた古い PHP で動いているサイトが、いちばん危ない状態です。

この記事は、前半が「サイトを持っている方向け」で、何が起きているのか、何がまずいのか、自分のサイトが対象かどうかの確認のしかた、対応が必要なケースと不要なケース、できること、保守会社や事業者への頼み方、の順で書いています。後半は、サーバーを管理している方向けの実践編です。前半だけ読んでも判断できるように書いています。

※記事中の情報は2026年10月22日未明時点のものです。状況は動いているので、公式の情報もあわせて確認してください。

何が起きているのか

PHP の開発チームが、10月21日23時（日本時間）に緊急の修正版 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を公開しました。深刻度「Critical」の脆弱性2件への対応です。

前日の20日に公開予告が出ていましたが、修正版が出る前に脆弱性の詳細が外部に漏れてしまい、国内でもサービスを緊急停止する企業が相次ぎました。セキュリティ企業からは、実際の悪用も報告されています。

CVE	深刻度	ざっくり言うと
CVE-2026-109618	CVSS v4.0 9.2	メモリ不足のエラーで処理が中断されたとき、準備途中のデータを正しいものとして後片付けしてしまう
CVE-2026-109619	CVSS v4.0 9.2	解放済みのメモリを指す状態が残り、同じワーカーが次のリクエストを処理するときにそれを使ってしまう

どちらも、PHP が Web リクエストを処理する途中で起きる、メモリ管理の不具合です。影響を受けるバージョンは「PHP 5 以降ほぼすべて」と報告されています。

何がまずいのか

攻撃者は、PHP で動いているページならどれにでも、細工したリクエストを送るだけで、サーバー上で好きな命令を実行できます。ログインは要りません。

しかも攻撃が成立するのは、PHP がリクエストの中身を読み込む段階です。WordPress や EC-CUBE のプログラムが動き出す前なので、アプリ側のセキュリティ対策（プラグイン、ログイン制限、管理画面の IP 制限）では防げません。

攻撃が成立するのは、WordPress や EC-CUBE が動き出す前の段階

乗っ取られた場合に起こりうることは次のとおりです。

サイトの改ざん（偽のページ、不正な広告、別サイトへの誘導）
データベースの中身の流出。DB の接続情報は設定ファイルに書かれているため、顧客情報や注文情報まで届きます
裏口プログラムの設置。PHP を更新したあとも侵入経路が残るおそれがあります
EC サイトの決済画面の差し替えによる、カード情報の窃取

さらに今回は、修正版が出る前に詳細が漏れています。「修正版が出たから安心」ではなく、「修正版が出る前から攻撃できる状態だった」と考えて動く必要があります。

自分のサイトが対象か、どうやって確認する？

確認することは3つです。順番に見ていけば、5分で分かります。

1. PHP で動いているか

次のどれかに当てはまれば、まず PHP です。

WordPress で作られている
EC-CUBE、Welcart などのネットショップ
レンタルサーバーの管理画面に「PHP のバージョン」という設定がある
制作会社から「PHP のバージョンを上げる必要がある」と言われたことがある

Wix・Shopify・STUDIO・ペライチのようなサービスで作ったサイトは、PHP で動いていても利用者側に触れる部分がなく、サービス側が対応します。

2. PHP のバージョン

レンタルサーバーなら、コントロールパネルの「PHP 設定」「PHP バージョン」のような項目に書いてあります。WordPress なら、管理画面の「ツール → サイトヘルス → 情報 → サーバー」にも出ます。

見るのは、先頭の数字です。8.2 以上か、8.1 以下かで、やることが変わります。

3. サーバーの種類

レンタルサーバー（さくら、ロリポップ、エックスサーバー、ConoHa WING など）：PHP 本体の更新は事業者がやる
VPS・クラウド（さくらの VPS、ConoHa VPS、AWS など）：自分（か保守会社）がやる
分からない：制作会社か保守会社に聞く。毎月の請求書に「サーバー費」があれば、その宛先が答えです

確認は3つ。PHPかどうか、バージョン、サーバーの種類

どのケースなら対応が必要で、どのケースなら不要？

上の3つの確認結果で、次のように分かれます。

ケース	対応
PHP で動いていない（Wix・Shopify などのサービス、静的な HTML だけ）	不要。サービス側が対応します
レンタルサーバー × PHP 8.2 以上	事業者の対応待ち。お知らせを確認し、更新の告知が出るまでは後半の一時対策と監視をする
レンタルサーバー × PHP 8.1 以下	急ぐ。事業者が修正を当てるかどうか、お知らせで確認する。当てない場合は、コントロールパネルで 8.2 以上に切り替えられないか確認する（切り替えるとサイトが壊れることがあるので、先に保守会社に相談）
VPS・クラウド × PHP 8.2 以上	今夜のうちに。後半の手順で一時対策を入れ、修正版が届き次第更新する
VPS・クラウド × PHP 8.1 以下	いちばん急ぐ。公式の修正版は出ない。後半の「【実践編】サポート切れの PHP」を読んで、保守会社に連絡する
制作会社・保守会社に丸ごと任せている	連絡する。次の「どうやって頼めばいいか」を参照

「対象外」と言い切れるのは、1行目だけです。それ以外は、程度の差はあっても何かしら動く必要があります。

自分でできることは何か

サーバーに詳しくなくても、できることが3つあります。どのケースでも、やっておいて損はありません。

バックアップを取る。 公開ディレクトリ一式とデータベース。改ざんされたときの比較用と、復旧用を兼ねます。レンタルサーバーなら、コントロールパネルのバックアップ機能か、FTP ソフトで丸ごとダウンロードします
管理者アカウントを確認する。 WordPress や EC-CUBE の管理画面で、知らない管理者が増えていないか見ます。増えていたら、その時点で侵入済みです
WAF を有効にする。 レンタルサーバーのコントロールパネルに「WAF」の項目があれば、オンにします。完全には防げませんが、攻撃の一部は止まります

逆に、やらないほうがいいこともあります。

焦って PHP のバージョンをコントロールパネルで切り替える。 8.1 → 8.3 のような切り替えは、サイトが真っ白になることがあります。切り替える前に、保守会社に相談するか、少なくともバックアップを取ります
知らない人の「対策プラグイン」を入れる。 今回の脆弱性はアプリの外側で起きるので、プラグインでは防げません。便乗した偽プラグインの可能性もあります

保守会社や事業者に、どうやって頼めばいいか

「よく分からないけど不安」という状態で連絡しても、相手が答えにくいだけです。聞くことを絞ると、返事が早くなります。

制作会社・保守会社に送る文面の例

PHP の脆弱性「PHP2Shell」（CVE-2026-109618 / CVE-2026-109619）の件で、弊社サイトの状況を教えてください。

弊社サイトの PHP のバージョンと、サーバーの種類（レンタル／VPS）

修正版への更新、または一時対策の予定と時期

弊社側で何かやることがあるか

急ぎで恐縮ですが、本日中にご返信いただけると助かります。

返事が「対象外です」か「対応済みです（いつ、何をしたか）」のどちらかになるまで追います。「確認します」のまま2日以上止まったら、もう一度聞きます。

レンタルサーバーの事業者に対しては、問い合わせより先に、公式のお知らせページを見ます。今回のような事態では、事業者は全利用者向けに告知を出していて、問い合わせ窓口は混み合っています。お知らせに「対応済み」「メンテナンス予定」のどちらも書かれていないときだけ、問い合わせます。

ここから後半は、サーバーの管理をしている方向けの実践編です。

【実践編】VPS（自社管理サーバー）での対応手順

とある会社の VPS（Ubuntu 24.04、nginx + PHP-FPM）で、修正版の公開直後に行った手順です。

1. PHP の版と入手元を確認する

php -v と apt-cache policy php8.x-fpm で確認します。このサーバーでは、Ubuntu 標準の 8.3 と外部リポジトリ（ondřej PPA）の 8.4 が同居していて、FPM も2つ動いていました。

ターミナルの php -v は CLI 版の情報です。Web の処理を担う FPM は別物なので、systemctl list-units | grep php で動いている FPM をすべて洗い出します。

2. 修正版が来ているか確認する

sudo apt update のあと、更新候補の版を見ます。php.net で公開されてから OS のパッケージに反映されるまでには時差があり、当夜の時点では 8.4.27 / 8.3.36 はまだ届いていませんでした。

Ubuntu 標準のパッケージは、版の番号を上げずに修正だけを取り込みます。そのため、apt changelog に CVE 番号が載っているかどうかで判断します。

3. 修正版が届くまでの一時対策を入れる

公式が案内している緩和策を、すべての FPM の設定ディレクトリに追加して再起動しました。

; /etc/php/8.x/fpm/conf.d/99-php2shell.ini
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

ファイルのアップロードが必要なサイトでは、post_max_size を 32M にします。.user.ini や ini_set() では効かないので、必ず php.ini か FPM の pool 設定に書きます。

これは確認済みの攻撃経路を塞ぐだけで、完全な対策ではありません。

4. 使っていない FPM は止める

nginx の fastcgi_pass を確認し、使われていない FPM は停止して、攻撃を受ける窓口を減らします。

5. 修正版が届いたら更新して再起動する

sudo apt install --only-upgrade 'php8.x*' を実行して FPM を再起動し、CLI と Web 経由の両方で版を確認します。他のパッケージの一括更新や OS のアップグレードは、別の機会に分けて行います。今夜はこれだけに絞ります。

【実践編】レンタルサーバーの場合

レンタルサーバーでは、PHP 本体の更新は事業者が行います。利用者は更新されるのを待つしかなく、その間もサイトは公開されたままなので、リスクが残ります。

当夜は国内の大手事業者も緊急メンテナンスを実施していて、管理画面や SFTP につながらない時間帯がありました。そんな中でも通常の FTP は使えたため、FTP だけでできる範囲の一時対策を入れました。

1. PHP の動き方を確認する

推測されにくい名前のファイル（例：chk_8f3k2.php）に <?php phpinfo(); と書いてアップロードし、ブラウザで開きます。見る項目は3つです。

項目	見るところ
PHP Version	サポート中の版かどうか
Build Date	事業者が修正を当てて作り直したかどうかの目安（後述）
Server API	`Apache 2.0 Handler` なら mod_php で、公式が最も危険とする構成。`CGI/FastCGI` なら CGI 系

確認が終わったら、phpinfo のファイルは必ずすぐ削除してください。サーバーの内部情報が丸見えになるためです。

2. `.htaccess` で一時対策を入れる（mod_php の場合）

mod_php で動いている場合は、.htaccess で PHP の設定を上書きできることがあります。とある EC サイト（さくらのレンタルサーバ、PHP 7.4、mod_php、EC-CUBE 2系）では、次の手順で設定が効くことを確認しました。

ドキュメントルートの .htaccess をダウンロードして、バックアップしておきます
先頭に次の3行を追加して、アップロードします

php_flag session.upload_progress.enabled off
php_value post_max_size 32M
php_value upload_max_filesize 30M

トップページ、商品ページ、管理画面を開いて、500 エラーにならないか確認します。エラーになった場合は事業者が許可していない設定なので、すぐバックアップに戻します
もう一度 phpinfo を開き、session.upload_progress.enabled の Local Value が Off、Master Value が On になっていれば、このサイトでは設定が効いています。確認したら phpinfo を削除します

phpinfo で Local Value が Off になっていれば、.htaccess の設定が効いている

EC-CUBE 2系は upload_progress の機能を使っていないため、Off にしても動作に影響はありません。商品画像のアップロードがあるので、post_max_size は 8M ではなく 32M にしています。設定後に、管理画面から画像を登録できるかも確認しておきます。

.htaccess が使えない場合は、管理画面の「php.ini 設定」などで同じ項目を設定します。いずれにしても、確認済みの攻撃経路を1つ塞ぐだけで、完全な対策ではありません。

3. 改ざんに備えて、基準を取って監視する

FTP ではコマンドを実行できないため、次の方法で監視します。

公開ディレクトリ一式をダウンロードしておく。 改ざんされたときの比較用と、復旧用を兼ねます
データベースもバックアップしておく。 管理画面が使えるようになったら取得します
毎日、ファイルを更新日時順に並べて確認する。 覚えのない新しい .php ファイルがないかを見ます。画像のアップロード先（EC-CUBE なら upload/ の下）に .php があったら要注意です
管理者アカウントを確認する。 アプリの管理画面で、知らない管理者が増えていないか見ます
気になるファイルがあれば差分を取る。 ダウンロードしておいたものと、WinMerge などで比べます

通常の FTP はパスワードが暗号化されずに流れるので、FTP ソフトが対応していれば FTPS（明示的な TLS）で接続します。

4. そのほか

事業者のお知らせを確認する。 PHP の更新状況やメンテナンスの対象ホストを確認します
WAF を有効にする。 コントロールパネルで有効にできることが多いです
PHP のバージョンを見直す。 管理画面で選べる、サポート中の版への移行を計画します

【実践編】サポート切れの PHP を使っている場合

一番危ないのは、サポートが切れた古い PHP で動いているサイトです。公式の修正版が出ないので、事業者や LTS ベンダーが独自に修正を移植しない限り、穴は開いたままになります。

ただし今回は深刻さを考慮して、7.4・8.0・8.1 向けに最小限のソースパッチが例外的に公開されています。

PHP の版	公式の修正	当面の対応	根本的な対応
8.2〜8.5	修正版あり	修正版に更新する	8.2 は2026年12月末でサポート終了。上の版へ移行を計画
7.4 / 8.0 / 8.1	最小限のソースパッチのみ	事業者の対応を確認し、一時対策を入れる	サポート中の版へ移行
7.3 以前	なし	一時対策、アクセス制限、WAF。決済のあるサイトは一時閉鎖も検討	アプリごと移行（EC-CUBE 3系なら EC-CUBE 4.3 へ）

PHP 7.4.33 と表示されていても、修正済みとは限らない

7.4.33 は 7.4 系の最後の公式リリース（2022年11月）で、今回の 7.4 向けの修正は新しい版ではなく、このバージョンに当てるソースパッチとして出ています。そのため、事業者が修正を当てても、表示は 7.4.33 のままになる可能性が高いです。

判断するときは、phpinfo の「Build Date」が2026年10月21日より後になっているか、事業者から修正適用の告知が出ているかを確認します。8.0・8.1 も同じ考え方です。

EC-CUBE は、本体のバージョンが PHP を縛っている

EC-CUBE の場合は、本体のバージョンが対応する PHP を決めています。たとえば EC-CUBE 4.0 は PHP 7.4 までしか対応していないため、PHP 8 系に上げるには本体を 4.2 や 4.3 に上げる必要があります。

一方、EC-CUBE 2.17 系は PHP 8 系への対応が進んでいるため、カスタマイズ部分の動作確認は必要ですが、比較的小さな改修で PHP を上げられる見込みがあります。

古い EC-CUBE を古い PHP で動かし続けている構成は、今回のような事態で打てる手がほとんどありません。今回の件を、移行計画を立てるきっかけにしてください。

まとめ

完全な対策は、修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）への更新だけ。一時対策は、更新までの時間稼ぎ
攻撃は WordPress や EC-CUBE が動く前の段階で成立する。アプリ側のセキュリティ対策では防げない
自社で管理しているサーバーは、PHP の入手元と、動いている FPM をすべて洗い出してから対応する
レンタルサーバーは事業者の対応待ち。その間は .htaccess や php.ini 設定での一時対策と、改ざんの監視をする
PHP 7.4.33 の表示は修正済みの証拠にならない。Build Date か事業者の告知で判断する
サポート切れの PHP で動いているサイトは、移行の計画を今すぐ立てる

お使いのサイトが対象かどうか分からない、保守会社から返事がない、という場合は、相談だけでも構いません。