PHP 脆弱性：PHP2Shellのパッチと PHP バージョンの確認（WordPress）

テスト環境 RHEL系AlmaLinux 9.8PHP 8.3 · WordPress 7.1.32026-10-22 確認

PHP2Shellは、2026年10月21日にパッチが公開されたPHPの脆弱性2件（CVE-2026-109618・CVE-2026-109619）の名前です。ログインしていないリクエストでもサーバー上でコードが実行されるリモートコード実行の欠陥のため、サイトが使っているPHP バージョンを確認し、パッチ適用バージョンに上げることが先決です。WordPress 7.1.3が入ったNginx + Apache構成のサーバーで、サイトヘルスからPHP バージョンを確認し、phpパッケージだけをパッチ適用バージョンに上げてから再確認した手順です。

3mn read

1️⃣ PHP 脆弱性 PHP2Shell：欠陥の仕組みと影響範囲

この欠陥はWordPressのコードが実行される前にリクエストを読み込むPHPエンジンの中にあるため、プラグインとテーマを最新に保っていても、PHPを上げなければそのまま残ります。CERT-EUの勧告によると2件ともCVSS 9.2で、技術的な詳細が公開されて議論されており、初期の概念実証（PoC）コードも出回り始めました。

CVE-2026-109618は、リクエストがメモリ上限（memory_limit）を超えて中断されたとき、半分しか初期化されていないリクエストデータを後処理が正常なデータとして扱ってしまう欠陥です。CVE-2026-109619は、致命的エラーのあとに解放されたメモリの状態が残り、同じワーカーが処理する次のリクエストで初期化前に再び使われてしまう欠陥です。

php.netの告知によると、Webリクエストを処理するすべてのPHPのインストールが対象で、そのうちApache mod_phpを最も危険な構成としています。ログインなしのリクエスト1つで、アプリケーションのコードが実行される前に攻撃が発動するデモがmod_phpで行われたためです。

PHPの実行方式	影響	備考
Apache mod_php	🔴 影響あり・最も危険	ログインなしのリクエスト1つで、アプリケーションのコードが実行される前に攻撃が発動したデモ
PHP-FPM	🔴 影響あり	—
php-cgi	🔴 影響あり	—
FrankenPHP	🔴 影響あり	—
LiteSpeed	🔴 影響あり	—

パッチ適用バージョンは8.2.35、8.3.36、8.4.27、8.5.12で、これより低い8.2〜8.5系はすべて影響を受けます。PHP 8.1以下はPHPプロジェクトのサポートが終わった系列のため公式のパッチ適用バージョンがなく、ディストリビューションやホスティング会社が移植した修正（バックポート）で対応します。

CISAが10月21日に告知した時点では実際の悪用は確認されていませんでしたが、CISAはパッチを当てずに放置すると危険だとして、インターネットに公開されているシステムから直ちにパッチを当てるよう勧告しました。CERT-EUは同日の勧告で、概念実証コードが出回り始めたことで、攻撃者がすでに悪用している可能性が高まったと判断しました。

2️⃣ PHP バージョンの確認：サイトヘルス › 情報 › サーバー

欠陥のことを知っていても、自分のサイトがどのPHP バージョンで実行されているか分からなければ、やるべきことは決まりません。管理画面で [ツール › サイトヘルス]を開き、[情報]タブの[サーバー]セクションを展開すると、[PHP バージョン]の行に、サイトのリクエストを実際に処理しているPHPのバージョンが表示されます。

サイトヘルスの情報タブ画面：左メニューのツール › サイトヘルス、サーバーセクションのサーバー構造・Web サーバー・PHP バージョン・PHP SAPIの行 — PHP 脆弱性 PHP2Shellのパッチ確認の基準となるPHP バージョン（WordPress 7.1.3）

[PHP バージョン]の行のすぐ下にある[PHP SAPI]の行はPHPの実行方式を表し、fpm-fcgiはPHP-FPM構成です。欠陥はリクエストを読み込むPHPエンジンの中にあるため、この構成も対象で、php.netの告知はそのうちApache mod_phpを最も危険な構成に挙げました。ここでは[サーバー]セクションの[PHP バージョン]・[PHP SAPI]の2行だけを見ます。

🧩 PHP2Shellの攻撃の流れ

解説ダイアグラム

①ログインなしのリクエスト誰でも送れるWebリクエスト

②特別に細工したリクエストPHPがWordPressのコードより先に読む

③PHPの欠陥メモリ不足 → 作りかけのデータをそのまま使うCVE-2026-109618終わったリクエストの状態を次のリクエストが使うCVE-2026-109619

④サーバーでコード実行サイトの乗っ取り

