1 サーバー上のすべての PHP を把握する

多くのサーバーでは複数の PHP が動いています。システムパッケージ、コントロールパネルがインストールしたバージョン（cPanel EA-PHP、Plesk、CWP/CloudLinux alt-php、DirectAdmin）、コンテナ、cron が使うコマンドライン版などです。ウェブリクエストを処理するものはすべて更新する必要があります。

php -v を実行し、ps aux | grep php-fpm で php-fpm プロセスを一覧表示し、パネルの PHP セレクターを確認してください。

2 修正済みバージョンに更新する

アップストリームの修正済みバージョンは 8.5.12、8.4.27、8.3.36、8.2.35 です。ディストリビューションのパッケージは古いバージョン番号のまま修正を含んでいる場合があります。変更履歴で CVE-2026-109618 と CVE-2026-109619 を確認してください。

PHP 8.1 以前は PHP プロジェクトからのリリースがありません。ソースからビルドする方向けに 7.4、8.0、8.1 用の最小限のソースバックポートが公開されていますが、恒久的な対策はサポート対象ブランチへの移行です。

Debian / Ubuntu（ディストリビューションのパッケージ）

ディストリビューションのセキュリティ更新をインストールし、PHP を再起動します。バージョン番号は変わらない場合がありますが、パッケージの変更履歴に CVE が記載されます。

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

お使いの PHP モジュールストリーム向けのベンダーのエラータを適用し、再起動します。

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / 公式 php イメージ

修正済みのタグで取得または再ビルドし、コンテナを作り直します。

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel、Plesk、CWP、DirectAdmin

インストールされているすべての PHP バージョン（EA-PHP、Plesk PHP ハンドラー、alt-php、CustomBuild）に対してパネルの更新ツールを使い、PHP-FPM を再起動します。パネルは個別のサイト用に古いバージョンを残していることがよくあります。それらも更新するか削除してください。

共有ホスティング / マネージドホスティング

通常、PHP をご自身で更新することはできません。結果カードのメッセージを使い、正確なバージョン、修正日、ワーカーが再起動されたことの確認をプロバイダーに依頼してください。

Windows / IIS

windows.php.net から修正済みビルドをダウンロードし、PHP ディレクトリを置き換えて、IIS アプリケーションプールをリサイクルします。

3 すべての PHP プロセスを再起動する

パッケージをインストールしても、すでに実行中のコードは変わりません。PHP-FPM、Apache（mod_php の場合）、LiteSpeed、FrankenPHP、キューワーカー、スーパーバイザーを再起動してください。コンテナの場合は、新しいイメージを再ビルドまたは取得してください。同じイメージを再起動してもパッチは適用されません。

4 確認する

各バイナリで php -v を実行し、実行中のプロセスが新しいビルドを使っていることを確認してください（例えば ls -l /proc/$(pgrep -o php-fpm)/exe の出力に「deleted」が含まれていないこと）。その後、このチェッカーをもう一度実行してください。

5 今日中に更新できない場合

更新できるまで、以下の部分的な緩和策を適用し、サイトにアクセスできる範囲を制限してください。これらはリスクを下げますが、なくすものではありません。

6 侵害の兆候を確認し、秘密情報を変更する

脆弱なサイトがインターネットから到達可能だった場合は、2026 年 10 月 20 日以降の活動を確認してください。PHP-FPM または Apache のエラーログにある PHP ワーカーのクラッシュ（SIGSEGV）、ウェブルート内の新規または変更された PHP ファイル、新しい cron ジョブ、新しい管理者アカウント、予期しない外部への接続などです。

CVE-2026-109619 はコードを一切実行せずに PHP プロセスのメモリを漏えいさせる可能性があるため、ファイルシステムに異常がなくても、何も漏れていない証拠にはなりません。攻撃にさらされていたサイトについては、データベースのパスワード、API キー、決済とメールの認証情報を変更し、ユーザーのセッションを無効にしてください。

7 更新後に

この修正では新しいハードメモリ制限が導入されます。制限に達したプロセスは即座に終了され、シャットダウンハンドラーは実行されません。メモリが逼迫したときのアプリケーションの挙動を確認し、memory_limit を post_max_size および max_input_nesting_level と合わせて見直し、パッチ適用前に一時的に設定した memory_limit = -1 があれば元に戻してください。expose_php = Off でバージョンを隠すことは任意の強化策であり、修正ではありません。

部分的な緩和策（php.net およびアドバイザリより）

これらは既知の攻撃経路を狭めるだけです。php.net は、更新が唯一の安全な選択肢であると述べています。

; php.ini / FPM pool (php_admin_value) — 設定後はすべてのワーカーを再起動
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M アップロードが必要な場合
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

これらは php.ini、PHP-FPM プール（php_admin_value）、またはサーバー設定で指定してください。ini_set() や .user.ini では設定しないでください。設定後はワーカーを再起動してください。アドバイザリと研究チームによるその他の対策：

memory_limit = -1 は PHP 自身のメモリ制限に依存する一部の経路を防ぎますが、メモリ枯渇の処理をオペレーティングシステムに委ねることになります。必ず cgroup v2 の memory.max 制限と組み合わせて使用してください。RLIMIT_AS や RLIMIT_DATA は使用しないでください。同じ脆弱な経路を引き起こす可能性があります。
max_input_nesting_level をフォームが許す範囲でできるだけ低くしてください。
PHP-FPM の pm.max_requests を低くし、ワーカーがより頻繁に入れ替わるようにしてください（性能面のコストがあります）。
ウェブサーバーまたはプロキシでリクエストサイズ、フィールド数、ネストの深さを制限し、無効または非推奨のリクエスト単位の INI 設定を削除してください。
SELinux や AppArmor のポリシーで、侵害されたワーカーが実行できる内容を制限できます。影響を小さくするものであり、メモリの漏えいを防ぐものではありません。

参考資料

出典：php.net セキュリティアドバイザリ（2026 年 10 月 21 日）。最終確認日 2026-10-23。