はじめに

2026 年 10 月 21 日、PHP 本体に 認証なしでリモートからコードを実行される（RCE）おそれのある重大な脆弱性 2 件が公表され、修正版が緊急リリースされました。通称 「php2shell」（CVE-2026-109618 / CVE-2026-109619）です。CVSS v4.0 の評価は 9.2（Critical）、世界の Web サイトの多くが PHP で動いているため、国内でも緊急メンテナンスが相次ぎました。

この記事でわかること

php2shell がどんな脆弱性で、なぜ危険なのか
自分の環境が影響を受けるか、誰が直す責任を持つのか
レンタルサーバー / AWS EC2 / 自社サーバー / STUDIO / ロリポップ+WordPress それぞれの具体的な対応手順
修正版が出るまでの緩和策と、その限界
侵入されていないかを確認する方法

前提：本記事は 2026 年 10 月 22 日時点の公開情報に基づきます。

php2shell とは？

PHP 本体（実行環境）の脆弱性 2 件。アプリのコードのバグではありません。
認証なしでリモートから任意コード実行（RCE）につながるおそれがあり、深刻度は CVSS v4.0 で 9.2（Critical）。
だからこそ対策はシンプルで、PHP を修正版に上げることがほぼ唯一の根本対策です。

2 件の脆弱性の中身

CVE	通称上の位置づけ	原因（ざっくり）
CVE-2026-109618	OOM 時の RCE	メモリ不足（OOM）でリクエストデータの初期化が中断され、部分的にしか初期化されていないデータが後処理で「正常」として扱われる
CVE-2026-109619	Stale Global State による RCE	リクエスト固有の状態が、裏のメモリ解放後も残り、同じワーカーの後続リクエストが古い状態を触ってしまう

どちらも「不完全／古いデータを残すリクエスト」と「それを悪用するリクエスト」を組み合わせる攻撃です。発見元の Wiz によると PHP 5.4 以降のすべてのバージョンが少なくとも一方の影響を受けます。

Apache + mod_php の構成が特に危険

PHP を使う構成（SAPI）は PHP-FPM、Apache + mod_php、php-cgi、FrankenPHP、LiteSpeed など複数ありますが、mod_php ではアプリのコードが動く前の段階で攻撃が成立し得ることが実証されています。つまり「ログイン必須のサイトだから安全」とは言えません。

修正版が「予定より1日早く」リリースされた経緯

今回のリリースは、当初の予定より1日前倒しになっています。PHP Foundation が経緯を説明しているので、背景として把握しておきましょう。

当初の公開予定：2026年10月22日 14:00 UTC（日本時間 23:00）

前倒しの発端：2026年10月20日 15:00 UTC ごろ、Hacker News に「PHPに重大なRCEが存在する」という投稿が現れました。技術的な詳細は含まれていませんでしたが、CVE番号とともにスクリーンショットが X（旧Twitter）や Mastodon で急速に拡散。PHP セキュリティチームはあらかじめ「詳細が公開された場合や野生での悪用が確認された場合は早期リリースを行う」と表明しており、この漏洩がその条件を満たしたと判断しました。

前倒しリリース：2026年10月21日 14:00 UTC（日本時間 23:00）へ1日繰り上げ。実際には 13:35 UTC（予定より25分早く）にリリースされています。

さらにPoC動画が拡散：脆弱性を発見したセキュリティ企業 Calif.io の研究者 LCFR が、エンバーゴ期間中に誤って PoC（攻撃実証）動画をオンラインに公開しました。動画はすぐに削除されましたが、コピーが拡散。PHP Foundation によれば、これが外部での独自 PoC 開発を加速させました。

共通のポイント（全環境に共通）

修正版のバージョン

系統	修正版
8.5 系	8.5.12 以上
8.4 系	8.4.27 以上
8.3 系	8.3.36 以上
8.2 系	8.2.35 以上

