PHPの緊急レベルの脆弱性「PHP2Shell」（CVE-2026-109618／CVE-2026-109619）の概要と、サイト運営者が行うべき対応

2026年10月21日、PHPの開発元であるThe PHP Groupは、深刻度の高い脆弱性2件（CVE-2026-109618、CVE-2026-109619）を修正したPHP 8.5.12／8.4.27／8.3.36／8.2.35を公開しました。2件の組み合わせは「PHP2Shell」と呼ばれています。

悪用されると、ログインしていない外部の第三者が、Webサーバー上でPHPの実行権限のまま任意のプログラムを動かせるおそれがあります。PHP公式は「完全な緩和策はなく、更新が唯一の安全な選択肢である」としています。

PHPを使っているWebサイト（WordPress・Drupal・EC-CUBEなどのCMSを含む）は、以下の修正版へ速やかに更新してください。

利用中のバージョン	必要な対応
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	公式の修正版は提供されません。サポート中の8.2系以降への移行が必要です（自分でソースからビルドする利用者向けに、最小限の修正が別途公開されています）
PHP 7.3以前・5系	修正は提供されません。移行するまでの間は、外部からのアクセス遮断も含めて検討してください

出典：PHP公式セキュリティアドバイザリ（2026年10月21日）、PHP Supported Versions

1. 脆弱性の概要

項目	CVE-2026-109618	CVE-2026-109619
PHP公式の名称	RCE via OOM corruption	RCE via stale global state
内容（IPAの説明）	メモリ不足（OOM）のエラー処理に起因する脆弱性	リクエスト処理に関連する脆弱性
深刻度	CVSS v4.0 9.2（Critical）	CVSS v4.0 9.2（Critical）
認証の要否	不要	不要
影響	Webサーバーの実行ユーザー権限での任意のコード実行	同左、加えてメモリ内容の漏えい
詳細	GHSA-w8hw-w9fx-j79w	GHSA-6wmf-4rv5-p3rp

CVSSのベクトルは両件とも AV:N/AC:H/AT:P/PR:N/UI:N で、ネットワーク経由で、認証も利用者の操作も必要としません。一方で攻撃の難易度（AC）は「高」とされており、成功するかどうかはPHPのビルドや拡張機能、前段のWebサーバーの挙動などに左右されるとPHP公式は説明しています。

注意すべき点は、アプリケーション側のコードに不備がなくても影響を受けることです。発見者の一社であるWiz社は、単純な「Hello World」を表示するだけのアプリでも、該当バージョンのPHPで動いていれば対象になりうると述べています（Wiz社ブログ）。同社は、過去10年に公開されたPHPのすべてのバージョンが、2件のうち少なくとも一方の影響を受けるとしています。IPAも同社の見解として「PHP 5.4以降のバージョンは少なくとも一方の脆弱性の影響を受ける」と紹介しています（IPA 2026年10月22日）。

動作形態ごとの影響（PHP公式アドバイザリより）

PHPをWebサーバーでどう動かしているか（SAPI）によって、検証の状況が異なります。

動作形態	CVE-2026-109618	CVE-2026-109619
Apache＋mod_php	既定の設定で、HTTP経由での攻撃成立を確認済み	攻撃成立を確認済み（`.htaccess` の `php_value` 等が関係する経路を含む）
PHP-FPM（Nginx等と組み合わせる一般的な構成）	部分的に分析。完全な攻撃手順はまだ示されていない	セッションのアップロード進捗機能を使う経路で確認済み
FrankenPHP	ソースの分析上、影響を受ける可能性が高い	既定の設定では影響は示されていない（ただし、影響がないとはされていない）
LSAPI（LiteSpeed）	影響を受ける可能性が高い（未検証）	条件次第

「FPMなら安全」という結論にはなりません。PHP-FPMでもCVE-2026-109619は検証済みのため、動作形態にかかわらず更新が必要です。

2. 公表までの経緯（日時は各発表をもとに当サイトで整理）

今回は、修正版の公開前に情報が外部に出たことで、公開日が予定より1日早まっています。

