PHPの重大な脆弱性「PHP2shell」｜WordPressサイトのPHPが修正版かを、版番号の最後の数字まで確かめる手順

2026年10月23日

PHPの重大な脆弱性2件は10月21日公開の修正版で直る。入れ替えるのはサーバーにあるPHP

PHPの開発チームは2026年10月21日、ウェブサイトの処理に広く使われるプログラミング言語PHPの修正版「8.5.12」「8.4.27」「8.3.36」「8.2.35」を公開しました（PHPの公式の告知）。修正したのは、脆弱性（悪用されうる欠陥）2件、CVE-2026-109618とCVE-2026-109619です。通称は「PHP2shell」で、深刻度の評価（CVSS v4.0）はどちらも10点満点の9.2、区分は最も高い「Critical（緊急）」です。悪用されると、ログインしていない第三者に、ネットワーク越しにサーバー上でプログラムを実行されるおそれがあります。IPA（情報処理推進機構）も10月22日に注意喚起を出し、修正版への更新を求めています。

PHPは、WordPressのプログラムを実行しているサーバー側のソフトウェアです。公式の告知によると、ウェブサイトを表示するためにPHPを動かす方式はすべて対象で、ApacheにPHPを組み込んで動かす方式（mod_php）、PHP-FPM、php-cgi、FrankenPHP、LiteSpeedが挙がっています。WordPressのサイトを動かしているPHPも、このどれかに当たります。公式の告知では、危険度が最も高いのはmod_phpとされ、WordPressなどのプログラムが動き始める前の段階で攻撃を受けうると説明されています。欠陥はPHPそのものにあるため、WordPress本体、テーマ、プラグインを更新しても直りません。どの方式でも、サーバーにあるPHPを修正版に入れ替えて直します。

自分のサイトのPHPが修正版かは、WordPressの管理画面にある診断画面「サイトヘルス」の「情報」タブで、PHPの版を最後の数字まで見ると確かめられます。同じサイトヘルスの「ステータス」タブには、PHPの版の判定も出ます。Docker（1台のコンピューターの中に、ほかから切り離した実行環境を作るツール。PCでもサーバーでも使う）で、WordPressは同じでPHPだけが違う2つの検証サイト（修正前の8.3.35と修正版の8.3.36）を作って比べると、この判定はどちらも「推奨バージョン」でした。この記事では、版番号の最後の数字まで見て修正版かを確かめる方法と、レンタルサーバー、VPS（自分で管理する仮想サーバー）、Dockerのそれぞれで修正版にする手順を、検証の結果とともに説明します。

4つの要点

確かめるのはPHPの版の最後の数字。サイトヘルスの「推奨バージョン」の判定は、修正前の版でも出る

修正版の番号

8.5.12 / 8.4.27
8.3.36 / 8.2.35

使っている系列（8.3など）で、この番号以上なら修正済み。8.1以前には、PHPの開発チームからの修正版がない。

確かめる場所

サイトヘルスの「情報」タブ

ツール→サイトヘルス→情報→サーバー→PHP バージョン。「ステータス」タブの「推奨バージョン」は、修正前の8.3.35でも表示された。

番号が古く見える場合

パッケージの番号を見る

UbuntuなどLinuxの配布元が配るPHPは、番号が古いまま修正が入る。Ubuntu 24.04では、表示は8.3.6のままで、更新後のパッケージ（末尾が24.04.13）に修正が入っていた。レンタルサーバーは、サーバー会社のお知らせで確かめる。

環境別にやること

確認・更新・コンテナの作り直し

レンタルサーバーはお知らせとサイトヘルスで確認。VPSはパッケージを更新してPHPを再起動。Dockerはイメージを取り直してコンテナを作り直す。

修正版は8.5.12・8.4.27・8.3.36・8.2.35。8.1以前には開発チームからの修正版がない

PHPの版番号は「8.3.36」のように3つの数字でできています。最初の2つ（8.3）が系列、最後の数字（36）がその系列で何回目の更新かを表します。今回の修正版は系列ごとに次のとおりです。自分の系列で、この番号以上なら修正が入っています。

8.1以前のPHPで動いているサイトは、8.3以上へ切り替えます。8.2にも修正版はありますが、12月31日でサポートが終わります。WordPressのサイトヘルスも、推奨するPHPを8.3以上としています。Ubuntu 22.04のphp8.1のように、配布元が修正を配っているPHPを使っている場合は、パッケージを更新すると今回の2件の修正が入ります（後の節）。

