PHP重大脆弱性「php2shell」とは｜影響確認・更新依頼・暫定策

2026年10月21日、PHPプロジェクトは、認証なしで外部からコードを実行されるおそれがある2件の重大脆弱性に対する修正版を公開しました。対象はCVE-2026-109618とCVE-2026-109619です。「php2shell」と呼ばれるこの問題では、WordPressなどのCMSを更新しただけでは対応が終わりません。

サイト運営者がまず行うことは、自社サイトを動かしているPHPのバージョンと管理者を確認し、サーバー側のPHP本体の修正適用を依頼することです。 公式修正版は8.5.12・8.4.27・8.3.36・8.2.35。ホスティング会社やOS提供元が修正を取り込んだパッケージを提供する場合は、その適用状況を確認します。WAFや設定変更は追加の防御であり、PHP更新の代わりにはなりません。以下は2026年10月22日時点の公開情報に基づきます。

---

本記事のポイント

1. php2shellの対処にはサーバー側のPHP本体の修正が必要で、WordPressやプラグインの更新だけでは完了しません。
2. 自社サイトが実際に使うPHPのバージョンと管理者を確認し、提供元の修正済みパッケージまたは公式修正版への更新を依頼します。
3. WAFや設定変更は特定の攻撃経路を減らす暫定策にとどまるため、修正適用・稼働プロセスの切り替え・サイト動作まで確認します。

---

PHPの重大脆弱性「php2shell」で何が起きたか

PHP公式のセキュリティ告知は、Webリクエストを処理するPHP環境を確認対象としています。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedが例示されています。リモートコード実行とは、外部から送られた要求をきっかけに、サーバー上で攻撃者のコードが動くことです。両件ともCVSS v4.0の基本値は9.2で、重大度はCriticalです。

脆弱性	公式説明に基づく問題の概要	運営者が押さえる点
CVE-2026-109618	メモリ不足時の処理により、初期化途中の内部データを、その要求の終了処理で有効なデータとして扱うおそれがある	メモリ不足を起こす要求が、単なる負荷や停止を超え、コード実行につながり得る
CVE-2026-109619	要求に属するメモリを解放した後にも参照が残り、同じワーカーが次の要求で古い状態を使うおそれがある	ある要求の終了後、後続の要求にまたがって問題が生じ得る

詳しい条件はPHPプロジェクトの109618のアドバイザリと109619のアドバイザリに示されています。すべての環境で同じ攻撃手順が成功するという意味ではありません。ただし公式は、mod_phpではアプリケーションのコードが動く前に攻撃を起こせる実証があり、最もリスクが高いと説明しています。CMSのログインを強化したことだけで、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 7.4・8.0・8.1	最小限のソースバックポートを別途案内	通常サポートの再開ではない。提供元の修正対応とサポート中の系列への移行を確認

表の修正版と境界は両公式アドバイザリに基づきます。PHP公式は、8.1以前には通常の更新を提供しておらず、一部のLinuxディストリビューションや長期サポート事業者が修正を取り込むと説明しています。これはバックポートと呼ばれ、元のバージョン番号を保ったまま修正される場合があります。表示番号だけで未修正と決めず、提供元が両CVEへの修正を適用したことを確認してください。

公開日は公式ニュースと8.5.12のリリース告知が示す10月21日として扱います。更新作業では、日付だけで判断せず、該当系列の修正内容を公式ChangeLogでも確認してください。

自社サイトが影響を受けるかを確認する手順

最初に、会社サイト、採用サイト、LP、EC、会員ページ、サブドメインごとに、URL・サーバー契約・PHPの利用有無・PHPの管理者を並べます。一つのサイトの確認結果を、契約や設定が異なる別サイトへそのまま当てはめないことが大切です。確認対象の整理には、ウェブサイト構築で押さえる基盤と運用の考え方も役立ちます。

1. レンタルサーバーの管理画面を見る

契約しているサーバーの管理画面で、対象ドメインの「PHP設定」「PHPバージョン」などの項目を探します。画面名は提供会社によって異なります。「8.3」のような系列名しか表示されない場合は、細かな修正版まで分からないので、ホスティング会社の障害・セキュリティ告知とサポート窓口で確認します。