8.1 以前はサポートが終了しており、通常の修正版リリースはありません（PHP セキュリティチームによる最小限のソースバックポートが一部提供されていますが、恒久対応としては 8.2 以上への移行を強く推奨します）。

押さえておきたい 5 つのポイント

バージョンは Web 経由で確認する：php -v は CLI 版のバージョンを表示するだけです。アプリが実際に使っている PHP（php-fpm / mod_php）とは別物のことがあります。
更新したら必ず再起動する：再起動しないと、メモリ上で古い PHP が動き続けます。
パッチの入手先は公式だけ：騒ぎに便乗した「修正パッチ」を名乗る偽物に注意してください。
緩和策は時間稼ぎ：後述の緩和策は根本対策ではありません。修正版へのアップデートが完了するまでのつなぎです。
侵入の有無も確認する：公表前から攻撃が観測されています。更新と合わせて痕跡を確認してください。

Web 経由でのバージョン確認方法

実際にアプリが使っている PHP のバージョンと SAPI（fpm-fcgi / apache2handler など）を確認します。

check_version.sh

# 確認用ファイルを作成（ファイル名はランダムにして推測されにくくする）
echo '<?php echo PHP_VERSION, " ", PHP_SAPI;' | sudo tee /var/www/html/v_$(openssl rand -hex 8).php

# 作成されたファイル名にアクセスして表示を確認
curl http://localhost/v_xxxxxxxx.php   # 例: 8.3.36 fpm-fcgi

# 確認できたら、すぐ削除する（置きっぱなしは情報漏えいのもと）
sudo rm /var/www/html/v_*.php

環境別の対応一覧

まず「誰が PHP 本体を直すのか」を把握するのが出発点です。

環境	PHP 本体を直す人	あなたがやること
レンタルサーバー	レンタルサーバー事業者	確認・バージョン選択・緩和設定
EC2（AL2023）	あなた	修正版の適用・再起動・緩和策
自社サーバー	あなた（または保守会社）	入れ方に合わせて更新
STUDIO	STUDIO	外部とのつなぎ先の確認だけ
ロリポップ + WordPress	ロリポップ	確認・バージョン選択・WordPress の管理

自分で PHP 本体を直す環境（EC2・自社サーバー）では、共通して次の軸で判断します。

EOL 以外（サポート中 8.2〜8.5）／ディストリ対応ブランチ → 指定の修正版へアップデート（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 以上、またはディストリのバックポート）
EOL（7.4 / 8.0 / 8.1） → 公式ソースバックポート（修正パッチ）を当てて再ビルド。それより古い版は LTS ベンダー対応か移行

事業者が直す環境（レンタルサーバー・ロリポップ・STUDIO）では、EOL を意識する必要はほぼなく、管理画面で修正済み（サポート中）のバージョンを選ぶだけです。以降、それぞれの手順を具体的に説明します。

レンタルサーバーの場合

PHP 本体の更新は事業者側が行います。あなたの役割は「確認」と「設定」です。

PHP 本体の更新（修正版への更新／バックポート）は事業者が行うため、あなたは EOL かどうかを意識する必要はほぼありません。やることは「管理画面で修正済み（＝サポート中）のバージョンを選ぶ」ことに集約されます。

公式のお知らせで対応状況を確認します（不明ならサポートへ問い合わせ）。
管理画面で、修正済みの PHP バージョンを選択します。選べるのが EOL 版（8.1 以前）だけの場合は、事業者がバックポート対応しているかを確認し、していなければサポート中バージョンへの切り替えを検討します。
Web 経由で PHP_VERSION を表示して確認します。確認用ファイルはすぐ消します。
緩和設定を入れます。PHP の動かし方によって書く場所が違います。
- CGI / FPM の場合：.user.ini に以下を書く
  .user.ini
```
session.upload_progress.enabled = 0
```
- mod_php の場合：.htaccess に以下を書く
  .htaccess