自分のサイトのPHPの版は、サイトヘルスの「情報」タブで最後の数字まで確かめる

サイトヘルスはWordPressに標準で入っている診断画面で、プラグインは要りません。「情報」タブには、そのサイトを実際に動かしているPHPの版が最後の数字まで表示されます。

同じ表の「PHP SAPI」の行には、PHPを動かす方式が出ます。apache2handler ならApacheに組み込む方式（mod_php）、fpm-fcgi ならPHP-FPMです。VPSでPHPを再起動するときに、どちらのサービスを再起動するかの判断に使います。

レンタルサーバーの管理画面でPHPのバージョンを選んでいる場合、そこに「8.3」のように系列だけが表示されるなら、最後の数字はサイトヘルスで確かめます。サイトを複数持っているときは、サイトごとに確かめます。サイトごとに別の系列を選べるサーバーでは、サイトによってPHPの版が違うことがあるためです。

サイトヘルスの「推奨バージョン」は、修正前の8.3.35でも表示された

サイトヘルスの「ステータス」タブの下のほうにある「テスト通過」のボタンを押すと、PHPの版を判定した項目が出ます。修正前の8.3.35と修正版の8.3.36で比べると、どちらも「サイトは推奨バージョンの PHP を実行しています」という問題なしの判定になり、違いは括弧の中の番号だけでした。

WordPress 7.1.3のコードを読むと、この項目は、PHPの版が推奨の系列（8.3）以上なら「推奨バージョン」と判定し、最後の数字は判定に使っていません。推奨の系列は、WordPress.orgの判定API（サイトヘルスが問い合わせる仕組み）から届きます。10月22日18時に、このAPIへ修正前の8.3.35と修正版の8.3.36を問い合わせると、どちらも推奨の系列は8.3という同じ答えでした。今回の修正が入っているかは、版の最後の数字を前の節の番号と比べて確かめます。

Ubuntuなどの配布元が配るPHPは、番号が古いまま修正が入る

VPSなどで、UbuntuやDebianといったLinuxの配布元（ディストリビューション）が用意したPHPを使っている場合は、番号の見方が変わります。配布元は、出荷した版の番号を保ったまま、修正だけを移植して配ることがあるためです。Ubuntu 24.04のコンテナにPHP 8.3を入れて確かめると、php -v の表示は8.3.6でしたが、パッケージの番号は8.3.6-0ubuntu0.24.04.13で、変更履歴の先頭に今回の2件の修正が記録されていました（下の出力は一部を抜粋）。ビルド日が10月21日の公開より前なのは、PHPの公式の告知によると、配布元が公開前に修正を受け取っていたためです。

$ php -v
PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)

$ apt-cache policy php8.3-common
php8.3-common:
  Installed: 8.3.6-0ubuntu0.24.04.13

$ zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -5
php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium

  * SECURITY UPDATE: Remote RCE via state corruption issue
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
      ...

この場合、サイトヘルスにも「8.3.6」と出るので、修正版の8.3.36と比べると古く見えます。修正の有無は、パッケージの番号全体が、配布元のセキュリティ情報に載っている番号と一致するかで確かめます。その後の更新で番号が進んでいる場合は、パッケージの変更履歴に今回のCVE番号があるかを、zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep CVE-2026-109618 で見ます（該当する行が出れば修正入り）。UbuntuのCVE-2026-109618のページでは、24.04のphp8.3は8.3.6-0ubuntu0.24.04.13、22.04のphp8.1は8.1.2-1ubuntu2.28で修正済みとされています。20.04以前の修正は、Ubuntu Pro（延長サポートのサービス）向けに配られています。Ubuntu Proを使っていない場合は、Ubuntu Proの利用か、新しいUbuntuへの移行を検討します。

Ubuntu 22.04のphp8.1のように配布元が修正を配っている場合は、パッケージを更新すれば今回の2件の修正が入ります。PHPの開発チームによる8.1のサポートは終わっているので、8.3以上への切り替えも計画します。サーバー会社が8.1以前のPHPに独自の修正を当てた場合も、番号だけでは見分けにくいので、各社のお知らせで修正の有無を確かめます。

環境別の対応：レンタルサーバーは確認、VPSはパッケージの更新、Dockerはコンテナの作り直し

VPS（Ubuntu・Debian）の例

UbuntuやDebianでは、次のようにパッケージを更新してから、PHPを動かしているサービスを再起動します。どちらのサービスかは、サイトヘルスの「PHP SAPI」の行で分かります。入ったパッケージの番号は、配布元のセキュリティ情報と比べます。php8.3 の部分は、使っている系列に合わせて書き換えます。PHP以外のソフトも新しくなるので、先にバックアップを取り、更新後にサイトが表示されるかを確かめます。