WordPressなら、「ツール → サイトヘルス → 情報」のサーバー項目も手掛かりになります。WordPress公式のサイトヘルス説明を参照し、WordPress本体のバージョンとPHPのバージョンを取り違えないでください。管理画面で選べる系列を変更するだけでよいのか、提供元で修正済みなのかは、別途確かめる必要があります。

2. 必要なら担当者にphpinfoで確かめてもらう

管理画面で確認できない場合、サーバーを管理する担当者に、対象サイトで動くPHPの情報を確認してもらいます。PHP公式のphpinfoのマニュアルでは、PHPバージョン、サーバー情報、設定値などを表示できると説明されています。一般情報に絞って確認するコードの例は次のとおりです。

<?php phpinfo(INFO_GENERAL);

この確認は、担当者がアクセス制限を設けた場所で一時的に行い、PHP VersionとServer APIを読み取った後、確認用ファイルを削除してください。phpinfoは構成情報も表示するため、公開したままにしません。ファイルの設置や削除に慣れていない場合は、管理画面かサポート窓口を使う方が確実です。

担当者がコマンドのphp -vで調べる場合も、それがWebサイトの実行環境と同じPHPかを確認してもらいます。コマンド用PHPの情報だけで、Webリクエストを処理するPHP-FPMなどの修正状況まで確認できたと判断しないでください。

3. 分からなければ制作会社へURLを渡す

サイトがPHPを使っているか、誰に更新権限があるか分からない場合は、制作会社へ対象URLと両CVE番号を伝えます。「WordPressは最新です」という回答だけではPHP本体の修正状況は分かりません。PHPを使わない構成であれば、同じ契約内のフォームや別のサブドメインにもPHPが残っていないかまで確認してもらいます。

誰に何を頼むか｜更新依頼文と完了確認

PHPはサーバー上で動くソフトウェアです。WordPress公式のPHP更新ガイドも、ホスティング会社の設定を操作するか、提供元へ更新を依頼する流れを案内しています。まず更新権限を持つ相手を決め、制作会社にはアプリケーションの互換性確認も依頼します。

相手	依頼する内容	受け取りたい回答
ホスティング会社	対象契約・ドメインのPHP本体について両CVEの修正適用を確認	適用済みパッケージ、提供元の根拠、利用者側の切り替え要否
制作会社・保守会社	PHPの利用箇所、更新手順、CMS・テーマ・プラグインの互換性と動作を確認	対象URL、実施担当、作業日時、確認結果
社内のサーバー担当	修正済みパッケージの適用、稼働ワーカーの再起動・切り替え、ログの確認	全対象の修正根拠と実行中プロセスへの反映結果

制作会社・ホスティング会社への依頼文

この文面に、対象URLと契約番号、連絡先、回答が必要な期限を追記して利用できます。パスワードや秘密鍵を依頼文へ書く必要はありません。契約上どこまで保守対象かも確認し、制作会社とホスティング会社の間で担当が曖昧なままにしないことが重要です。

「更新済み」の後にも確かめる

1. 修正根拠：適用した公式バージョン、または提供元の両CVE対応パッケージを記録します。
2. 稼働への反映：担当者に、必要な再起動・ワーカー切り替えを終え、古いPHPが稼働していないことを確認してもらいます。
3. 業務動作：トップページだけでなく、管理画面、フォーム、アップロード、決済など自社で使う機能を確認します。
4. 対象の漏れ：別ドメイン、検証環境、旧サイトなど、Webから到達できるPHP環境の確認結果も残します。

バックアップと動作確認の準備は更新を進めるために行い、未修正環境へ戻して公開したままにすることを復旧完了にしません。PHPの系列をまたぐ変更が必要な場合は、互換性の確認と公開範囲の制限を管理者と相談してください。

すぐ更新できない場合の暫定策と限界

PHP公式は、完全な対策は更新だけであり、設定変更で安全な状態になるわけではないと明記しています。 非技術担当者が設定値をそのまま変更するより、サーバー管理者へ公式アドバイザリを渡し、適用可否・業務影響・更新までの期間を確認してください。

WAF・CDNは提供会社の対応範囲を確認する