日付	出来事	出典
2026年8月19日	Wiz社が1件目の脆弱性を発見	Wiz社
8月20〜21日	同社がDrupal、WordPressに対し、認証なしでのコード実行を確認	Wiz社
8月24日	Wiz社がPHPのセキュリティチームへ報告	Wiz社
9月21日	PHP側が報告を受理し、修正作業を開始	Wiz社
10月17日	Amazonが、自社のおとり観測網で本脆弱性を狙ったとみられる攻撃の試みを観測（公開の4日前）	Tenable社（Amazonの発表を引用）
10月20日	CVE番号がSNS等で拡散。PHP公式が「10月21日14:00（UTC）にセキュリティリリースを行う」と事前告知。当初は22日の予定だった	PHP公式、Tenable社（PHP Foundationの説明を引用）
10月21日	IPAが事前準備を呼びかけ	IPA
10月21日（日本時間23時の予定と事前告知）	修正版 8.5.12／8.4.27／8.3.36／8.2.35 を公開	PHP公式
10月21日	米国CISAが緊急の更新を呼びかけ	CISA
10月22日	IPA、JPCERT/CCが注意喚起を公開	IPA、JPCERT/CC

悪用の状況について

発表元によって記載が異なります。

CISA：公表時点で悪用は確認していない
PHP Foundation：修正版の公開時点で、実際に機能する攻撃コードは確認していない（Tenable社の記事による引用）
Amazon：10月17日に攻撃の試みを観測し、21日以降は複数の攻撃者によるとみられる試みが広く見られる。調査は10月17日以降を対象にするよう推奨（同上）
Cloudflare：10月21日に初期の攻撃が出始めていると発信（同上）

これらを踏まえると、「まだ悪用されていない」という前提で更新を先送りすることは避けるべきと当サイトでは考えます。少なくとも、Amazonは修正版の公開の4日前に攻撃の試みを観測したと報告しています。

3. 国内での影響の大きさ

W3Techsの集計（2026年10月22日時点）では、サーバー側の言語が判明しているWebサイトの**69.3%**がPHPを使用しています。報道で「ウェブの7割」とされているのはこの数値です。

同じ集計で、PHPを使うサイトのバージョン内訳は PHP 8が65.3%、PHP 7が26.9%、PHP 5が7.7%です（W3Techs）。

PHP 7系と5系には今回、公式の修正版が提供されません。2つを合計すると、PHPを使うサイトの約3割強（34.6%）が、更新ではなく移行を必要とするバージョンで動いている計算になります（当サイトによる算出。PHP 8系のうち8.0／8.1を使うサイトもこれに加わりますが、W3Techsの公開値からは切り分けられません）。

JPCERT/CCも、PHPが国内で広く利用されていることを確認したうえで注意喚起を出しています。

4. サイト運営者が行うべき対応

手順1：自社サイトのPHPのバージョンを確認する

レンタルサーバー：管理画面の「PHPバージョン設定」等で確認します。サーバー会社が修正版を順次適用する場合が多いものの、利用者が古いバージョン（8.1以前など）を選んだままになっていると、修正の対象外になります。 契約先のサーバー会社の告知もあわせてご確認ください。
VPS・クラウド・自社サーバー：php -v で確認します。Linuxディストリビューションのパッケージ（Debian、RHEL等）で導入している場合は、PHP公式とは異なる版番号で修正が提供されることがあるため、各ディストリビューションのセキュリティ情報を確認してください。
PHPを内部で使う製品：CMS、EC、グループウェア、ネットワーク機器の管理画面などにもPHPが組み込まれている場合があります。IPAは10月21日の事前の呼びかけで、マニュアルや開発元の情報で確認するよう求めています。たとえばCiscoは、自社製品約30件について影響を調査中とするアドバイザリを公開しています（2026年10月22日の版では、影響が確認された製品はありません）。利用中の機器・製品の開発元からの告知も確認してください。

手順2：修正版へ更新する

冒頭の表のとおり、サポート中の系列は修正版へ更新します。JPCERT/CCは、十分なテストを行ったうえで更新するよう案内しています。

8.2系は2026年12月31日でセキュリティサポートが終了します。今回8.2.35へ更新する場合でも、年内に8.3系以降への移行計画を立てておくことをおすすめします。

手順3：すぐに更新できない場合の暫定策

