PHP2Shell は PHP 本体にある認証前 RCE です。PHP を更新し、再起動してください。
PHP エンジンの 2 つのメモリ安全性のバグ（CVE-2026-109618、CVE-2026-109619）により、認証されていない攻撃者がコードを実行したり、サーバーのメモリ（パスワード、API キー、セッショントークン）を読み取ったりできます。上で動くアプリケーションに関係なく、5.4 以降のほぼすべての PHP バージョンが影響を受けます。
技術者ではない方は、PHP2Shell のやさしい解説 をご覧ください——あなたのサイトや利用中の SaaS にとって何を意味するかを説明しています。
最終確認 2026-10-22 · 独立・ベンダー中立
バージョン、php -v の出力、またはサーバー群のバージョンを 1 行に 1 つずつ貼り付けてください。処理はすべてブラウザ内で行われます。
CLI と Web サーバーは別の PHP ビルドを使っていることがあります。Web サーバーが実際に使っているバージョンを確認してください：php-fpm -v（または php-fpm8.3 -v）、もしくは対象サイトで phpinfo() を表示。
| ブランチ | 脆弱 | 修正版 |
|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 |
| 8.4 | < 8.4.27 | 8.4.27 |
| 8.3 | < 8.3.36 | 8.3.36 |
| 8.2 | < 8.2.35 | 8.2.35 |
| 8.1 · 8.0 · 7.4 | すべて | ソースのバックポートのみ |
| 5.4 – 7.3 | すべて | 修正なし |
PHP 8.2 は 2026-12-31 にセキュリティサポート終了
8.2.35 に更新すれば PHP2Shell は修正されますが、2026 年末までにもう一度移行が必要です。どうせ移行するなら 8.4 か 8.5 を目指しましょう。
今すぐやること
この順番で。これ以外に完全な修正はありません。
- 01
すべての PHP 実行環境を洗い出す
Web サーバー、コンテナ、ベースイメージ、共有ホスティング、ステージング。CLI のバージョンは PHP-FPM や Apache が使っているものと違うことがあります。
手順 - 02
修正版をインストールする
8.5.12 · 8.4.27 · 8.3.36 · 8.2.35、またはディストリの修正済みパッケージ。WordPress／Drupal／Laravel を更新しても PHP は更新されません。
手順 - 03
PHP を動かすものをすべて再起動する
PHP-FPM プール、Apache（mod_php）、FrankenPHP、キューワーカー、Octane／RoadRunner／Swoole。古いプロセスは古いコードをメモリに保持し続けます。
手順 - 04
確認し、さかのぼって調べる
Web サーバーが報告するバージョンを確認します。2026 年 10 月初旬以降のログを確認し、不審な点があれば認証情報を入れ替えてください。
手順
今日は更新できない？ 暫定対策 で既知の攻撃経路へのリスクを下げられます。共有ホスティングの場合は ホスティング会社向けガイド を参照してください。
環境別ガイド
- WordPressWordPress サイトは PHP2Shell の影響を受けるか。サイトヘルスで PHP バージョンを確認する方法、プラグイン更新では解決しない理由、ホスティング会社への問い合わせ文面。
- DrupalDrupal サイトは PHP2Shell の影響を受けるか。ステータスレポートや Drush で PHP バージョンを確認する方法、Drupal の更新では解決しない理由、ホスティング会社への確認事項。
- JoomlaJoomla サイトは PHP2Shell の影響を受けるか。システム情報で PHP を確認する方法、Joomla の更新では解決しない理由、ホスティング会社への確認事項。
- ホスティング会社共有ホスティングやマネージドホスティングでは PHP を自分で更新できません。cPanel や Plesk などでの PHP バージョンの確認・切り替え方法、各社の公表内容、問い合わせるべきこと。
- Cloudflare WAFFree／有料プラン向けの Cloudflare PHP2Shell WAF ルール ID、ルールが有効でブロックしているかの確認方法、そして Cloudflare の背後でも PHP の更新が必要な理由。
- session.upload_progresssession.upload_progress の無効化が PHP2Shell を部分的にしか防げない理由、確実に効く設定場所（.user.ini や ini_set では不可）、確認方法、再起動すべきもの。
悪用されているか？
2026-10-22 時点の状況です。情報は錯綜しています。能力のある攻撃者はすでに動作するエクスプロイトを持っていると考えてください。
- Cloudflare（CTO Dane Knecht）：「We are seeing early attacks emerging and are updating mitigations as new vectors show up.」（初期の攻撃が出始めており、新たな攻撃経路が現れるたびに対策を更新している）
- watchTowr は、10 月 21 日時点でハニーポット網により実環境での悪用を観測したとしています。
- オランダ NCSC は当時悪用を確認しておらず、インターネットに公開されたすべての PHP システムを、パッチ適用までは脆弱とみなしています。
- 侵害の成功が確認された公開事例はなく、どちらの CVE も CISA の KEV カタログには掲載されていませんでした。
- GitHub には「PoC」を名乗るリポジトリが複数出回っています。Tenable はどれも動作を確認できていません——信頼できない、悪意がある可能性のあるコードとして扱ってください。
どのサーバー構成が影響を受けるか
最も明確に悪用できるのは mod_php ですが、Web リクエストを処理するすべての SAPI にパッチが必要です。
| 構成 | …109618 | …109619 | 補足 |
|---|---|---|---|
| Apache + mod_php | RCE 確認済み | RCE 確認済み | 両 CVE ともデフォルト制限で RCE まで確認済み。最もリスクの高い構成です。 |
| PHP-FPM（nginx、Apache、Caddy など） | 影響あり | RCE 確認済み | セッションのライフサイクル経由の RCE が FPM で確認済み。OOM 経路はアプリケーション層のコードパス経由で確認されていますが、汎用的な FPM 向けエクスプロイトは公開されていません。 |
| FrankenPHP / LiteSpeed LSAPI | 影響の可能性大 | 影響の可能性大 | アドバイザリでは影響の可能性が高いとされています。常駐ワーカーでは、リクエストをまたいだ残留状態の問題がむしろ大きくなります。 |
| CLI（cron、キューワーカー、artisan） | 対象外 | 対象外 | アドバイザリでは扱われておらず、通常の使い方では HTTP リクエストから到達できません。ただし同じパッケージなので、いずれにせよ更新してください。 |
自分のタイムゾーンでは何時にパッチが出た？
PHP は 2026 年 10 月 21 日（火）14:00 UTC、日本時間 23:00 に修正版を公開しました。この日、米国と欧州はまだ夏時間だったため、「EST」は実際には EDT（UTC−4）を指します。
| タイムゾーン | パッチ公開時刻 | 日付 |
|---|---|---|
| UTC | 14:00 | 2026 年 10 月 21 日（火） |
| 米国太平洋時間（PDT、UTC−7） | 07:00 | 10 月 21 日 |
| 米国中部時間（CDT、UTC−5） | 09:00 | 10 月 21 日 |
| 米国東部時間（EDT、UTC−4） | 10:00 | 10 月 21 日——「EST」で検索した場合はこちら |
| 英国（BST、UTC+1） | 15:00 | 10 月 21 日 |
| 中央ヨーロッパ夏時間（CEST、UTC+2） | 16:00 | 10 月 21 日——オランダ、ベルギー、ルクセンブルク、ドイツ、オーストリア、フランスなど |
| インド（IST、UTC+5:30） | 19:30 | 10 月 21 日 |
| 中国／香港／シンガポール（UTC+8） | 22:00 | 10 月 21 日 |
| 日本（JST、UTC+9） | 23:00 | 10 月 21 日 |
| シドニー（AEDT、UTC+11） | 01:00 | 10 月 22 日 |
攻撃者にできること
ログインせずにコードを実行
PHP ワーカーユーザー（例：www-data）としてコードを実行：Web シェルの設置、データ窃取、改ざん、横展開。
他のリクエストのメモリを読む
ワーカーのメモリには DB パスワード、API キー、セッション Cookie、TLS の鍵情報、他のユーザーのフォーム入力が含まれている可能性があります。
気づかれずにデータを持ち出す
メモリ漏えいの経路はコード実行を必要としないため、不審なプロセスを監視するツールは反応しないかもしれません。
よくある勘違い
安全ではないのに安全だと思い込んでしまう典型例です。
| こう思っていたら…… | 実際は |
|---|---|
| 「WordPress／プラグインは更新した」 | バグは PHP インタープリタにあります。アプリケーションの更新では直りません。脆弱な PHP 上なら、単純な「Hello World」スクリプトでも影響を受けます。 |
| 「session.upload_progress.enabled = 0 にした」 | それで防げるのは一方の CVE の確認済み経路の一部だけで、CVE-2026-109618 には効果がありません。PHP の開発者自身が、唯一の対策はアップグレードだと述べています。 |
| 「apt upgrade したから大丈夫」 | 実行中の PHP-FPM／Apache プロセスは、再起動するまで古いバイナリをメモリに保持しています。 |
| 「php -v では修正済みと出ている」 | それは CLI です。Web サーバーは別のパッケージ、コンテナ、バージョンを使っているかもしれません。php-fpm -v か phpinfo() で確認してください。 |
| 「Cloudflare／WAF の後ろにいる」 | WAF ルールは既知のペイロードのリスクを下げますが、攻撃者はすでにそれを変形させており、オリジンに直接アクセスできることも多いです。時間稼ぎにはなりますが、修正ではありません。 |
| 「バージョンが古く見えるから脆弱だ」 | そうとは限りません。Debian、Ubuntu、RHEL は上流の番号を変えずに修正をバックポートします。パッケージの changelog を確認してください。 |
2 つの CVE の概要
メモリ枯渇（OOM）時の破損による RCE
認証なしで、PHP の Web ワーカーユーザーとしてコードを実行できます。
実証： WordPress、Drupal、Joomla（mod_php、デフォルト制限）で認証前 RCE を実証。
リクエストをまたいで残るグローバル状態による RCE
use-after-free により、ワーカーのメモリ漏えいやコード実行につながります。
実証： WordPress と Drupal で認証前 RCE を実証。アプリケーションに依存しないリモートのメモリ漏えいも実証。
一部のサイトが 10.0 としている理由：CVSS 9.2 vs 10.0 →
経緯
- 2026-10-20 15:00 UTCCVE 番号がフォーラムや SNS で出回り始める。誤った CVSS 10.0 が付いていた。
- 2026-10-20 19:30 UTCPHP が予告を前倒しで公開。
- 2026-10-20 ~20:00 UTCCalif が誤って PoC の動画を公開。
- 2026-10-20 23:00 UTC暫定対策の情報が一部の重要インフラ事業者に送られ、外部に漏れた可能性がある。
- 2026-10-21 03:02 UTCCloudflare の WAF ルールが Free を含む全プランで有効に。
- 2026-10-21 07:41 UTCChainguard が修正済みイメージを公開し、エンバーゴを 6 時間以上破る。
- 2026-10-21 11:51 UTCBambooHR が予防措置としてサービスを停止（米国、カナダ、アイルランド）。
- 2026-10-21 (CEST)DigiD や MijnOverheid を含むオランダの政府・教育機関のサイトが予防措置として停止。
- 2026-10-21 14:00 UTC協調公開：PHP 8.5.12、8.4.27、8.3.36、8.2.35 と、7.4、8.0、8.1 向けのソースバックポート。当初は 10 月 22 日の予定だった。
- 2026-10-21 15:03 UTCBambooHR が修正を適用し、テスト中と報告。
2024 年の監査からの全タイムライン → · 2021 年の Java のバグとの比較：PHP2Shell vs Log4Shell →