# パッケージを更新する
sudo apt update
sudo apt upgrade

# 入ったパッケージの番号を確かめる
apt-cache policy php8.3-common

# 使っている方のサービスを再起動する
# PHP SAPI が fpm-fcgi の場合
sudo systemctl restart php8.3-fpm
# PHP SAPI が apache2handler の場合
sudo systemctl restart apache2

# 再起動を確かめる（since の時刻を見る）
systemctl status php8.3-fpm   # fpm-fcgi
systemctl status apache2      # apache2handler

再起動したら、サイトヘルスの「情報」タブで版を確かめます。サーバー上の php -v はコマンドライン用のPHPで、サイトを動かしているPHPと別の版のことがあるため、確認はサイトヘルスで行います。配布元のPHPは更新しても番号が変わらないので、パッケージの番号と、サービスを再起動したことの両方を確かめます。

Dockerの例

Docker Hubの公式イメージは修正版で作り直されていて、10月22日に php:8.3-apache と wordpress:latest を取得すると、中のPHPは8.3.36でした。ただし、イメージを取り直しただけでは、すでに動いているコンテナは古いPHPのまま動き続けます。検証では、修正前の8.3.35で起動したコンテナは、イメージを新しくしたあとも8.3.35のままで、作り直すと8.3.36になりました（同じ名前のイメージを新しい版に差し替えて確かめた）。Docker Composeを使っている場合は、次の手順で取り直しと作り直しをまとめて行えます。compose.yaml に build: がある（自分でイメージを作っている）場合は、build のコマンドも実行します。サービス名の wordpress は、自分の compose.yaml に合わせます。

# compose.yaml のあるフォルダで実行する
docker compose pull

# build: がある場合は、これも実行する
docker compose build --pull

# イメージが新しくなったコンテナを作り直す
docker compose up -d

# 版を確かめる（wordpress はサービス名）
docker compose exec wordpress php -v

Composeを使わずに docker run で起動した場合は、コンテナを削除する前に、サイトのファイルやデータベースがボリューム（コンテナの外にデータを残す保存場所）に置かれているかを確かめます。置かれていなければ、先にバックアップを取ります。そのうえで docker pull でイメージを取り直し、コンテナを削除して同じ指定で起動し直します。公式イメージを使った検証サイトでは、コンテナの中の php -v とサイトヘルスに出る版は同じでした。

イメージの指定（タグ）にも注意します。作り直したあとも php -v が修正版の番号（8.3系列なら8.3.36以上）にならなければ、そのタグは修正版で作り直されていません。10月22日に確かめると、WordPress 6.9で固定した wordpress:6.9-php8.3-apache は5月20日から更新されておらず、中のPHPは8.3.31でした。同じ日に wordpress:7.1-php8.3-apache と wordpress:7.1.3-php8.3-apache は作り直されていました。この場合は、先にバックアップを取ってから7.1系のタグに切り替えます。WordPressのファイルをボリュームに置いていない構成では、WordPress本体も7.1系に新しくなります。PHP 8.1の公式イメージ（php:8.1-apache など）は2025年12月31日から更新されていないので、8.3以上のイメージへ移ります。php:8.3.35-apache のようにPHPの版まで固定したタグは、番号を修正版に書き換えます。

すぐ修正版にできないときの一時的な設定（PHPの設定を自分で変えられるサーバー向け）

配布元の修正版がまだ届かない、8.1以前からすぐには移れない、といった理由で入れ替えに時間がかかる場合に向けて、PHPの公式の告知は一時的な設定を挙げています。公式は、修正版への更新だけが完全な対策で、これらの設定は確認された攻撃の経路の一部を防ぐものと説明しています。ここでは、そのうちPHPの設定で指定するものを紹介します。ウェブサーバーやプロキシで受け付ける通信を制限する方法など、ほかの対策は公式のアドバイザリ（CVE-2026-109618、CVE-2026-109619）にまとまっています。