Cloudflareの公式発表では、WAFを導入している環境に対策を展開したと説明しています。Freeプランでは対応ルールが自動適用され、有料のProfessional・Business・EnterpriseプランではManaged Rulesetがブロックモードで展開されているか確認するよう案内しています。同社もPHP本体への修正適用を推奨しています。

「CDNを契約している」ことと、対象サイトにWAF対策が適用されていることは分けて確認します。提供会社へ、両CVEへの対応、対象ホスト名、ルールの有効状態、除外設定を問い合わせてください。他社サービスにも同じ防御があるとは判断できません。役割の違いはCloudflareのDNS・CDN・WAFの仕組みで整理しています。

WordPressでWAFやキャッシュの設定を確認する際は、WordPress向けCloudflare設定も参照してください。ログインやフォームなど、自社が利用する機能への影響も確認します。

サーバー側の設定変更は管理者に判断してもらう

109618について、公式はmemory_limit=-1の管理者側での強制と、要求サイズや入力項目数などの制限を案内しています。ただし、下位のメモリ確保が失敗する経路は残ります。メモリ上限の解除にはリソース管理も伴うため、この値だけを変更して終えず、管理者が公式に示されたコンテナ・cgroupなどの制約と合わせて判断する必要があります。公式は、脆弱な処理につながるメモリ確保失敗を起こすため、代わりにRLIMIT_ASやRLIMIT_DATAを使わないよう注意しています。

109619については、session.upload_progress.enabled=0を要求解析より前に有効になる設定へ入れ、すべてのワーカーを再起動する方法が示されています。PHP 8.5ではfatal_error_backtraces=0も案内されています。いずれも確認済みの特定経路を抑えるもので、別経路まで防ぐとは説明されていません。アプリケーション内のini_set()やFPMの.user.iniに頼らないことも公式の注意点です。

また、エラーを画面に表示しない設定へ変えるだけでは109619を防げません。暫定策を採用した場合は、何を設定したか、どの経路を減らすか、誰がいつPHP更新を行うかを記録し、「WAFを入れたので更新不要」という判断を避けてください。

よくある質問

WordPress本体やプラグインを更新すれば直りますか？

それだけでは直りません。今回の問題はPHP本体にあり、サーバー側のPHP修正が必要です。CMS・テーマ・プラグインの更新は互換性や別の脆弱性への対応として行い、PHP更新の確認も別に実施してください。

PHP 8.3と表示されていれば安全ですか？

系列名だけでは分かりません。公式修正版は8.3.36です。バックポートを使う環境では表示番号が異なる場合もあるため、ホスティング会社やOS提供元に両CVEの修正適用を確認してください。

PHP 7.4・8.0・8.1にも通常の修正版がありますか？

PHPプロジェクトが案内したのは最小限のソースバックポートで、通常サポートが復活したわけではありません。ソースからのビルドを自分で行う前提にせず、提供元の修正対応か、サポート中の系列への移行を担当者に確認してください。

WAFが有効ならPHP更新を待っても大丈夫ですか？

WAFだけで安全とは判断できません。提供会社の対策は追加の防御として使い、PHP本体の更新を進めてください。PHP公式も、完全な対策は更新だけだと説明しています。

修正版を適用すれば、過去に侵入されていないと分かりますか？

分かりません。修正適用の確認と、過去の侵入有無の調査は別です。不審なファイル、管理者追加、通信やエラーの異常があれば、担当者へログと変更履歴の保全・調査を依頼してください。更新完了だけを根拠に、被害がなかったと結論づけないでください。

自社でサーバーを管理していない場合も確認が必要ですか？

契約先へ確認してください。マネージドサービスでも、提供元がPHP更新を実施するか、利用者側でバージョン切り替えが必要かは契約によって異なります。対象URLと両CVE番号を渡し、利用者が行う作業の有無を書面で確認すると担当が明確になります。

サイトの基盤と運用担当を整理したい方へ

更新対象や管理者が分からず対応が止まる場合は、サイトの構成、保守範囲、更新時の確認手順を整理することが出発点になります。ファネルAiでは、Webサイト・業務システムの構築と運用設計を支援しています。

Webサイトの基盤・運用設計を相談する