✅ パッチ適用バージョンではこの流れが止まる8.2.35 · 8.3.36 · 8.4.27 · 8.5.12

攻撃はログインなしのリクエストから始まります。特別に細工したリクエストをPHPがWordPressのコードより先に読む段階で2つの欠陥のどちらかに触れ、サーバーでのコード実行につながります。パッチ適用バージョンはこの流れを止めるので、やることはサイトのPHPをパッチ適用バージョン以上に上げることです。

ターミナルの[php -v]は、コマンドラインの既定のPHPのバージョンしか表示しません。cPanelのEA-PHPやCloudLinuxのalt-phpのように1台のサーバーに複数のバージョンのPHPを入れる構成では、サイトが使うバージョンと違うことがあります。そのため基準はサイトヘルスの[PHP バージョン]の値にします。

php -v

PHP 8.3.xx (cli) (built: Jun  3 2025 17:17:57) (NTS gcc x86_64)

管理画面に入れないサーバーでは、Webリクエストを処理するために動いているPHP-FPMのプロセスから、サイトが使うバージョンを探します。Debian・Ubuntuのパッケージでは、FPMマスターが読み込んだ設定ファイルのパスにバージョン番号が入っており、以下はあるマネージドホスティングのDebian 12テストサーバーで確認した結果です。

ps -eo user,args | grep '[p]hp-fpm'

root     php-fpm: master process (/etc/php/8.2/fpm/php-fpm.conf)
abcdefg+ php-fpm: pool abcdefghij-82
klmnopq+ php-fpm: pool klmnopqrst-82

設定パスの8.2がこのサーバーでサイトが使うPHPのバージョンで、このホスティングではプール名の末尾（-82）にもバージョン番号を付けています。起動中のFPMサービスが実行したファイルは[systemctl status]の[Main PID]の行でも確認でき、rootアカウントでなくても表示されます。

systemctl status php8.2-fpm --no-pager | head -6

● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-10-22 07:14:57 UTC; 7h ago
       Docs: man:php-fpm8.2(8)
    Process: <PID> ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82 (code=exited, status=0/SUCCESS)
   Main PID: <PID> (php-fpm8.2)

AlmaLinuxのようなRHEL系ディストリビューションの標準パッケージでは、マスターの設定パスが/etc/php-fpm.confのためバージョン番号が出ません。この場合は[rpm -qf /usr/sbin/php-fpm]でFPMパッケージのバージョンを確認します。

3️⃣ PHP 8.2未満なら：ホスティング会社にバックポートの適用を確認し、なければ依頼

サイトヘルスの[PHP バージョン]が8.2未満（7.x・8.0・8.1）なら、php.netの公式なパッチ適用バージョンはありません。php.netのサポート対象バージョンの表（2026年10月22日確認）では、サポート中の系列は8.2・8.3・8.4・8.5の4つだけで、8.1以下の公式バージョンにはセキュリティパッチが出ません。

PHP系列	パッチ適用バージョン	セキュリティサポート終了
8.2	8.2.35	2026年12月31日
8.3	8.3.36	2027年12月31日
8.4	8.4.27	2028年12月31日
8.5	8.5.12	2029年12月31日
8.1以下	公式バージョンなし · ディストリビューション・ホスティングのバックポート	終了

8.2系列は2026年12月31日にセキュリティサポートが終わるため、今から上げるなら8.3以上を選びます。

その代わり、ディストリビューションやホスティング会社が、バージョン番号はそのままに修正だけを移植したパッケージ（バックポート）を出すことがあります。あるマネージドホスティングのテストサーバーの7.4.33・8.0.30・8.1.34パッケージがその例です。変更履歴に[Backported from 8.2.35 — CVE-2026-109618, CVE-2026-109619]という行が入っていました。

バージョン番号が同じでも、修正が入っているかはパッケージの変更履歴でCVE番号を探して確認し、行が出れば修正が入ったパッケージです。Debian・Ubuntu系では以下のように探し、パスのバージョン番号はサイトが使うバージョンに合わせます。

zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618

   + (CVE-2026-109618, CVE-2026-109619): Avoid state corruption via

RPM系では以下のコマンドで探します。

rpm -q --changelog php-common | grep 109618

そのため8.2未満なら、まずホスティング会社にバックポートが適用されているかを確認し、適用されていない、または確認できない場合は、サポート対象のバージョンに上げるよう依頼します。上げたあとはサイトヘルスの[PHP バージョン]の値で再確認します。

CISAは、8.1以下を使っている組織がすぐにアップデートできない場合、パッチ適用かアップグレードまでPHPベースのシステムをオフラインにしておくよう勧告しました。