書く場所は、サイトを動かしているPHPの設定ファイルです。Ubuntuでは方式ごとに php.ini が分かれていて、PHP-FPMは /etc/php/8.3/fpm/php.ini、mod_phpは /etc/php/8.3/apache2/php.ini を読みます。コマンドライン用の /etc/php/8.3/cli/php.ini を直しても、サイトには効きません。php.ini を直接書き換える代わりに、同じフォルダの conf.d/ に .ini ファイル（例: /etc/php/8.3/fpm/conf.d/99-php2shell.ini）を足しても読み込まれます。8.3 の部分は、使っている系列に合わせます。ほかの環境では、php --ini はコマンドライン用の場所を表示するので、PHP-FPMなら sudo php-fpm8.3 -i | grep "Loaded Configuration File"（コマンド名は環境によって php-fpm など）で、PHP-FPMが読む php.ini の場所を確かめます。書き換える前に、サイトヘルスの「情報」→「サーバー」にある「PHP POST サイズ上限」の値を控えておきます。

公式は、session.upload_progress.enabled（下の例の1行目の設定）をアプリの中の ini_set() や、PHP-FPMで使う .user.ini（フォルダごとの設定ファイル）で指定しないよう求めています。こうした方法しか使えない共用のレンタルサーバーでは、この節の最後の「設定を変えられないとき・サイトを止めるとき」のとおりサーバー会社の対応を確かめます。

; conf.d に足すファイルの例

; アップロードの進み具合の記録を止める
session.upload_progress.enabled = 0

; 1回の送信の上限（公式の値。下の説明を参照）
post_max_size = 32M

; 1ファイルの上限（post_max_size より小さく）
upload_max_filesize = 16M

; 8.5のみ: エラー時の呼び出し履歴を止める
fatal_error_backtraces = 0

post_max_size の公式の値は、ファイルのアップロードが必要なサイトで32M、不要なサイトで8Mです。WordPressは管理画面から画像などをアップロードするので、多くのサイトは32Mが目安です。upload_max_filesize を16M（例）にすると、16MBを超えるファイルはメディアに上げられなくなります。fatal_error_backtraces は、致命的なエラーが起きたときに呼び出し履歴（バックトレース）を記録するPHP 8.5の設定です。

公式のアドバイザリは、アップロードの進み具合を記録する機能（session.upload_progress）を使っていないなら、修正版にしたあとも0のままにするよう勧めています。WordPress 7.1.3の本体のPHPコードには、この機能を使う箇所はありませんでした。プラグインが使っているかは、各プラグインの説明やコードで確かめます。

php.ini の代わりに、PHP-FPMのプールの設定ファイルやApacheの設定に書くこともできます。サイトごとに設定を分けたい場合や、アプリから上書きできない書き方（php_admin_value、php_admin_flag）にしたい場合です。書式はそれぞれ次のように変わります。

; PHP-FPMのプールの設定ファイル
; upload_max_filesize なども同じ形で書く
; fatal_error_backtraces は 8.5 のときだけ
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 32M

# Apacheの設定（mod_php）
# upload_max_filesize なども同じ形で書く
# fatal_error_backtraces は 8.5 のときだけ
php_admin_flag session.upload_progress.enabled off
php_admin_value post_max_size 32M

Apacheの設定は、Ubuntuなら /etc/apache2/conf-available/ に .conf ファイル（例: php2shell.conf）を置き、sudo a2enconf php2shell で有効にします。

メモリの上限をなくす設定（memory_limit = -1）

1つ目の脆弱性（CVE-2026-109618）は、PHPがメモリ不足になったときの処理にあります。そのため公式は、PHPのメモリ上限をなくす memory_limit = -1 も挙げ、アプリから上書きできない書き方（php_admin_value）で指定するよう勧めています。

使っている方式（サイトヘルスの「PHP SAPI」の行）に合わせて、どちらか一方を書きます。PHP-FPMのプールの設定ファイルは、Ubuntuでは /etc/php/8.3/fpm/pool.d/www.conf などです。

; PHP-FPMの場合（プールの設定ファイル）
php_admin_value[memory_limit] = -1

# mod_php の場合（Apacheの設定）
php_admin_value memory_limit -1

memory_limit = -1 にすると、PHP自身は1回の処理で使うメモリを制限しなくなります。公式は、PHPの外側で、コンテナやcgroup（Linuxでプロセスのまとまりにメモリなどの上限を設ける仕組み）によってメモリの上限を設ける方法も挙げています。アドバイザリはこれを、PHP自身の上限の代わりになりうる方法として挙げていますが、メモリの確保の失敗を確実に防げるとは限らず、上限に達したときにPHPのすべての処理がまとめて止まることもある、と注意しています。RLIMIT_AS や RLIMIT_DATA（プロセスごとに使えるメモリの量を決めるOSの制限）は、上限に達したときに今回の欠陥の引き金になるので使わないよう求めています。自分のサーバーでは、memory_limit = -1 を指定する、コンテナやcgroupで上限を設けるかを検討する、上限を設けるときに RLIMIT_AS や RLIMIT_DATA は使わない、の3つを行います。設定が効いているかは、サイトヘルスの「情報」→「サーバー」の「PHP メモリ上限」の行が -1 になっているかで確かめられます（検証サイトで確認）。

