PHP CVE-2026-109618・CVE-2026-109619の影響と対策

PHPコアエンジンの異常終了およびリクエスト状態管理の過程で、認証なしにリモートコード実行（RCE）が可能になるCVE-2026-109618、CVE-2026-109619の脆弱性が公開されました。この問題はWordPressやグヌボードのようなWebアプリケーションではなく、PHP実行エンジン自体のメモリ破損および解放後使用（Use-After-Free）の欠陥に起因します。問題を解決するには、PHP 8.5.12、8.4.27、8.3.36、8.2.35など、セキュリティパッチが適用されたバージョンへ直ちにアップグレードし、ワーカープロセスを再起動する必要があります。

Webアプリケーションの更新だけでは防げないPHPエンジンの脆弱性

2026年10月21日（UTC）、PHP開発チームはCVSS v4.0基準で危険度9.2とされる2件のセキュリティ脆弱性を発表しました。攻撃者は別途ログインすることなく、細工したHTTPリクエストを送信するだけで、サーバー上で任意のコードを実行できます。

この欠陥は、Webリクエストを解析し、メモリを解放するPHPコア層で発生します。そのため、サイトのCMSやプラグインを最新に保っていても、PHPランタイム自体が旧バージョンであれば攻撃にさらされます。特にApacheのmod_phpの既定の設定環境では、Webアプリケーションのコードが実行される前に、1回のリクエストだけでコードを実行できることが確認されています。

攻撃に成功すると、侵入者はPHPプロセスが実行されているシステムアカウントの権限を取得します。直ちにroot（root）権限を奪取するわけではありませんが、WebルートディレクトリにWebシェルを作成したり、設定ファイルに記録されたデータベース接続情報を閲覧して内部データを流出・改ざんしたりできます。1台のサーバーで複数のWebサイトが同じPHP-FPM実行アカウントを共有している場合、1つのサイトへの侵害がサーバー内の他のサイトへ拡大するリスクもあります。

異常終了時に発生するメモリ破損と解放後使用の仕組み

2つの脆弱性はいずれも、リクエスト処理中に例外的な状況が発生した際、メモリを安全に解放できないことで発生します。発生条件と内部動作の仕組みはそれぞれ異なります。

CVE-2026-109618（メモリ制限超過の処理中に発生するメモリ破損）： PHPはリクエストの処理中に許可されたメモリ制限（Out-Of-Memory）を超過すると、longjmp()を呼び出して実行を直ちに中断します。このとき、内部のリクエストデータ構造がまだ完全に初期化されていない状態で処理が停止すると、不完全な状態がロールバックされずに残ります。その後に実行されるリクエスト解放（cleanup）ルーチンが、この未初期化メモリを正常なデータとして信頼してアクセスすることで、メモリ破損とリモートコード実行につながります。

CVE-2026-109619（以前のリクエストで解放されたメモリを参照するUse-After-Free）： PHP内部の一部のグローバル状態やエラー処理状態は、単一のリクエストが所有するメモリ領域を一時的に指し示します。致命的なエラー（fatal error）やメモリ不足によってリクエストが異常終了した際、実際のメモリは解放されたにもかかわらず、それを指す内部ポインター参照が初期化されずに残る場合があります。PHP-FPMやmod_phpのようにワーカープロセスを再利用する環境で、同じワーカーが次のHTTPリクエストを受けて処理すると、すでに解放されたメモリ領域を再び読み込むことで（Use-After-Free）、コード実行への経路が作られます。

公式セキュリティ通知では、CVE-2026-109619で確認された経路として、セッションアップロード進行状況機能（session.upload_progress）、リクエストの初期化前に出力される設定警告、PHP 8.5の致命的なエラーのバックトレース（fatal_error_backtraces）を挙げています。ただし、これらの経路を防いでも、別の変形経路が残ると説明しています。

PHPバージョン別のパッチ状況と実行環境による影響範囲