自分でサーバーを運用していて8.1以下を使っているなら、ディストリビューションのバックポートパッケージを入れるか、PHPのセキュリティチームが出した7.4・8.0・8.1用のソースパッチを適用できます。それでもサポートが終わった系列なので、サポート対象のバージョンに上げるのが根本的な対応です。

4️⃣ PHP 8.2以上なら：パッチ適用バージョンにアップデートして再確認

8.2以上でもパッチ適用バージョンより低いなら、PHP自体を上げます。マネージドホスティングや共有ホスティングでは事業者がサーバー全体にパッチを適用するので、事業者の告知や問い合わせで適用状況とビルドを確認し、サイトヘルスの[PHP バージョン]が変わったかを見ます。Cloudwaysはステータスページの告知で、10月21日22:19 UTCにPHP 5.6・7.4・8.0〜8.4へのパッチを適用中だと知らせ、10月22日10:11 UTCには適用が終わったと明らかにしました。

🪐参考PHP2Shell 2

📡【緊急】Webサイトの70%が使うPHPに非常事態｜脆弱性と今すぐやることまとめ（韓国語） 🌌Cloudways マネージドホスティング

自分で運用しているサーバーは、php.netの告知どおりディストリビューションやLTSベンダーのリポジトリのパッケージで上げます。アップデート前にプレビューで変わるパッケージの一覧を確認し、phpで始まるパッケージだけが上がってほかのパッケージがついてこないかを見て、OSのほかのアップデートと混ぜないようにします。

dnf upgrade --assumeno 'php*'

Dependencies resolved.
================================================================================
 Package       Architecture  Version         Repository  Size
================================================================================
Upgrading:
 php           x86_64  8.3.xx-1.…        …       1.9 M
 php-cli       x86_64  8.3.xx-1.…        …       5.6 M
 php-common    x86_64  8.3.xx-1.…        …       1.3 M
 php-fpm       x86_64  8.3.xx-1.…        …       1.9 M
 （php-gd・php-intlなどの拡張パッケージの行は省略）

Transaction Summary
================================================================================
Upgrade  xx Packages

dnf upgrade 'php*'

Upgraded:
  php-8.3.xx-1.….x86_64
  php-cli-8.3.xx-1.….x86_64
  php-common-8.3.xx-1.….x86_64
  php-fpm-8.3.xx-1.….x86_64
  （拡張パッケージの行は省略）

Complete!

今回の実測では、phpで始まるパッケージだけがパッチ適用バージョンに上がり、パッケージのインストールが終わるとphp-fpmが自動で再起動しました。パッチ適用バージョンはphp-fpmのワーカーが再起動して初めて反映されるため、自動再起動がない環境では[systemctl restart php-fpm]を自分で実行します。

上げたあとは、[php -v]とサイトヘルスの[情報]タブの[PHP バージョン]の行がどちらもパッチ適用バージョン以上かを見て、php-fpmサービスの状態とサイトの応答まで確認します。コマンドラインの値だけが変わり[PHP バージョン]の値がそのままなら、php-fpmを再起動してから再確認します。

サイトヘルスの情報タブ画面：アップデート後にサーバーセクションのPHP バージョンの行がパッチ適用バージョン以上かを再確認 — 左メニューのツール › サイトヘルス、サーバーセクションのPHP バージョン・PHP SAPIの行（WordPress 7.1.3）

アップデートのあとも、同じ[ツール › サイトヘルス]の[情報]タブで[サーバー]セクションを展開して[PHP バージョン]の行を見ます。この値が上げたバージョンに変わっていれば、php-fpmのワーカーまで新しいバージョンで実行されています。

php -v

PHP 8.3.xx (cli) (built: Oct 19 2026 14:00:34) (NTS gcc x86_64)

systemctl is-active php-fpm

active

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'

バージョン番号そのものが上がるパッケージは新しいバージョン番号で、バージョン番号をそのままにしたバックポートパッケージは変更履歴のCVE番号で、パッチが当たったかを確認します。今回のサーバーは前者だったため[rpm -q --changelog php-common]にCVE番号の行はなく、変更履歴の最初の行の新しいバージョン番号で確認しました。

5️⃣ すぐに上げられないとき：php.netが案内する暫定対策

すぐに上げられないサーバー向けに、php.netは以下の設定を暫定対策として案内しつつ、これらの対策は特定の攻撃経路を減らすだけで、インストールを安全にするものではないと明記しました。メモリ上限をRLIMIT_ASやRLIMIT_DATAで代わりに設定すると、かえって脆弱なメモリ割り当ての失敗を引き起こすことがあるため使わないようにとも書いています。