```
php_flag session.upload_progress.enabled off
```
- 書いた後は 500 エラーが出ないか確認します（.htaccess の設定は構成によっては弾かれ 500 になることがあります）。
改ざんの確認：FTP でダウンロードしたファイルと、手元のリポジトリを比べて差分がないか確認します。

⚠️ 注意：この緩和設定だけでは完全には防げません。最終的には事業者が提供する修正済みバージョンの適用が必須です。

AWS EC2（Amazon Linux 2023）の場合

PHP 本体を直すのはあなた自身です。自社サーバーと同じく、まず使っている PHP が EOL かどうかで方針が分かれます。

EOL 以外（サポート中 8.2〜8.5）／ディストリがサポートするブランチ → dnf upgrade で修正版（またはディストリのバックポート）を適用（＝下記の手順）
EOL（7.4 / 8.0 / 8.1 を Remi やソースで導入し、ディストリが面倒を見ない） → PHP セキュリティチームのソースバックポート（修正パッチ）を当てて再ビルド、または 8.2 以上へ移行

⚠️ ポイントは、AL2023 のようにディストリがバージョン番号を変えずに修正だけを取り込む（バックポート）場合があることです。この場合 dnf で修正が降ってくるので、ディストリがサポートするブランチなら EOL 以外と同じ手順で対応できます。「バージョンが上がっていない＝未修正」とは限りません（判定方法は後述）。

⚠️ 下記コマンドは Linux サーバー上での実行を想定しております。必ずステージング環境やスナップショットで検証してから本番に適用してください。

EOL 以外（サポート中）／ディストリ対応ブランチの手順

ec2_update.sh

# 0. 必要に応じて EBS スナップショット等で切り戻し手段を確保

# 1. 現在の環境を確認
cat /etc/os-release                          # AL2023 であることを確認
php -v                                        # ※ これは CLI 版の表示。Web の版は別途確認（後述）
rpm -qa | grep '^php'                        # インストール済み PHP パッケージ一覧

# 2. 新しい AL2023 リポジトリバージョンを確認
sudo dnf check-release-update

# 3. 対象 releasever で PHP 更新・Security Advisory を確認
sudo dnf check-update --releasever=<releasever> 'php8.⚪︎*'
sudo dnf updateinfo list --releasever=<releasever> --security | grep -i php

# 4. AWS Security Advisory で今回の CVE が修正済みであることを確認
# ※ Pending Fix の段階では「修正済み」と判断しない

# 5. 検証済みの releasever へ更新（PHP だけでなくシステム全体がこの版に上がる）
sudo dnf upgrade --releasever=<releasever>

# 6. 必要なサービスの状態を確認
systemctl status php-fpm
systemctl status httpd

# 必要な場合のみ再起動
sudo systemctl restart php-fpm
sudo systemctl restart httpd

# 7. 適用確認
rpm -q php8.⚪︎ php8.⚪︎-fpm                   # パッケージ版が修正版になっているか（確定的な確認）
php -v                                        # 補助。CLI 版なので Web の版とズレることがある

# 古い実行ファイルを掴んでいないか確認
sudo ls -l /proc/$(pgrep -o php-fpm)/exe     # "(deleted)" が付いていれば古いまま動いている

# OS 再起動の必要性を確認
sudo dnf needs-restarting -r

注意点

2026年10月22日時点では、AWS Security Center上でAL2023のphp8.2〜8.5は「Pending Fix」となっています。AWS側の修正済みRPMが提供されたことを確認してから適用してください。
AL2023 以外を使っている場合はディストリに合わせたコマンドに読み替えてください。
シェルのコメントは # です。// はコメントにならずエラーになります。
dnf upgrade --releasever=<releasever> は PHP だけでなくシステム全体をその release 版に更新します。これは依存ライブラリとの整合を保つための推奨挙動です。PHP だけを更新するとバージョンの組み合わせが崩れることがあります。
--releasever=latest と書くと「その時点の最新」に動いてしまうため、手順 2 で確認した具体的なバージョンにピン留めすると、切り戻しや再現がしやすくなります。
ディストリビューションでは、バージョン番号を変えずに修正だけを取り込む（バックポート）ことがあります。そのため「バージョンが上がっていない＝未修正」とは限りません。

