2026年10月21日、PHP開発元は、認証なしのリモートコード実行（RCE）につながる可能性がある2件の重大な脆弱性を公表しました。国内では10月22日にIPAとJPCERT/CCが注意喚起しています。これらは「PHP2Shell」とも呼ばれています。
- CVE-2026-109618：メモリ不足（OOM）時のエラー処理に関連するメモリ破損
- CVE-2026-109619：リクエスト処理後に残る内部状態に関連する問題
本記事では、Linuxサーバーを運用する際に行う影響確認、RPM更新、Apache/PHP-FPMの判別、更新できない場合の暫定対策、ログ監視を整理します。コマンドは一般化した例であり、個別の組織・サーバーを特定する情報は含めていません。
影響を受けるPHPと修正バージョン
| PHP系列 | PHP開発元の修正リリース |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
PHP 8.1以前はPHP開発元のサポート終了系列です。古いPHP 5.4、7.1、7.2、7.4なども、単に今回の表にないから安全という意味ではありません。ディストリビューションや有償サポート提供元によるバックポートの有無を確認し、原則としてサポート対象系列への移行を計画します。
※私の環境ではCentOS 7.xにおいて、yumから今回のパッチが提供されていることを確認しました。本文下のほうにyumでの検索方法を記載してます。
重要：RHEL系RPMでは、表示されるPHP本体のバージョン番号が古くても、配布元がセキュリティ修正をバックポートしている場合があります。php -vだけで修正済みかを断定せず、RPMのリリース番号、changelog、配布元アドバイザリを確認してください。
1. OSとPHPのインストール状況を棚卸しする
cat /etc/redhat-release
php -v
rpm -qa | grep -E '^php|^oniguruma5php' | sort
rpm -q php php-cli php-common php-fpm
rpm -qi php-common | grep -E 'Vendor|Packager|Build Date'
Rocky Linux 9では、標準AppStreamのPHPなのか、RemiリポジトリのPHPなのか、あるいはSCL形式の別系列が共存しているのかを確認します。php -vはCLIのPHPを示すため、Webサーバーが実際に読み込むPHPと一致するとは限りません。
2. Apacheのmod_phpかPHP-FPMかを確認する
httpd -M 2>/dev/null | grep -Ei 'php|proxy_fcgi|cgi'
systemctl status php-fpm --no-pager
ps -ef | grep '[p]hp-fpm'
php_moduleが有効ならmod_php、proxy_fcgi_moduleとPHP-FPMの組み合わせならFastCGI経由の可能性があります。ただしモジュール一覧だけで断定せず、VirtualHost、Handler、FPMプール設定まで確認してください。
mod_phpの実体を確認したい場合は、Apacheの設定とロード済みモジュールを調べます。PHP開発元は、今回の問題についてmod_phpを特に高リスクな構成として挙げています。
3. 更新パッケージの提供状況を確認する
dnf repolist --enabled
dnf module list php
dnf --refresh check-update 'php*'
dnf update --assumeno 'php*'
実際に適用する前に、対象RPMと依存関係を確認します。Remiを使う場合は通常のphp-*と、php74-php-*などの別パッケージ系列を混同しないようにします。
修正のバックポートがあるかを調べる例：
dnf repoquery --available --changelogs php \
| grep -i -B 8 -A 8 -E 'CVE-2026-109618|CVE-2026-109619'
検索結果が空でも、直ちに「未修正」とは断定できません。実際に使用するパッケージのchangelogや配布元のセキュリティ情報も照合します。
4. 更新後に確認すること
事前に設定ファイルとバックアップ、停止可能時間を確認し、検証環境で互換性を調べてから更新します。更新後はWebサーバーとPHP-FPMの必要な再起動を行い、古いワーカープロセスが残っていないか確認します。
php -v
rpm -q php-common php-cli php-fpm
httpd -t
systemctl status httpd php-fpm --no-pager
サービス構成に応じてHTTP応答、PHP実行、ログイン、ファイルアップロード、DB接続、定期処理を確認します。CLIだけ更新され、Web側で古いPHPが動き続ける事態を避けます。
5. 更新できない古いPHPの対応
CentOS 7などサポートが終了したOSや、PHP 5.x・7.xを利用している場合は、最新系列への移行を優先します。独自にRPMを置き換える場合はABI・依存関係・アプリ互換性に注意が必要です。
PHPを使用していないWebサイトなら、ApacheのPHP HandlerやPHP-FPM/CGI経路を無効化できるか確認します。ただしmod_phpを外しただけでは、別のHandler経由でPHPが動く可能性があります。PHPソースがそのまま配信されないかを含めて検証し、不要なPHPへのアクセスは拒否してください。
PHPが必要なのに更新できない場合は、公開範囲の縮小、アクセス元制限、代替サービスへの切り替え、公開停止を含めて判断します。
6. 公式アドバイザリにある暫定緩和策
以下は修正パッチの代替ではありません。 PHP開発元は、完全な対策は更新のみとしています。
memory_limit=-1
今回のOOM処理経路に対する緩和策の一つとして、PHP開発元はmemory_limit=-1を、アプリケーション側で上書きできない形で設定する方法を案内しています。ただしPHPのメモリ使用量が無制限になり得るため、OS・コンテナ側の適切なメモリ制限、監視、可用性への影響評価が不可欠です。通常運用で無条件に推奨する設定ではありません。
PHP-FPMのプール設定例：
php_admin_value[memory_limit] = -1mod_phpのサーバー設定例：
php_admin_value memory_limit -1実際に適用する場合は対象PHPの設定方法を確認し、設定反映後にワーカーを再起動してください。
アップロードサイズを制限する
post_max_size = 8M
upload_max_filesize = 2Mこれはアップロードが不要なアプリケーション向けの設定例です。業務要件に応じて調整し、upload_max_filesizeはpost_max_sizeより小さくします。リバースプロキシやWebサーバー側のリクエストサイズ制限も検討します。
session.upload_progressを無効化する
session.upload_progress.enabled = OffこれはCVE-2026-109619の確認済み攻撃経路の一部を緩和する設定です。php.iniやサーバー側設定で、リクエスト解析前に有効になるように指定し、全ワーカーを再起動します。これだけで脆弱性全体を解消できるわけではありません。
7. FortiGate IPSやWAFで補助的に防御する
境界機器のIPS/WAFは、更新までの補助策として検討できます。シグネチャの有無、IPS定義の更新状況、対象Webサーバーへ向かうポリシーへの適用状況を確認します。
diagnose autoupdate versionsHTTPS通信の場合、構成によっては復号やWebアプリケーション層の検査が必要です。シグネチャをBlockにしただけで、すべての攻撃を検知・遮断できるとは限りません。検知ログがないことも「攻撃されていない」証明にはなりません。
※FortiGateではIPSの中に、CVE-2026-109618とCVE-2026-109619に対応したパターンが入っていることを確認しました。
下記シグネイチャーをIPSから検索したら出てきます。
CVE-2026-109618が「PHP.longjmp.Remote.Code.Execution」
CVE-2026-109619が「PHP.stale.global.state.Remote.Code.Execution」
8. Apache・PHPのログを調べる
対策と並行して侵害の兆候も確認します。ログの保存場所や形式は環境に合わせて読み替えてください。
# POSTリクエストの確認
grep '"POST ' /var/log/httpd/access_log | tail -n 100
# 5xx応答の確認（一般的なcombined形式を想定）
awk '$9 ~ /^5[0-9][0-9]$/ {print}' /var/log/httpd/access_log | tail -n 100
# Apacheエラーの確認
tail -n 200 /var/log/httpd/error_log
# OOM関連の確認
journalctl -k --since '2026-10-21' | grep -Ei 'out of memory|oom|killed process'
通常と異なるPOSTの急増、5xx、PHP/Apacheワーカーの異常終了、OOM、Webサーバー権限での不審なプロセス起動などを時系列で確認します。ただし、これらの兆候だけで今回の脆弱性の悪用と断定することはできません。
必要に応じてauditdなどでWebサーバー権限によるプロセス起動を監査します。監査ルールの導入はログ量・性能・権限設計に影響するため、検証してから適用してください。
9. 実務向け対応チェックリスト
- 対象OS・PHPバージョン・RPM配布元を棚卸しする
- CLIとWebで使用されるPHPの違いを確認する
- mod_php・PHP-FPM・CGIの経路を確認する
- 公式修正版または配布元バックポートの有無を確認する
- 更新前バックアップと切り戻し方法を準備する
- 更新後にワーカー再起動とアプリ動作確認を行う
- 古いPHPの停止・隔離・移行計画を行う
- IPS/WAF・アクセス制限など補助策を行う
- FWでのアクセス制限の厳格化を行う。
- アクセスログ、エラーログ、OOM、不審なプロセスを確認できるようにする
- サーバー用ウィルススキャンソフトを入れることを検討する
まとめ
2026年10月のPHP脆弱性では、まず「どのサーバーで、どのPHPが、どの方式でWebリクエストを処理しているか」を把握することが重要です。php -vだけで判断せず、ApacheのHandler、PHP-FPM、RPM配布元、バックポートの有無まで確認します。
暫定設定やFortiGate IPSはリスクを減らす補助策であり、根本対策は修正済みPHPへの更新です。サポート終了系列は、更新困難な事情も含めて移行・公開制限・停止を検討してください。
コメント