設定を反映させて確かめる

設定を書き換えたら、再起動の前に sudo php-fpm8.3 -t（PHP-FPM）や sudo apachectl configtest（Apache）で書式を確かめます。書式を誤ると、PHP-FPMやApacheが起動しなくなることがあります。そのうえで、PHPを動かしているプロセスをすべて再起動します（再起動のコマンドは「VPS（Ubuntu・Debian）の例」）。検証サイト（PHP 8.3.35、ApacheにPHPを組み込む方式）でも、設定ファイルを置いただけでは値が変わらず、Apacheを再起動したあとに session.upload_progress.enabled が0になりました。

効いたかは、書いた場所に関係なく、サイトヘルスの「情報」→「サーバー」で確かめられます。session.upload_progress.enabled の行はサイトヘルスにはありませんが、同じ場所に書いた post_max_size が「PHP POST サイズ上限」に書いた値（例: 32M）で出ていれば、その場所の設定と再起動が反映されています。控えておいた前の値から変わったことを確かめます。前と同じ値を書いた場合は変化が見えないので、この方法では確かめられません。memory_limit を変えた場合は、「PHP メモリ上限」が -1 になっていることを見ます。php.ini や conf.d に書いた場合は、sudo php-fpm8.3 -i | grep upload_progress でも確かめられます。Ubuntu 24.04の検証では、fpm の conf.d に設定を足すとこの表示は Off（0 を指定したときの表示）になり、コマンドライン用の php -i は On のままでした。PHP-FPMのプールに書いた設定は、この方法では表示に出ないので、サイトヘルスで確かめます。

設定を変えられないとき・サイトを止めるとき

共用のレンタルサーバーで、サーバー全体の設定を変えられない場合は、サーバー会社のお知らせで、修正版への入れ替えの予定を確かめます。お知らせがない場合や、サイトヘルスの版が修正版より低いままの場合は、サーバー会社に問い合わせます。IPAは、効果的な対策を取れない場合、想定される被害を踏まえて、外部からのアクセスの遮断やサービスの停止も検討するよう求めています。止めるときは、PHPに通信が届く前の段階で止めます。たとえば、サーバー会社の管理画面でサイトを停止する、ウェブサーバーやファイアウォールで接続元を制限する、といった方法です。WordPressのメンテナンスモードのプラグインは、PHPが通信を受け取って処理を始めたあとに働くので、今回の欠陥を防ぐ目的には使えません。

自分のサイトが修正済みかを判断する順番

サイトヘルスの「推奨バージョン」は、PHPの版が推奨の8.3以上であることを示す表示です。今回の修正が入っているかは、版の最後の数字か、配布元のパッケージの番号で確かめます。レンタルサーバーを使っているなら、まずサーバー会社のお知らせにある更新後の版と、サイトヘルスの「情報」タブの版が合っているかを見るところから始めます。

参考資料

• PHP「News Archive 2026」（2026年10月20〜21日の事前告知、Security advisory、各修正版の公開）。修正版の番号、影響する方式、一時的な設定、8.1以前の扱い、8.2のサポート終了日。
• GitHub php/php-src「RCE via OOM corruption」（CVE-2026-109618、2026年10月21日）。影響する版と修正版、一時的な設定。
• GitHub php/php-src「RCE via stale global state」（CVE-2026-109619、2026年10月21日）。影響する版と修正版、一時的な設定。
• IPA「PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)」（2026年10月22日）。修正版、8.1以前の扱い、すぐ更新できない場合の対応。
• Ubuntu「CVE-2026-109618」。Ubuntuの各版で修正済みとなったパッケージの番号。
• WordPress.org「Serve Happy API」。サイトヘルスが問い合わせるPHPの版の判定（例は8.3.35を問い合わせるURL）。
• WordPress開発リポジトリ「class-wp-site-health.php（7.1.3）」。サイトヘルスのPHPの版の判定（get_test_php_version）。
• Docker Hub「php」「wordpress」。公式イメージのタグと更新日時。
• Docker Docs「docker compose up」。イメージが変わったサービスのコンテナを作り直す動作。