方式	パッケージ名の例
修正版バージョンに更新	`php8.3-8.3.35-1.amzn2023` → `php8.3-8.3.36-1.amzn2023`
バックポート	`php8.3-8.3.35-1.amzn2023` → `php8.3-8.3.35-2.amzn2023`

バックポートかどうか（該当 CVE が修正済みか）は、次で確認します。

check_cve.sh

sudo dnf updateinfo list --security --installed | grep -i php
rpm -q --changelog php8.⚪︎ | head -20   # changelog に CVE 番号が載っていれば修正済み

EOL の PHP を使っている場合

Remi リポジトリやソースビルドで 7.4 / 8.0 / 8.1 などの EOL 版を入れていて dnf で修正が降ってこない場合は、自社サーバーと同じく PHP セキュリティチームのソースバックポートを当てて再ビルドするか、ディストリ／LTS ベンダーのパッチを使います。いずれにせよ当座しのぎなので、8.2 以上への移行を計画してください。

修正版が出るまでの緩和策

/etc/php.d/99-php2shell.ini

session.upload_progress.enabled = 0

書いたら php-fpm（または httpd）を再起動します。あわせて以下も有効です。

セキュリティグループで接続元を絞る。使っていなければインスタンスを停止する。
IAM ロールの権限を最小限にし、IMDSv2 を必須にする（万一侵入されても被害を広げないため）。

更新後、古い PHP のまま動いていないかの確認

check_restart.sh

rpm -qa --last | grep -E '^php' | head       # パッケージの更新日時
ps -o lstart= -p $(pgrep -o php-fpm)         # プロセスの起動日時

プロセスの起動日時がパッケージの更新日時より前なら、まだ古い PHP で動いています。 再起動してください。

自社サーバーの場合

パッチを当てる責任は自社にあります。保守を委託している場合は、OS・ミドルウェアの更新が契約に含まれているかを必ず確認してください（「サーバーを借りている＝全部やってもらえる」とは限りません）。

対応方針は、使っている PHP が EOL（サポート終了）かどうかでまず分かれます。

EOL 以外（サポート中）の場合：指定の修正版へアップデート

8.2 / 8.3 / 8.4 / 8.5 系は、指定の修正版へアップデートするのが基本です（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 以上）。具体的な当て方は、PHP の入れ方で変わります。

入れ方	当て方
OS のパッケージ（dnf / yum / apt）	ディストリビューションの修正版に更新
ソースからビルド	php.net の修正版ソースでビルドし直す
cPanel / Plesk	パネルの更新機能で更新
Docker	修正版のイメージで作り直してデプロイ

EOL の場合：修正パッチを当てる

サポートが終了した PHP 7.4 / 8.0 / 8.1 には通常の修正版リリースはありませんが、PHP セキュリティチームが最小限のソースバックポート（修正パッチ）を公開しています。ソースビルド環境ではこのパッチを当てて再ビルドします。

7.4 / 8.0 / 8.1 より古い 5.x / 7.0〜7.3 には公式パッチがありません。この場合は、ディストリ／LTS ベンダー（TuxCare など）が提供するパッチを使うか、サポート中バージョンへ移行します。
EOL 版を使い続けること自体がリスクなので、パッチで当座をしのぎつつ、8.2 以上への移行を計画してください。すぐ上げられない間は後述の緩和策で時間を稼ぎます。

これをキッカケに決めておきたい 3 点

次回以降の対応を速くするため、普段から次を整理しておきます。

どのサーバーで、どの PHP が、どう入っているかの一覧
誰が、どの手順で更新するか
脆弱性情報を誰がどこで見張るか

STUDIO の場合