修正版より古いPHP 8.2～8.5が影響を受けます。サポートが終了した8.1以下は、PHPプロジェクトの公式更新対象ではありません。実行方式では、PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するすべてのインストールが対象です。公式通知では、その中でもmod_phpの危険度を最も高く評価しています。Red Hatは、PHP-FPMについて、アプリケーション段階の経路を通じて条件付きで影響を受けると分類しています。

確認環境： 2026年10月22日時点で、Remiリポジトリを使用するLinuxサーバー環境において、PHP 8.4.26を8.4.27へアップグレードし、PHP-FPMワーカーの再起動とWebリクエストへの反映を検証しました。

パッケージ更新とPHP-FPM緩和設定の適用手順

PHP開発チームは、設定変更だけではすべての攻撃経路を遮断できず、パッチバージョンへ更新することだけが唯一の完全な解決策だと案内しています。更新後も攻撃対象領域を減らすため、不要な機能を無効にする緩和策を併せて適用できます。

1. PHPパッケージの更新をインストール
   オペレーティングシステムのパッケージマネージャーを使用し、利用中のPHP系列の修正版（8.4系列の場合は8.4.27）へパッケージをアップグレードします。インストール後、ターミナルでCLIバージョンを先に確認します。

   php -v

   コマンドを実行すると、画面にPHP 8.4.27 (cli)のように更新されたバージョン番号とビルド日時が表示されます。ただし、CLIバージョンと実際にWebサーバーが連携するPHPプロセスのバージョン状態は異なる場合があるため、次の手順を必ず実行してください。

2. 攻撃対象領域を減らすためのPHP-FPM設定の調整（任意および一時的な緩和策）
   更新を直ちに適用することが難しい場合や、追加の防御層を設ける場合は、php.iniまたはPHP-FPMプール設定ファイル（例：/etc/php-fpm.d/www.conf）をバックアップしたうえで、以下の項目を調整します。

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   session.upload_progress.enabledを無効にすると、確認されたセッションベースの攻撃経路を遮断できます。post_max_sizeを下げると（ファイルアップロードが不要な環境では8M、必要な環境では32Mなど）、大容量リクエストによってメモリ枯渇を誘発する試みを困難にできます。このとき、multipartの付加ヘッダーサイズを考慮し、upload_max_filesizeはpost_max_sizeより少し小さく指定します。PHP 8.5環境では、fatal_error_backtraces = 0の設定も併せて適用します。

3. PHP-FPM設定の構文チェックとプロセスの再起動
   設定を保存した後、構文エラーがないことをテストし、PHP-FPMサービスを再起動します。

   php-fpm -t
   systemctl restart php-fpm

   php-fpm -tの実行時に設定に問題がなければ、NOTICE: configuration file ... test is successfulというメッセージが画面に表示されます。ワーカープロセスを再起動すると、メモリ上に常駐していた従来の旧バージョンのワーカーが終了し、新しいパッチと設定が反映されます。

4. Webリクエストによる実際の適用バージョンの確認
   WordPressの「サイトヘルス（Site Health）」情報タブやWebサーバー連携の診断ページを呼び出し、Webリクエストを処理するPHP-FPMワーカーが8.4.27などのパッチ適用済みバージョンで応答することを確認します。確認のために一時的に作成した診断用PHPファイルがある場合は、外部にシステム情報が公開されないよう、確認直後に削除します。

更新の遅延や設定変更による副作用が発生した場合の対処法

サードパーティリポジトリ（Remiなど）のミラーへの反映が遅く、パッケージをダウンロードできない場合

緊急セキュリティパッチの直後は、トラフィック集中や同期遅延により、サードパーティリポジトリ（例：rpms.remirepo.net）で更新パッケージがすぐに検索できなかったり、ダウンロード速度が遅くなったりすることがあります。公式通知では、ボランティアが運営するこのリポジトリに発表当日の更新が掲載されないと説明し、ディストリビューションのパッケージまたはソースビルドへ切り替えるよう推奨しています。

