先に要点
- PHP2Shell は、2026年10月21日に修正が公開された PHP 本体の2つの重大な脆弱性（CVE-2026-109618・CVE-2026-109619）の呼び名です。認証なしでリモートからコードを実行されるおそれがあります（CVSS v4.0 で 9.2）。
- 影響を受けるのは Web のリクエストを処理している PHP（PHP-FPM・Apache の mod_php・php-cgi・FrankenPHP・LiteSpeed）。mod_php では、アプリのコードが動く前に攻撃できることが確認されています。
- 修正版は 8.5.12・8.4.27・8.3.36・8.2.35。8.1 以前は公式の新しいリリースが出ていません（ソースの修正だけが公開）。
- やることは「修正版に上げて、すべてのワーカーを再起動」。設定での回避策は一部の経路しか防げません。公表前から悪用の試みが報告されているので、痕跡の確認もあわせて行います。
PHP2Shell（ピーエイチピー・ツー・シェル）は、PHP の処理系そのものに見つかった2つの脆弱性をまとめた呼び名です。WordPress や Laravel などのアプリではなく PHP 本体 の問題なので、アプリをいくら更新しても直りません。直す場所は、サーバーに入っている PHP です。
この記事では、PHP の公式発表と GitHub のセキュリティ情報（2026年10月24日に確認）をもとに、自分のサーバーが影響を受けるかの確かめ方、更新の順番、すぐに更新できないときの暫定策とその限界、攻撃されていないかの確かめ方を整理します。
PHP2Shell とは：2つの脆弱性の中身
PHP の開発チームは2026年10月21日に、2つの脆弱性を修正したセキュリティリリースを公開しました。どちらも、細工した HTTP リクエストを送るだけで、ログインせずに PHP のワーカーの権限でコードを実行される危険があります。
PHP2Shell を構成する2つの脆弱性
2つは組み合わせて使われることがあり、公式の対策も「両方の修正を当てる」ことが前提です。発見者には、クラウドセキュリティ企業の Wiz の研究者などが挙がっています。
| 項目 | 内容 |
|---|---|
| 呼び名 | PHP2Shell |
| CVE | CVE-2026-109618（メモリ不足時の破損）、CVE-2026-109619（前のリクエストの状態が残る） |
| 深刻度 | どちらも CVSS v4.0 で 9.2（Critical） |
| 認証 | 不要（ネットワーク越しに、利用者の操作なしで成立しうる） |
| 修正の公開 | 2026年10月21日 |
影響を受けるのは「Web のリクエストを処理している PHP」
公式の発表は、影響の範囲を「Web のリクエストを処理しているすべての PHP」としています。サーバーで PHP がどの形で動いているか（SAPI と呼ばれます）によって、確認されている危険の度合いが違います。
| 動かし方 | 公式の評価（2026年10月24日時点） |
|---|---|
| Apache の mod_php | 最も危険。アプリのコードが動く前に、認証なしで攻撃できることが実証されている |
| PHP-FPM（nginx などと組み合わせる形） | CVE-2026-109619 は実証済み。CVE-2026-109618 はソースの解析上は影響あり |
| php-cgi・FrankenPHP・LiteSpeed（LSAPI） | 影響を受けるとされている（一部は未検証） |
| コマンドラインだけで動かす PHP（バッチ・cron など） | 公式の対象は「Web のリクエストを処理する PHP」。ただし同じサーバーで Web 用の PHP も動いているなら、そちらが対象になる |
WordPress・Laravel・EC-CUBE などのアプリやプラグインを最新にしても、この脆弱性は残ります。直すのはサーバーに入っている PHP 本体です。レンタルサーバーなら、事業者が PHP を更新したかを確認します。
修正版と、サポートが終わった版の扱い
修正版は、まだ公式のサポートが続いている4つの系列に出ています。
| 系列 | 修正版 | 補足 |
|---|---|---|
| PHP 8.5 | 8.5.12 | |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | 8.2 は 2026年12月31日でサポート終了 |
| PHP 8.1・8.0・7.4 | 公式の新しいリリースは無し | PHP の開発チームが、最小限の修正をソースのブランチとして公開。Linux の配布元や長期サポートの事業者が独自に修正版を出す場合がある |
サポートが終わった版にも修正が用意されたのは異例ですが、番号付きのリリースではなくソースの修正だけです。自分でビルドするか、配布元・事業者の修正版を待つことになります。古い版のまま運用している場合は、これを機に サポートが続いている版へ移る 計画を立てるのが現実的です。サポート期限の読み方は EOLとLTSの違い で整理しています。
自分のサーバーの版を確かめる
注意したいのは、コマンドラインの PHP と、Web で動いている PHP の版が違うことがある点です。php -v が修正版でも、Web 側が古いままなら意味がありません。
版の確かめ方（上から順に）
- 1Web で動いている PHP の種類を知る
Apache の mod_php か、PHP-FPM か、レンタルサーバーの管理画面で選ぶ形か。わからなければサーバーの担当者や事業者に確認する。
- 2PHP-FPM ならその実行ファイルの版を見る
php-fpm8.4 -v や php-fpm -v のように、FPM 側のコマンドで版を確かめる。複数の版が入っているサーバーでは、実際にサイトが使っている版を確認する。
- 3パッケージで入れたなら、更新が届いているかを見る
Debian・Ubuntu なら apt list --installed、RHEL 系なら dnf list installed で、PHP のパッケージの版を確かめる。配布元は修正を独自の版番号で出すことがあるので、配布元のセキュリティ情報もあわせて見る。
- 4レンタルサーバーは管理画面と事業者のお知らせを見る
PHP の版の設定画面と、事業者のお知らせ（PHP2Shell・CVE-2026-109618 への対応）を確認する。
- 5
コマンドの例です。表示される版番号が、上の表の修正版以上になっているかを見ます。
# コマンドラインの PHP（Web 側と違うことがある）
php -v
# PHP-FPM の版（名前は環境によって php-fpm8.4 などになる）
php-fpm8.4 -v
# Debian・Ubuntu でパッケージの版を見る
apt list --installed 2>/dev/null | grep -i php
Web 側の版を確かめるために phpinfo を表示するファイルを置く方法もありますが、サーバーの情報が丸見えになります。使うなら推測されにくい名前にし、確認したらすぐに削除してください。
今すぐやる対策：更新と、全ワーカーの再起動
公式の結論ははっきりしていて、修正版に更新することだけが完全な対策です。そのうえで、更新しただけで古いプロセスが残っていると意味がないので、すべてのワーカーを再起動します。
- 1
修正版に更新する
8.5.12・8.4.27・8.3.36・8.2.35 以上。8.1 以前は配布元・事業者の修正版か、サポート中の版への移行。
- 2
すべてのワーカーを再起動する
PHP-FPM のサービス、Apache（mod_php）を再起動し、古いプロセスが残っていないことを確かめる。
- 3
更新できないときだけ暫定策を入れる
下の表の設定は一部の攻撃の経路しか防げない。更新までのつなぎとして使う。
- 4
痕跡を確かめる
公表より前から悪用の試みが報告されている。更新の前後にかかわらず、ログとファイルを確認する。
すぐに更新できない場合の暫定策は、公式の発表に次のものが挙がっています。どれも完全な対策ではありません。
| 暫定策 | 何を防ぐか | 注意 |
|---|---|---|
session.upload_progress.enabled=0 にして全ワーカーを再起動 |
CVE-2026-109619 の確認済みの経路（セッションのアップロード進捗） | php.ini・FPM のプール設定・サーバー設定で入れる。ini_set() や FPM の .user.ini では効かない。機能が不要なら、修正後も切ったままでよいとされている |
memory_limit=-1（php_admin_value で固定） |
CVE-2026-109618 のメモリ不足の経路を起きにくくする | 完全な対策ではない。代わりにコンテナや cgroup でメモリの上限をかける |
post_max_size を小さくする |
大きなリクエストによるメモリ不足を起きにくくする | アップロードが無いなら 8M、あるなら 32M 程度（upload_max_filesize はそれより小さく） |
RLIMIT_AS・RLIMIT_DATA での制限をやめる |
弱点の経路を通りにくくする | プロセスのメモリ制限は、これらではなくコンテナや cgroup でかける |
| 使っていないなら、マルチパートの POST を手前で止める | メモリ不足を起こす入力の入口を絞る | ファイルのアップロード機能があるサイトでは使えない |
PHP 8.5 なら fatal_error_backtraces=0 |
確認済みの1つの経路 | 8.5 だけの設定 |
共用のレンタルサーバーでは、利用者が変えられる設定が .user.ini などに限られることが多いですが、公式は「FPM の .user.ini に頼らないこと」としています。事業者が PHP 本体を更新したかを確かめ、未対応なら問い合わせるのが確実です。
WAF（Web アプリケーションファイアウォール）の事業者も検知のルールを出していますが、公式の立場はあくまで「更新が唯一の完全な対策」です。WAF は更新までの時間を稼ぐものと考えます。
攻撃されていないかを確かめる
Amazon の脅威インテリジェンスは、公表の4日前（2026年10月17日）に PHP2Shell を狙った悪用の試みを観測したと公表し、少なくとも10月17日以降を調査の対象にするよう呼びかけています。公表の数時間後には攻撃用のコードも出回りました。修正版にした後でも、それまでに侵入されていないかは別に確かめる必要があります。
具体的な攻撃の痕跡（ログに残る特徴など）は、セキュリティ機関や事業者から順に公開されている段階です。ここでは、Web サーバーが乗っ取られたときに一般的に確かめる場所を挙げます。
エラーログ
ワーカーの異常終了とメモリ不足
PHP-FPM のワーカーが signal 11 などで落ちた記録や、メモリ不足のエラーが、10月中旬以降に急に増えていないか。
アクセスログ
見慣れない大きな POST
普段は使われない URL への、大きなマルチパートの POST が繰り返されていないか。同じ送信元からの連続にも注意する。
ファイル
覚えのない PHP ファイル
公開ディレクトリや一時ディレクトリに、最近作られた・書き換えられたファイルが無いか。
プロセス・通信
見慣れない処理と外向きの通信
Web の実行ユーザーで動く不審なプロセスや cron、外部への見慣れない接続が無いか。
ファイルの確認は、たとえば次のように「ある日付より後に変わった PHP ファイル」を探すところから始めます。パスはサイトの置き場所に合わせて変えます。
# 2026-10-15 より後に作成・変更された PHP ファイルを探す
find /var/www -type f -name "*.php" -newermt "2026-10-15" -ls
ファイルを消して終わりにせず、まずログとファイルを保存し、サーバーをネットワークから切り離すか公開を止めます。そのうえで、データベースや外部サービスのパスワード・API キーを変更し、レンタルサーバーなら事業者に連絡します。侵入されたサーバーは、作り直す前提で考えるのが安全です。
PHP2Shell についてよくある質問
Q. WordPress やプラグインを更新すれば大丈夫ですか？
A. いいえ。PHP 本体の脆弱性なので、アプリやプラグインの更新では直りません。サーバーの PHP を修正版に更新する必要があります。
Q. PHP 7.4 や 8.1 のままです。どうすればいいですか？
A. 公式の新しいリリースは出ていません。PHP の開発チームが公開したソースの修正を使ってビルドするか、Linux の配布元・長期サポートの事業者の修正版を使うか、サポート中の版（8.2 以上）へ移ります。8.2 も 2026年12月31日でサポートが終わるので、移るなら 8.3 以上を選ぶと次の移行までの時間を取れます。
Q. WAF を入れていれば更新しなくてもいいですか？
A. 公式は、更新だけが完全な対策だとしています。WAF のルールは攻撃の一部を止められても、すべての経路を防げる保証はありません。
Q. 修正版にした後も session.upload_progress は切ったままにすべきですか？
A. 公式の情報では、この機能を使っていないなら修正後も無効のままにしておくことが勧められています。アップロードの進捗表示に使っている場合だけ、有効に戻します。
まとめ
- PHP2Shell は PHP 本体の2つの重大な脆弱性で、認証なしでコードを実行されるおそれがある
- 影響を受けるのは Web のリクエストを処理している PHP。アプリの更新では直らない
- 修正版は 8.5.12・8.4.27・8.3.36・8.2.35。更新したらすべてのワーカーを再起動する
- 8.1 以前は配布元・事業者の修正版か、サポート中の版への移行
- 設定の暫定策は一部の経路しか防げない。公表前から悪用の試みがあるので、痕跡の確認もあわせて行う
この記事は2026年10月24日時点の公式情報で書いています。修正の追加や新しい情報が出ることがあるので、対応の前に下の一次情報も確認してください。
参考リンク
- PHP 公式：セキュリティリリースのお知らせ（2026年10月21日）
- PHP 公式：ダウンロード
- PHP 公式：サポートされている版の一覧
- GitHub：GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
- GitHub：GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
- GitHub：サポート終了版向けのソースの修正（7.4・8.0・8.1）
- AWS セキュリティブログ：Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure
- ITmedia NEWS：PHP2Shell、公表4日前に悪用の試み 「公表日より前にさかのぼって調査を」とAmazon