PHP 本体についてやることはありません（STUDIO が PHP を使っているかどうかも公開されていません）。基盤のセキュリティはサービス側の責任なので、EOL かどうかを気にする必要もありません。
ただし、フォームの送信先や埋め込みなど、外部のサーバー・サービスにつないでいる先は確認してください。つなぎ先のサーバーは自分たちの責任です（例：自前で立てたフォーム受信 API が PHP 製なら、それは対象）。
アカウントに 2 段階認証を設定し、編集権限を持つメンバーを最小限にします。

ロリポップ + WordPress の場合

PHP 本体の更新はロリポップ側が行うため、レンタルサーバーと同じく EOL を意識する必要はほぼありません。あなたは「修正済み（サポート中）バージョンの選択」と「WordPress の点検」を担当します。

ロリポップの公式のお知らせで対応状況を確認します。
ユーザー専用ページで、修正済みの PHP バージョンを選択します。EOL 版（8.1 以前）しか選べない場合は、バックポート対応の有無を確認し、サポート中バージョンへの切り替えを検討します。
WordPress 管理画面 → ツール → サイトヘルス → 情報 → サーバーで、実際に動いている PHP のバージョンを確認します。
侵入されていないか確認します。
- 見覚えのない管理者ユーザーがいないか
- wp-content/uploads/ の中に .php ファイルがないか（本来ここは画像などの置き場。.php があれば Web シェルの可能性が高い）
- 見覚えのないプラグインがないか、ページが改ざんされていないか
普段からの守り
- WordPress 本体・プラグイン・テーマを最新に保ち、使っていないものは削除する
- WAF を有効にする（今回の脆弱性を確実に防げるとは限らないので、あくまで補助）
- バックアップを取る

緩和策の「限界」を正しく理解する

今回いちばん誤解されやすいのがここです。

session.upload_progress.enabled = 0 は、CVE-2026-109619 の「セッションアップロード経由という攻撃経路の 1 つ」を塞ぐだけです。PHP 公式は「他の攻撃バリアントは防げない」と明言しています。
CVE-2026-109618（OOM 側）には、別の緩和が案内されています。
- memory_limit = -1 をアプリから上書きできない形で設定する
- 低い post_max_size を設定する
- Web サーバー／プロキシ側で、リクエストサイズ・multipart のパート数・ヘッダ・ネストの上限を設ける

つまり「session.upload_progress を切ったから大丈夫」ではありません。これらはすべて時間稼ぎであり、唯一の根本対策は修正版 PHP へのアップデートです。

侵入されていないかの確認

見覚えのない .php ファイルがないか（特にアップロードディレクトリ）。
エラーログで Segmentation fault やメモリ枯渇が急に増えていないか。これらは攻撃の試行に伴って発生しやすい兆候です。
少しでも怪しければ、パスワード・API キー・DB 認証情報などを変更します。侵入後に認証情報が盗まれている前提で動くのが安全です。

まとめ

php2shell（CVE-2026-109618 / CVE-2026-109619）は、認証なし RCE につながる CVSS 9.2（Critical） の PHP 本体脆弱性。PHP 5.4〜8 系の広い範囲が対象で、Apache + mod_php は特に危険。
根本対策は修正版への更新：8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以上。8.1 以前は 8.2 以上へ移行する。
バージョンは Web 経由で確認し、更新後は必ず再起動。php -v の CLI 版表示だけで判断しない。
緩和策は時間稼ぎにすぎず、session.upload_progress を切っても全攻撃は防げない。
環境ごとに「誰が直すか」が違う。レンタルサーバー / ロリポップ / STUDIO は事業者側、EC2 / 自社サーバーは自分側。
更新と並行して侵入痕跡の確認も行う。怪しければ認証情報を変更する。

本記事は 2026 年 10 月 22 日時点の公開情報に基づく解説です。状況は刻々と更新されています。実際の対応にあたっては、PHP 公式および利用中の各サービスの最新の公式情報を必ず確認してください。