設定	値	設定場所	防ぐもの
memory_limit	-1	FPMプール・Apache設定のphp_admin_value（アプリケーションが戻せないように）	CVE-2026-109618・メモリ上限の失敗経路（完全ではない）
post_max_size	8M（アップロードが必要なら32M）・upload_max_filesizeはそれより小さく	php.ini・プール設定	CVE-2026-109618
session.upload_progress.enabled	0 + すべてのワーカーを再起動	php.ini・FPMプール・サーバー設定（ini_set()・.user.iniは不可）	CVE-2026-109619・確認済みのセッション経路のみ
fatal_error_backtraces	0 + すべてのワーカーを再起動（PHP 8.5のみ）	上と同じ	CVE-2026-109619・確認済みのバックトレース経路のみ

php_admin_valueはアプリケーションが戻せないサーバー側の設定のため、共有ホスティングの利用者は自分で変えられないことが多く、その場合も結局はホスティング会社に依頼することになります。php.netは、Webサーバーやプロキシの段階でも、リクエスト本文のサイズと入力フィールドの数、multipartの分割数、ヘッダーの数、ネストの深さに上限を設けるよう案内しています。

表のsession.upload_progress.enabledの設定は、10月23日のphp.netの案内であらためて推奨されました。php.netは、可能性の低いリモートコード実行の経路（CVE-2026-115560）まで防ぐため、次の定期バグ修正バージョンまでこの値を0にしておくよう勧めています。10月21日のGHSA-6wmf-4rv5-p3rpの勧告にすでに緩和策として載っていた設定なので、そのとき適用していればそのままで構いません。

この経路は、設定でsession.serialize_handlerをphp_binaryまたはphp_serializeにしているアプリケーションが、session_start()の前にini_set()でphpに切り替え、セッションのアップロード進捗機能もオンになっている場合にだけ生じます。CVE-2026-115560の経路だけで見れば、実行中にシリアライズ方式を変えないアプリケーションはこの機能をオンにしたまま使えるとphp.netは明らかにしました。

🔢 FAQ & おすすめコンテンツ

WordPressの自動更新が扱うのはコアとプラグイン、テーマ、翻訳だけで、PHPはサーバーにインストールされたプログラムなので、サーバー管理者かホスティング会社が上げます。コア・プラグイン・テーマの自動更新は WordPress の更新画面とプラグイン・テーマの画面でそれぞれオンにし、それらの画面にPHPのバージョンは表示されません。

技術的な詳細の全文は、php.netの告知がCVE番号の横にリンクしているGitHubのセキュリティアドバイザリー2件にあります。CVE-2026-109618はGHSA-w8hw-w9fx-j79w、CVE-2026-109619はGHSA-6wmf-4rv5-p3rpです。CERT-EUの勧告も同じ2件を参考文献に挙げており、攻撃の再現手順の詳細はこの記事に載せていません。

CISAは、PHPのワーカープロセスがシェルを起動したりツールをダウンロードしたりする動きを監視するよう案内しています。パッチを当てるまでは、Webアプリケーションファイアウォールがある程度の防御になり得るとも書いています。PHPはほかのソフトウェアの部品として組み込まれて目立たないことが多いため、PHPが実行されているシステムの一覧づくりから始めるよう勧めました。

セキュリティ wp-config.phpのセキュリティ脆弱性 wp-config.phpファイルの露出を防ぎ、セキュリティ設定を強化する方法です。

セキュリティ WordPress XML-RPC xmlrpc.phpへの攻撃をログで見分け、無効化する3つの方法です。

サーバー php-fpm max_children 警告ワーカーを増やす前に、ログで警告の原因を突き止める実測です。

🪐参考PHP2Shell 7

📡PHP: Security advisory — Critical remote code execution vulnerabilities, update now (2026-10-21) 📡PHP: Informational advisory — Session upload progress (2026-10-23) 📡CISA: Critical Vulnerabilities in PHP Require Immediate Patching (2026-10-21) 📡CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP 📡GitHubセキュリティアドバイザリー GHSA-w8hw-w9fx-j79w (CVE-2026-109618) 📡GitHubセキュリティアドバイザリー GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) 🛰️Sansec: PHP2Shell — PHP RCE (CVE-2026-109618, CVE-2026-109619)

ℹ️ 提携について
当サイトのコンテンツにはアフィリエイトリンクが含まれています。訪問者がこのリンクを通じて商品やサービスを購入すると、当サイトは販売元から手数料を受け取ります。この過程において、購入者が支払う金額^{（イベント割引適用で金額が下がります↓）}は上昇しません。掲載されている価格・割引・在庫情報は作成時点のものであり、実際とは異なる場合がありますので、ご購入前に販売元にて最終確認をお願いいたします。商品の選定および評価は独自の基準に基づいて行われており、手数料の支払いの有無は紹介順や評価内容に影響を与えません。