WordPressのサイトや自社の問い合わせフォームがPHPで動いているが、サーバーのPHPがいま何版なのか、誰が更新する決まりなのかがはっきりしない。今回の脆弱性は、その状態のまま放置しにくい内容です。PHPの公式の告知は、対象を「Webのリクエストを処理しているすべてのPHP」とし、アプリケーションのコードが動く前に、認証なしのリクエストで攻撃が始まる例を示しています。
PHPの開発チームは2026年10月21日、2件の脆弱性（CVE-2026-109618、CVE-2026-109619）を直した 8.5.12・8.4.27・8.3.36・8.2.35 を公開しました。告知の冒頭は次のとおりです。
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.
公式の告知と、手元のPHPで設定の扱いを確かめた結果から、サイトの保守担当者が今日確かめることを整理します。
何が直ったのか
公式の告知によると、2件はどちらも「認証なしでの遠隔コード実行（RCE）」につながりうる不具合です。
- CVE-2026-109618（GHSA-w8hw-w9fx-j79w）：メモリ不足の処理が、リクエストの内部データを作りかけの状態で中断させ、後片付けの処理がその不正なデータを正しいものとして扱うおそれがある
- CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）：リクエストに属する内部の状態が、メモリを解放した後も残り、同じワーカーが次に処理するリクエストがそれを使ってしまうおそれがある
影響を受ける構成として、告知は PHP-FPM、Apacheの mod_php、php-cgi、FrankenPHP、LiteSpeed を挙げ、mod_php が最も危険だとしています。GitHub のアドバイザリによると、完全な攻撃が確かめられたのは主に mod_php ですが、GHSA-6wmf-4rv5-p3rp ではアプリケーション側の条件しだいで PHP-FPM でも成り立つ経路も確かめられています。FPM だから後回しにしてよい、とは言えません。深刻度は、前日（10月20日）の予告とアドバイザリのどちらでも、2件とも CVSS v4.0 で 9.2 です。
Google Cloudの10月21日のブログは、影響を受ける版を「PHP 5.4 から 8.5.11 まで」と書いています。これはGoogleによる整理で、php.net の告知には同じ範囲の記載はなく、アドバイザリも各系列の修正版より前の版とだけ書いています。
予告では公開を10月21日 14:00 UTC（日本時間23:00）としていましたが、アドバイザリの公開は 13:34 UTC（日本時間22:34）で、予告より少し早く出ました。php.net の変更履歴（ChangeLog）では4つの版とも日付が10月22日になっていますが、告知とアドバイザリの日付は10月21日です。
どの版に上げるか
| 系列 | 修正版 | 補足 |
|---|---|---|
| 8.5 | 8.5.12 | 緩和策の1つ（fatal_error_backtraces）はこの系列だけ |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | 告知によると、2026年12月31日でセキュリティ修正が終わる |
| 8.1以前 | PHPプロジェクトからは出ない | 7.4・8.0・8.1向けに、修正だけを移した最小限のソースのブランチが公開された |
8.1以前について、告知は提供元への問い合わせか、サポート中の版への更新を求めています。7.4〜8.1向けのブランチはソースから自分でビルドする人向けです。8.2は年末で修正が終わるため、8.3以降への移行も同時に計画します。
OSのパッケージは「版の数字」で判断できない
告知には「Linuxのディストリビューションには事前にパッチが渡されている」とあります。ここで注意したいのは、OSのパッケージのPHPは、修正を取り込んでも版の数字が変わらないことが多い点です。
編集部の検証環境（Ubuntu 24.04）に入っていたPHPは php -v で「8.3.6」と表示され、パッケージの版は 8.3.6-0ubuntu0.24.04.12 でした。このパッケージの変更履歴（/usr/share/doc/php8.3-cli/changelog.Debian.gz）を開くと、2026年10月7日付の更新に9月の修正（CVE-2026-91768 など）が取り込まれていましたが、今回の CVE-2026-109618・109619 は含まれていませんでした。
Ubuntuは10月21日のセキュリティ情報（USN-8948-1）で、24.04向けに 8.3.6-0ubuntu0.24.04.13 を出しています。修正後も php -v の表示は「8.3.6」のままで、変わるのはパッケージの版の末尾だけです。数字だけでは安全とも危険とも言えず、確かめる先はパッケージの版と変更履歴です。10月22日の時点で、各ディストリビューションの公式の情報には次の版が載っていました。
- Ubuntu 26.04 LTS：php8.5 の
8.5.4-0ubuntu1.5 - Ubuntu 24.04 LTS：php8.3 の
8.3.6-0ubuntu0.24.04.13 - Ubuntu 22.04 LTS：php8.1 の
8.1.2-1ubuntu2.28 - Debian 13（trixie）：php8.4 の
8.4.27-1~deb13u1（DSA-6574-1） - Debian 12（bookworm）：php8.2 の
8.2.35-1~deb12u1（DLA-4848-1）
Ubuntuのパッケージ置き場（Launchpad）で公開されている 8.3.6-0ubuntu0.24.04.13 の変更履歴には、CVE-2026-109618 と CVE-2026-109619 が載っています。編集部の検証環境を実際にこの版へ更新しての確認はしていません。
# Debian・Ubuntu系：入っているPHPのパッケージに、今回のCVEの修正が入っているか
zcat /usr/share/doc/php8.3-cli/changelog.Debian.gz | grep -E "CVE-2026-10961[89]"何も表示されなければ、そのパッケージには入っていません。
RHEL系で、有志が運営する追加リポジトリ rpms.remirepo.net のPHPを使っている場合について、告知は「当日は更新が出ない」として、ディストリビューションのパッケージかソースからのビルドに切り替えるよう求めています。10月22日時点のこのリポジトリの更新状況は確認していません。
運用の形ごとに、誰が何をするか
ここからは編集部の整理です。
| 運用の形 | 確かめること |
|---|---|
| 共用のレンタルサーバー | 事業者が告知を出しているか。管理画面で選べるPHPの系列と、その系列に修正が入ったか。8.1以前を選んでいるなら系列の変更 |
| VPS・専用サーバー | OSのパッケージの更新と、変更履歴でのCVEの確認。PHP-FPMやApacheなど、PHPを動かしているプロセスすべての再起動 |
| コンテナ（Docker・Cloud Run など） | 土台のイメージを修正版で作り直し、デプロイし直す。作り直さない限り古いイメージのまま |
Google Cloudのブログによると、App Engineのスタンダード環境（PHP 8.2以降）は自動で更新され、Cloud Run と Cloud Run functions は「ベースイメージの自動更新」を有効にしていれば自動、それ以外は作り直しとデプロイが必要です。App Engineのフレキシブル環境は自動では更新されません。自分で作ったコンテナのイメージは利用者の責任だと明記されています。
制作会社に保守を任せている場合は、更新の作業がどちらの担当かを、この機会に書面で確かめておきます。管理型のホスティングで、提供元による更新を版の表示で確かめた実例は、PHPの緊急セキュリティ修正 管理型ホスティングとCMSクラウド版での対応記録で記録しています。
すぐ上げられない場合の緩和策と、その限界
告知は、更新だけが完全な解決策だとしたうえで、特定の攻撃の経路を減らす設定を挙げています。どれも「安全にはならない」と明記されています。主なものは次のとおりです。
- CVE-2026-109618：
memory_limit=-1を、アプリケーションが上書きできない形（FPMのプールやApacheの設定のphp_admin_value）で設定する。post_max_sizeを下げる（アップロードが不要なら 8M、必要なら 32M。upload_max_filesizeはそれより小さく）。Webサーバーやプロキシでリクエストの大きさ・項目数を制限する - CVE-2026-109619：
session.upload_progress.enabled=0を php.ini・FPMのプール・サーバーの設定で指定し、すべてのワーカーを再起動する（ini_set()や FPM の.user.iniには頼らない）。PHP 8.5 ではfatal_error_backtraces=0も
「アプリケーションが上書きできない形で」の意味を、手元のPHP 8.3.6（コマンドライン版）の ini_get_all() と ini_set() で確かめました。
memory_limit は、アプリケーションのコードから ini_set() で変えられる設定でした。php.ini で -1 にしても、アプリケーションやプラグインが有限の値に戻せます。告知が php_admin_value を指定し、「有限の値を戻す設定がないか確認する」と書いているのはこのためです。WordPress本体のコード（wp-includes/default-constants.php）を読むと、現在の上限が -1 のときは上限を書き換えない作りでしたが、テーマやプラグインがどう扱うかは別に確かめる必要があります。
残りの3つは実行中には変わりませんでしたが、.htaccess や .user.ini でも変えられる種類の設定です。共用サーバーで利用者が触れるのはこの層のため、告知の条件（リクエストの解析より前に効く場所）を満たすかは事業者に確認します。アドバイザリ（GHSA-6wmf-4rv5-p3rp）によると、mod_php の .htaccess の設定はリクエストの処理が始まる前に適用される一方、FPM の .user.ini は通常の初期化の後に適用されます。
設定を確かめるときは、次のような小さなスクリプトを、Webサーバー経由（PHP-FPMやmod_phpで実行される場所）で一時的に置いて見るのが確実です。コマンドラインのPHPは別の php.ini を読むことがあり、上の検証でも、コマンドライン版の memory_limit は php.ini の指定で -1、設定ファイルなしでは 128M でした。確認が終わったらすぐに削除します。
<?php
// 版と、緩和策に関係する設定を表示する（確認後はすぐに削除する）
echo PHP_VERSION, ' / ', PHP_SAPI, "\n";
foreach (['memory_limit', 'post_max_size', 'upload_max_filesize',
'session.upload_progress.enabled', 'fatal_error_backtraces'] as $k) {
$v = ini_get($k);
echo $k, ' = ', $v === false ? '(この版にはない設定)' : $v, "\n";
}
echo 'php.ini: ', php_ini_loaded_file() ?: '(なし)', "\n";緩和策は更新までのつなぎです。アップロードの上限を下げるとフォームが動かなくなることもあるため、入れた設定は記録し、更新後に戻すかを決めます。なお session.upload_progress.enabled=0 について、アドバイザリは、この機能を使っていないなら更新後も無効のままにしておくのが賢明かもしれない、としています。
WordPressの更新の確かめ方はWordPress 7.1.2の修正は届いたか、本体の緊急の脆弱性への初動はWordPress本体の緊急脆弱性「wp2shell」、サーバーのOSごと上げる場合はUbuntu 24.04→26.04.1の更新で扱っています。
確認した範囲
2026年10月22日に、php.net のニュース（10月20日の予告と21日の告知）と変更履歴（ChangeLog）、GitHub の php/php-src のアドバイザリ2件、告知の原稿（php/web-php リポジトリの
public/archive/entries、include/version.inc、include/branches.inc）、PHP本体（php/php-src）の PHP-8.2〜8.5 の各ブランチの NEWS と修正版のタグ・7.4〜8.1向けのブランチの存在、Ubuntu のセキュリティ情報（CVEのページ、USN-8948-1）と Launchpad の php8.3 の変更履歴、Debian のセキュリティトラッカーと DSA-6574-1、Google Cloudのブログ「Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619」、WordPress本体（wordpress-develop）のdefault-constants.phpを確認しました（資料調査）。あわせて、編集部の検証環境（Ubuntu 24.04、パッケージ版のPHP 8.3.6のコマンドライン版）で、各設定の変更できる場所とini_set()の結果、パッケージの変更履歴を確認しました（実機検証）。脆弱性の再現は行っていません。発見者（Wiz Research）の解説、NVD、RHEL系のディストリビューションと rpms.remirepo.net の更新状況は確認していません。PHP-FPM・mod_php でのphp_admin_valueの動作、修正版のパッケージに更新しての動作、各レンタルサーバー事業者の対応状況も確認していません。
PHPで動くサイトや業務システムの更新・保守の体制の見直しは、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- Security advisory: Critical remote code execution vulnerabilities, update now（php.net、2026-10-21）
- Upcoming Critical PHP Security Release（php.net、2026-10-20）
- PHP 8 ChangeLog（php.net）
- GHSA-w8hw-w9fx-j79w: RCE via OOM corruption（php/php-src）
- GHSA-6wmf-4rv5-p3rp: RCE via stale global state（php/php-src）
- php/web-php（php.net のソース）
- php/php-src NEWS（PHP-8.4 ブランチ）
- USN-8948-1: PHP vulnerabilities（Ubuntu）
- CVE-2026-109618（Debian Security Tracker）
- Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619（Google Cloud Blog）
- wordpress-develop: src/wp-includes/default-constants.php