この場合、リポジトリ設定で同期が完了した正常な速度のミラーサーバーアドレスを直接指定して、更新を進めることができます。ミラーを手動で変更しても、パッケージの改ざんを防ぐため、GPG署名チェック（gpgcheck=1）は有効な状態に保つ必要があります。ミラーを利用できない場合は、OSディストリビューションの公式バックポートパッケージを使用するか、ソースコードを直接コンパイルして適用します。

緩和設定の適用時にメモリ不足（OOM）やアップロード拒否が懸念される場合

公式通知では、直ちに更新できない場合のCVE-2026-109618に対する緩和策として、memory_limit = -1（無制限）を提示し、このときコンテナーまたはcgroupのメモリ制限も併せて設定するよう案内しています。ただし、物理メモリに余裕がないサーバーでメモリ制限を解除すると、単一のリクエストがサーバーのメモリをすべて消費し、オペレーティングシステムのOOM Killerが重要なデーモンを強制終了する障害が発生する可能性があります。この設定は更新前までの一時的な措置であり、パッチバージョンへ更新した後は、元のメモリ制限へ戻すことが安全です。

また、post_max_sizeを既存の値（例：64MB）より下げる場合は、サイトのファイル転送方式を先に確認する必要があります。管理者Webページから大容量のバックアップファイルやプラグインを直接アップロードするサイトでは、リクエストが拒否される可能性があります。一方、大容量ファイルをSFTPやrsyncで転送する環境、またはアプリケーション自体の制限がすでに30MB以下に設定されている場合は、PHPのアップロード制限を32MBに下げてもサービスに影響はありません。

一方、PHPバージョンのアップグレード後にPHP-FPMワーカーが断続的に異常終了する場合は、OPcacheのJIT（Just-In-Time）コンパイル設定を疑うことができます。JIT機能（例：opcache.jit=1255）は今回のセキュリティ脆弱性と直接関係ありませんが、バージョン変更時に安定性の問題を引き起こした実績がある場合は、設定ファイルでopcache.jit=offにして無効化し、クラッシュを防止できます。

よくある質問

WordPressやプラグインを最新バージョンに更新すれば解決しますか？

解決しません。この脆弱性は、WordPressやセキュリティプラグインが実行される前の段階であるPHPコアエンジンで発生します。Webアプリケーションファイアウォール（Cloudflare、AWS WAFなど）によって既知の攻撃パターンを一時的に遮断することはできますが、根本的な解決には、ホスティング事業者またはサーバー管理者を通じてサーバーのPHPバージョン自体を更新する必要があります。

session.upload_progress.enabledの設定を無効にすれば、更新しなくても安全ですか？

安全ではありません。公式通知では、この設定で確認されたセッション経路だけを遮断でき、他の変形経路は防げないと説明しています。また、設定はini_set()やFPMの.user.iniではなく、php.ini・FPMプール・サーバー設定など、リクエストの解析前に適用される場所に置き、すべてのワーカーを再起動する必要があります。完全な解決策はパッチのインストールだけです。

パッチの適用が完了したら、追加の確認なしですぐ運用してもよいですか？

更新は今後の攻撃を防ぐだけで、過去に侵害されていないかどうかは分かりません。更新後も、過去の侵害の有無を別途確認することを推奨します。Webディレクトリ内に最近、不自然に作成または変更されたPHPファイル（Webシェルなど）がないか確認し、WebサーバーのアクセスログとPHPのエラーログで、不審な大容量POSTリクエストやメモリエラーの繰り返し記録がないか調査するとよいでしょう。

コンテナーやクラウドイメージ環境ではどのように対応すればよいですか？

ホストサーバーのパッケージを更新しても、コンテナー内部に含まれるPHPランタイムは自動的に変更されません。そのため、修正済みバージョン（8.5.12、8.4.27、8.3.36、8.2.35）が反映されたベースイメージを使用してコンテナーイメージを再ビルドし、再デプロイする必要があります。

出典

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트 （韓国語）