PHP公式のアドバイザリには、更新までの間に攻撃の経路を減らす設定が示されています。いずれも部分的な緩和にとどまり、更新の代わりにはなりません。

対象	設定・対処
CVE-2026-109618	を管理者の設定として固定する（アドバイザリが主な緩和策として挙げる設定。メモリの上限がなくなるため、サーバー全体のメモリ不足に注意が必要です）
CVE-2026-109619	PHP 8.5では `fatal_error_backtraces=0` に設定し、ワーカーを再起動する
CVE-2026-109619	`session.upload_progress.enabled=0` に設定し、ワーカーを再起動する
CVE-2026-109618	`post_max_size` を控えめに設定し、前段のWebサーバー側でもリクエストの大きさを制限する
CVE-2026-109618	アプリがファイルアップロード等の multipart 形式を使わない場合は、前段で multipart のリクエストを遮断する
CVE-2026-109618	`max_input_nesting_level` を下げ、入力変数・アップロード数などに上限を設ける
共通	WAF（Webアプリケーションファイアウォール）の利用。CISAは「一定の防御になりうる」としています

session.upload_progress.enabled を無効にすると、アップロードの進捗表示を使う機能が動かなくなる場合があります。設定変更の前に、影響する機能がないかを確認してください。

CISAは、修正版を適用できないシステムやPHP 8.1以前で動くシステムについて、更新できるまでオフラインにするべきとしています。IPAも、有効な暫定策がない場合は外部からのアクセス遮断やサービスの一時停止を判断するよう求めており、さらに、維持管理の体制を確保できないシステムについては、機能の縮小や公開の終了を含めて経営層とともに判断するよう求めています。

手順4：攻撃を受けていないかを確認する

JPCERT/CCは、次の痕跡を確認するよう推奨しています。

不自然に長い、または異常な形式の PHPSESSID Cookie が発行されていないか
不審な multipart/form-data のリクエストと、その前後にメモリ上限のエラーや HTTP 500 エラーが出ていないか
PHPのワーカープロセスが予期せず異常終了したり、頻繁に再起動したりしていないか

CISAは、PHPのワーカープロセスがシェルを起動したり、外部からツールをダウンロードしたりする動きにも注意するよう求めています。

ただし、Wiz社は「この攻撃はアプリケーションより下の層で動くため、アプリのログには手がかりがほとんど残らない場合がある」としており、PHP公式も「ログに痕跡がないことは安全の証明にはならない」と明記しています。調査期間はAmazonの推奨に沿って10月17日以降を対象にすることをおすすめします。

侵害が疑われる場合の進め方は、関連記事「脆弱性が見つかったときの対応手順」で整理しています。

よくある質問

Q. WordPressを使っていますが、プラグインやテーマの更新で対応できますか。 A. できません。今回の脆弱性はWordPressではなく、その土台であるPHP本体にあります。サーバー側のPHPを修正版へ更新する必要があります。

Q. レンタルサーバーなら何もしなくてよいですか。 A. サーバー会社が修正版を適用する場合でも、利用者が選んでいるPHPのバージョンが8.1以前であれば修正は届きません。管理画面で選択中のバージョンを確認し、8.2系以降（できれば8.3系以降）へ切り替えてください。切り替え後は、サイトの表示や問い合わせフォームなどが正しく動くかを確認してください。

Q. 静的サイト（HTMLのみ）やNext.jsのサイトも影響を受けますか。 A. サーバー側でPHPを動かしていなければ、今回の脆弱性の対象にはなりません。ただし、同じサーバーや同じドメインの別の場所で問い合わせフォームや管理画面だけPHPで動かしている例もあるため、構成全体を確認してください。静的サイトや Next.js の安全性については「Next.js・静的サイトは安全か」で整理しています。

Q. 深刻度の「9.2」はどの程度ですか。 A. CVSS v4.0では9.0以上が最も高い「Critical（緊急）」に分類されます。なお、公開前に一部で「10.0」という数値が出回りましたが、PHP公式が示した値は9.2です。

※本記事は2026年10月22日時点の公開情報にもとづいています。各機関の発表は随時更新されるため、対応の際は最新の情報をご確認ください。