2026年10月21日、PHPの開発チームが、認証なしで外部からプログラムを実行されるおそれのある重大な脆弱性2件（CVE-2026-109618、CVE-2026-109619）を公表し、修正版のPHP 8.5.12・8.4.27・8.3.36・8.2.35を公開しました。2件を組み合わせた攻撃は「PHP2shell」と呼ばれています。対処の基本は、PHPを修正版に更新することで、設定による緩和策は一部の攻撃経路をふさぐだけです。WordPressなどのアプリケーションやプラグインを更新しても、この脆弱性そのものは直りません。この記事では、PHPの脆弱性の中身、起こりうる被害、影響を受けるバージョン、サイト運営者が取るべき対処を、公式のアドバイザリをもとに整理します。
この記事の目次
PHP2shellは「PHP本体」の脆弱性で、CVSS 9.2の2件
PHPのセキュリティチームは、10月20日に「重大なセキュリティリリースを21日14:00（UTC）に出す」と予告し、21日に修正版を公開しました。日本では、IPAが21日に事前準備を呼びかけ、22日にIPA・JPCERT/CCが注意喚起を出しています。ヘテムルの告知によると、公開は予定より早い日本時間の21日22時30分過ぎでした。
2件とも、PHPのGitHub上のアドバイザリで深刻度は「Critical」、CVSS v4.0のスコアは9.2です。
| CVE番号 | 公式の名称 | 原因 |
|---|---|---|
| CVE-2026-109618 | RCE via OOM corruption | メモリ不足（OOM）の処理で、初期化の途中のリクエストのデータを、後片付けの処理が正しいデータとして扱ってしまう |
| CVE-2026-109619 | RCE via stale global state | リクエストの内部状態が、メモリを解放したあとも残り、同じワーカーが次に処理するリクエストがその古い状態を使ってしまう（解放後のメモリの使用） |
どちらも、WordPressやLaravelのようなアプリケーションの不具合ではなく、PHPという実行環境そのもののメモリの扱いに原因があります。発見に関わったWiz社は、PHP 5.4以降のどのバージョンも、2件のうち少なくとも1件の影響を受けると説明しています。
なぜ「アプリの前」で攻撃が成立するのか
PHPの公式発表は、Apacheのmod_phpで動かしている環境のリスクが最も高いとし、「アプリケーションのコードが動く前に、認証なしのリクエスト1つで攻撃を起こせる」実証があると書いています。ログイン画面やフォームを持たない、ほぼ静的なサイトでも、PHPがリクエストを受け付けている限り対象になる、という意味です。アプリケーション側のログには痕跡がほとんど残らない、とWiz社も注意しています。
2件目（CVE-2026-109619）は、攻撃の準備をするリクエストと、それを使うリクエストが同じワーカープロセスに届く必要がある、などの条件があり、アドバイザリの攻撃の難しさは「高（AC:H）」です。ただし、条件が厳しいことと、狙われないことは別の話です。
悪用されると何が起こるのか
JPCERT/CCは、悪用された場合「PHPの実行プロセスの権限で任意のコードを実行される可能性がある」としています。Webサイトの運営者の立場で言いかえると、次のような被害につながります。
- サイトの改ざん（不正なページやリダイレクト、偽の広告・フィッシングページの設置）
- バックドア（Webシェル）を置かれ、修正版に更新したあとも出入りされ続ける
- wp-config.phpなどに書かれたデータベースの接続情報の窃取と、会員情報・問い合わせ内容などの持ち出し
- 同じサーバー上の別のサイトやファイルへの被害の拡大
- ほかのリクエストのデータの漏えいや、サービスの停止（Vercelの解説より）
注意したいのは、公表の前から攻撃が始まっていたことです。Amazonの脅威インテリジェンスは、公表の4日前の10月17日に、おとりのサーバー（ハニーポット）でPHP2shellを狙った攻撃を観測したと報告しています。Vercelも、実際に動く攻撃コードがすでに公開され、各所で攻撃の試みが報告されていると伝えています。
影響を受けるバージョンと修正版
修正版より前のサポート中のバージョンはすべて対象です。アドバイザリが挙げる実行環境は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedで、Webのリクエストを受けるPHPは方式を問わず影響を受けます。
| 系列 | 影響を受けるバージョン | 修正版 |
|---|---|---|
| PHP 8.5 | 8.5.12より前 | 8.5.12 |
| PHP 8.4 | 8.4.27より前 | 8.4.27 |
| PHP 8.3 | 8.3.36より前 | 8.3.36 |
| PHP 8.2 | 8.2.35より前 | 8.2.35 |
| PHP 8.1以前 | 影響あり（公式の修正版は無し） | サポート中の系列へ移行 |
PHP 8.1以前は公式の更新が終わっています。今回は深刻さを考えて、PHP 7.4・8.0・8.1向けに最小限の修正（ソースコード）が別に用意されましたが、自分でPHPをビルドする人向けのものです。また、PHP 8.2は2026年12月31日でサポートが終わると、8.2.35の告知に書かれています。今回8.2に上げて済ませるより、8.3以降に移る計画を立てておくほうが、次の脆弱性で慌てずに済みます。
Linuxディストリビューションや長期サポートの提供元には、事前に修正が渡されています。OSのパッケージでPHPを入れている場合は、バージョン番号が修正版と違っていても修正が取り込まれていることがあるので、提供元のセキュリティ情報で確認してください。
サイト運営者がやること：まずPHPを修正版に上げる
レンタルサーバーを使っている場合
共用のレンタルサーバーでは、PHPの更新はサーバー会社が行います。まずは利用中のサーバー会社の障害・メンテナンス情報を開き、修正が済んだか、利用者に何を求めているかを確かめましょう。たとえばヘテムルは、10月22日の11時24分ごろに修正を当ててサイトの表示を再開し、利用者には「サポートが続いているPHP 8.2以降への切り替え」と、WordPressのプラグイン・テーマの確認を求めています。サーバーを選ぶ段階の話は「ドメインとサーバーを準備しよう【ホームページ制作入門 第3回】」でも触れています。
コントロールパネルでドメインごとにPHPのバージョンを選べるサーバーでは、古い系列（8.1以前）を選んだままのサイトが残っていないかを確認します。複数のサイトを持っている人ほど、昔作ったサイトが古いまま残りがちです。
VPS・自社サーバーを使っている場合
- PHPが動いているサーバーを洗い出す（インターネットに公開しているものから優先）
- 修正版、または提供元の修正済みパッケージに更新する
- PHP-FPMやApacheを再起動し、実際にリクエストを処理しているPHPが新しくなったかを確かめる（コマンドラインの
php -vと、Webサーバーが使うPHPが違うことがある） - コンテナで動かしている場合は、新しいPHPのベースイメージで作り直してデプロイする
WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」の「サーバー」で、実際に動いているPHPのバージョンを確認できます。確認のために phpinfo() を書いたファイルを公開ディレクトリに置くのは、消し忘れると情報漏えいになるので避けましょう。
すぐ更新できないときの緩和策
PHPの公式発表は、緩和策について「特定の攻撃経路への露出を減らすが、安全にはしない」と明記しています。更新までのつなぎとして考えてください。主なものは次のとおりです。
session.upload_progress.enabled=0：php.iniやFPMのプール設定など、リクエストの解析より前に効く場所で設定し、全ワーカーを再起動する。ini_set()や FPM の.user.iniでは効かないfatal_error_backtraces=0（PHP 8.5のみ）：確認された攻撃経路の1つをふさぐmemory_limit=-1をアプリから変えられない形で設定する、post_max_sizeを小さくする（アップロード不要なら8M、必要なら32M）- Webサーバーやプロキシで、リクエストの大きさ・入力項目の数・multipartの部品の数などを制限する
なお、PHPは10月23日に、upload progressの機能に関わる別の小さな問題（CVE-2026-115560）についても、次の定例リリースまで session.upload_progress.enabled=0 を勧める追加の告知を出しました。起こる条件はかなり特殊ですが、すでにこの設定を入れている場合は、そのままにしておけば対応は不要とされています。ヘテムルも、今回の対策で全バージョンのupload progressを無効にしたと告知しています。
Cloudflare・AWS WAF・Vercelなども既知の攻撃パターンを止めるWAFのルールを出していますが、AWSは「更新までのつなぎ」、Vercelは「更新の代わりにはならない」と位置づけています。
攻撃されたかを確かめる手がかり
更新しても、更新前に入り込まれていれば被害は続きます。英国のNCSCは、更新や緩和の前に侵害の痕跡を確認するよう求めています。JPCERT/CCとWiz社が挙げている確認ポイントに、一般的な改ざんの確認を足すと、次のようになります。
- アクセスログに、不審な multipart/form-data のPOSTリクエストがないか。その前後に、メモリ上限のエラーやHTTP 500が続いていないか
- HTTPレスポンスに、不自然に長い・形のおかしい PHPSESSID のCookieが出ていないか
- PHPのワーカーが、予期せず落ちたり、頻繁に再起動したりしていないか
- 見覚えのない .php ファイル（特に画像を置くアップロード用のフォルダの中）や、最近書き換えられた .htaccess・.user.ini がないか
- WordPressなら、知らない管理者ユーザーが増えていないか
Amazonは、調査の起点を公表日ではなく10月17日にするよう勧めています。共用サーバーでは、アクセスログとエラーログはコントロールパネルやFTPで取得できることが多いので、まず10月17日以降の分を保存しておきましょう。JPCERT/CCは、侵害が疑われるときはログなどの証拠を保全したうえで、影響範囲の調査や隔離を行うよう求めており、痕跡が見つからなくても攻撃を受けていないとは言い切れない、とも注意しています。
今回の件から見直しておきたいこと
今回の脆弱性で目立つのは、アプリケーションをいくら丁寧に更新していても、その下で動くPHPが古ければ守れないという点です。WordPressの本体やプラグインの更新は習慣になっていても、PHPのバージョンは「サーバー会社まかせ」で、何年も同じ系列のまま、という運営者は多いと考えます。共用サーバーなら修正はサーバー会社が当ててくれますが、どの系列のPHPを選ぶかは利用者の責任です。サポートが終わった系列のサイトは、今回のように応急の対策しか受けられません。年に1回、持っているサイトのPHPの系列と、その系列のサポート期限を一覧で確かめるだけでも、次に同じような発表があったときの動きが大きく変わるはずです。
このサイトでは、curlの脆弱性修正（curl 8.23.0が公開、HTTP/2のUAFなど24件のCVEを修正）や、Node.jsのセキュリティリリース（Node.js 26.12.1など公開、Brotliの脆弱性でRCEのおそれ）も取り上げています。サーバーで動くソフトウェアは、PHPと合わせて確認しておきましょう。
参考にした公式情報
- PHP: News Archive 2026（Security advisory: Critical remote code execution vulnerabilities, update now ほか）
- GHSA-w8hw-w9fx-j79w: RCE via OOM corruption（CVE-2026-109618）
- GHSA-6wmf-4rv5-p3rp: RCE via stale global state（CVE-2026-109619）
- IPA：PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)
- JPCERT/CC：PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起
- ヘテムル：お知らせ（PHPの重大な脆弱性への対応）
- AWS Security Blog：Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure
- Wiz Blog：PHP2Shell
- NCSC：Critical security issue affecting PHP
- Vercel：PHP security advisory: php2shell
2026年10月24日時点の情報です。
