PHP プロジェクトは 10 月 21 日、「Critical remote code execution vulnerabilities, update now」と題したセキュリティアドバイザリを公開しました。PHP 8.5.12、8.4.27、8.3.36、8.2.35 で、2 件の深刻な脆弱性 CVE-2026-109618（GHSA-w8hw-w9fx-j79w）と CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）が修正されています。GitHub のアドバイザリではどちらも Critical、CVSS v4 スコアは 9.2 で、いずれも認証なしでのリモートコード実行につながるおそれがあります。PHP プロジェクトは、すべての PHP ユーザーに直ちに更新するよう強く呼びかけています。この 2 件は php2shell とも呼ばれています。

影響を受けるのは誰か

  • アドバイザリの対象はWeb リクエストを処理するすべての PHP 環境で、PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed が含まれます。PHP チームは mod_php のリスクが最も高いとしており、アプリケーションのコードが動く前に、認証のない 1 回のリクエストで攻撃が成立する実証済みのエクスプロイトがあります。
  • CVE-2026-109618：メモリ不足（OOM）の処理によって、内部のリクエストデータが一部しか初期化されていない状態で PHP の処理が中断されることがあり、その後のリクエストのクリーンアップがこの無効なデータを有効なものとして扱うおそれがあります。
  • CVE-2026-109619：あるリクエストに属する内部状態が、その裏付けとなるメモリが解放された後も残ることがあり、同じワーカーが処理する後続のリクエストが、通常の初期化でリセットされる前にその古い状態を使ってしまうおそれがあります。
  • 問題は PHP ランタイムそのものにあり、WordPress やプラグインのものではありません。WordPress は同日、この問題について WordPress の更新は不要で、予定もないと説明しています。更新が必要なのは PHP です。WordPress では「ツール → サイトヘルス → 情報 → サーバー」で PHP のバージョンを確認できます。

更新の方法

  • まず php -v でバージョンを確認します。公式ソースからビルドしている場合は、8.5.12、8.4.27、8.3.36、8.2.35 のいずれかに更新してください。
  • ディストリビューションのパッケージを使っている場合：Ubuntu は 10 月 21 日に USN-8948-1 を公開し、22.04 の修正版は php8.1 8.1.2-1ubuntu2.28、24.04 は php8.3 8.3.6-0ubuntu0.24.04.13 です。Debian 13 は php8.4 8.4.27-1~deb13u1（DSA-6574-1）、Debian 12 は php8.2 8.2.35-1~deb12u1（DLA-4848-1）です。sudo apt update && sudo apt upgrade の後は、PHP-FPM か Apache を再起動してください（例：sudo systemctl restart php8.3-fpm）。すでに動いているワーカーは、自動では新しいコードに切り替わりません。
  • PHP 8.1 以前は、PHP プロジェクトによる更新がすでに終了しています。ディストリビューションが修正をバックポートしている場合（上記の Ubuntu 22.04 の 8.1 など）は、システムのパッケージを通常どおり更新すれば十分です。深刻度を考慮し、PHP セキュリティチームはソースからビルドする人向けに、7.4、8.0、8.1 用の最小限のソースパッチも用意しました。
  • aaPanel のようなパネルでインストールした PHP や、Docker イメージ内の PHP は、システムの apt から入ったものではありません。前者はパネルで新しいバージョンがあるか確認し、後者は更新されたイメージを取得してコンテナを作り直してください。aaPanel で VPS を管理する方法とVPS での Docker 入門を参照してください。

すぐに更新できない場合：公式の暫定策

PHP チームは完全な解決策は更新だけだと強調しています。以下の対策は特定の攻撃経路を減らすものにすぎず、環境を安全にするものではありません。

  • CVE-2026-109618 向け：memory_limit=-1 を、できればアプリケーションが上書きできない方法（FPM プールや Apache の設定での php_admin_value など）で設定します。あわせて post_max_size を低めにし、ファイルのアップロードが不要なアプリケーションは 8M、必要なものは 32M とし、upload_max_filesize はそれより小さくします。
  • CVE-2026-109619 向け：session.upload_progress.enabled=0 を設定してすべてのワーカーを再起動します。設定は php.ini、FPM プール、またはサーバーの設定に書き、ini_set() や FPM の .user.ini ファイルには頼らないでください。PHP 8.5 では fatal_error_backtraces=0 も設定します。
  • 10 月 23 日には補足のアドバイザリが出ました。8.5.12 に更新済みでも、次の定期リリースまでは session.upload_progress.enabled=0 を維持するよう勧めています。発生条件がまれな関連問題 CVE-2026-115560 が、次のリリースでようやく修正されるためです。

前段に CDN があってもパッチは必要

Cloudflare は 10 月 21 日、この脆弱性が正式公開の前に漏れており、顧客を狙った攻撃トラフィックを観測したと明らかにしました。10 月 21 日 03:02（UTC）からは、同社の無料版または有料版の WAF を使うサイトが既定で保護されています。ただし Cloudflare 自身も、WAF があっても PHP にパッチを当てるべきだとしています。また WAF が防げるのは自分を経由するトラフィックだけで、オリジンサーバーの IP アドレスに直接アクセスできるなら、攻撃者は CDN を迂回できます。更新を終えたら、それまでサイトがインターネットに公開されていた場合は、VPS が侵害されたときの調査方法に沿って、不審なプロセスや見覚えのないファイルがないか確認してください。WordPress の運営者は9 月の WordPress コアの脆弱性も修正済みか確かめ、nginx を使っている場合は nginx が 10 月 14 日に修正した 5 件の脆弱性も確認してください。