2026年10月21日（日本時間23時）、PHP開発チームは認証なしでリモートコード実行（RCE）を可能にする2件の重大な脆弱性を修正した緊急セキュリティリリースを公開しました。
深刻度を示すCVSS v4.0スコアはいずれも「9.2（Critical：緊急）」と極めて高く、パッチ公開前から内閣官房 国家サイバー統括室やIPA（情報処理推進機構）、JPCERT/CCなどの政府・関係機関が異例の事前注意喚起を行う事態となっています。
本記事では、PHP公式サイトのセキュリティ勧告をもとに、脆弱性の仕組みや影響を受けるサーバー構成、優先して実施すべきアップデート手順、そして直ちに更新できない場合の一時的な緩和策を分かりやすく整理して解説します。
なぜ政府機関や関係組織が異例の注意喚起を行っているのか
今回の脆弱性（海外のセキュリティ研究者からは通称「php2shell」とも呼ばれています）は、外部の攻撃者がログイン認証などを一切経ることなく、インターネット越しにサーバー上で任意のプログラムやコマンドを実行できてしまうという深刻なものです。
さらに今回は、PHPセキュリティチームが10月20日の段階で「翌21日14:00（UTC）に重大なセキュリティ修正を公開する」と事前予告を出しました。
修正プログラムが公開されると同時に、攻撃者が修正前後のコード差分を解析して悪用手法を特定し、まだアップデートしていない世界中のサーバーへ一斉に攻撃を仕掛ける恐れがありました。
日本国内の政府機関・関係組織による主な動き
- 内閣官房 国家サイバー統括室：サイト運営者やシステム管理者に対し、自組織でのPHPの利用確認と、パッチ公開後の速やかな適用準備を強く呼びかけ
- IPA（情報処理推進機構）：「PHPのセキュリティリリース公開予定について」を発出し、Webサイトだけでなくネットワーク機器やパッケージ製品の内部で使われているPHPも含めた資産の棚卸しと更新準備を要請
- JPCERT/CC・各国CERT：早期のアップデート適用や、直ちに修正を適用できない環境におけるネットワーク隔離・設定見直しなどの警戒を要請
WordPressをはじめ、国内外のWebサイトやECサイト、業務システムの多くがPHPを基盤として稼働しています。
そのため、国内のレンタルサーバー事業者やクラウドサービス、ECプラットフォーム、大学・自治体などでも、パッチ公開前後に緊急メンテナンスや予防的なサービス一時停止を実施する動きが相次ぎました。
修正された2つの重大な脆弱性の仕組み
今回のアップデートで修正されたのは、PHPのコア部分（PHP 5.4以降の幅広いバージョン）に存在していた以下の2件の脆弱性です。
メモリ不足（OOM）破損によるリモートコード実行（CVE-2026-109618）
GitHubアドバイザリ番号は「GHSA-w8hw-w9fx-j79w」です。
PHPがWebリクエストを処理している途中で「メモリ不足（Out-Of-Memory）」が発生すると、内部のリクエストデータが途中までしか初期化されていない中途半端な状態で処理が中断されることがあります。
その結果、リクエスト終了時の後始末（クリーンアップ）処理において、本来は無効であるはずの未初期化データが「有効なデータ」として誤って扱われ、攻撃者が細工したデータを介してリモートコード実行につながる恐れがあります。
古いグローバル状態の残存によるリモートコード実行（CVE-2026-109619）
GitHubアドバイザリ番号は「GHSA-6wmf-4rv5-p3rp」です。
致命的なエラー（Fatal Error）などが発生した際、リクエストが保持していた内部状態のメモリ領域が解放された後も、その古い参照状態が残存してしまう問題（Use-After-Free）です。
同じワーカープロセスが後続の別リクエストを処理する際、通常の初期化処理によってリセットが行われるよりも前のタイミングでその「古い状態」を使用してしまい、結果として外部からのコード実行を許してしまいます。
影響を受ける環境と特にリスクが高い構成
公式勧告では、Webリクエストを処理するすべてのPHPインストール環境がリスクにさらされると明記されています。
- 対象となる主な実行環境：PHP-FPM、Apacheの「mod_php」、php-cgi、FrankenPHP、LiteSpeed など
- 特に危険度が高い構成：Apacheで「mod_php」を使用している環境
特に注意が必要なのが、Apacheのモジュール版である「mod_php」です。
公式勧告によると、mod_php環境ではWebアプリケーション側のPHPコード（WordPressやLaravelなどのログイン認証やセキュリティプラグインの処理）が実行されるよりも前の「リクエストを受け取る段階」で攻撃が成立することが確認されており、最もリスクが高いと評価されています。
恒久対策：修正済みバージョンへの速やかなアップデート
この脆弱性に対する確実な解決策は、修正パッチが適用された最新バージョンへPHPをアップデートすることです。
サポート対象となっている各ブランチ向けに、以下の修正版がリリースされています。
| 利用中のPHP系列 | 修正済みバージョン | サポート状況・備考 |
|---|---|---|
| PHP 8.5 系列 | PHP 8.5.12 | 最新の安定版系列。直ちにアップデートを推奨 |
| PHP 8.4 系列 | PHP 8.4.27 | アクティブサポート中。直ちにアップデートを推奨 |
| PHP 8.3 系列 | PHP 8.3.36 | セキュリティサポート中。直ちにアップデートを推奨 |
| PHP 8.2 系列 | PHP 8.2.35 | 2026年12月31日でサポート終了（EOL）予定。更新とあわせて上位版への移行計画を推奨 |
| PHP 8.1 以前 | 公式の通常更新は終了 （特例パッチ・OS別修正あり） |
PHP 7.4 / 8.0 / 8.1向けに最小限のソースバックポートが特例提供。Linuxディストリビューションの更新パッケージも確認 |
レンタルサーバー（WordPress等）を利用している場合
エックスサーバー、さくらインターネット、ConoHa WING、ロリポップなどの共用レンタルサーバーを利用している場合、サーバー事業者側で順次セキュリティパッチの適用が進められています。
各社のメンテナンス・お知らせ情報を確認するとともに、もしサーバー管理画面で「PHP 7.4」や「PHP 8.0 / 8.1」などの古いバージョンを選択したままになっている場合は、サポート対象の「PHP 8.3」「PHP 8.4」「PHP 8.5」などへ切り替えることを強くおすすめします。
VPS・クラウド・自社サーバーを管理している場合
UbuntuやRed Hat Enterprise Linux（RHEL）、AlmaLinuxなどのLinuxディストリビューションおよびLTSベンダーには事前にパッチが提供されています。
パッケージマネージャーで最新のパッケージへ更新した後、必ずWebサーバーやPHP-FPMのプロセスを再起動してください（プロセスを再起動しないと、メモリ上に古いPHPワーカーが残ったままになります）。
# Ubuntu / Debian系での更新と再起動の例
sudo apt update && sudo apt upgrade -y
sudo systemctl restart php8.4-fpm apache2 nginx
# RHEL / AlmaLinux / Rocky Linux系での更新と再起動の例
sudo dnf update -y
sudo systemctl restart php-fpm httpd nginxすぐにアップデートできない場合の一時的な緩和策
業務システムの互換性検証などの事情により、どうしても今すぐPHP本体のアップデートを実施できないケースもあるかと思います。
公式勧告では、特定の攻撃経路を遮断してリスクを軽減するための緩和策（ワークアラウンド）が提示されています。ただし、これらはすべての攻撃パターンを防ぐものではなく、サーバーを十分に安全にするものではないため、あくまでアップデートまでのつなぎとして活用してください。
CVE-2026-109618（メモリ不足による脆弱性）に対する緩和策
- memory_limit を「-1（無制限）」に強制設定する：PHP側でメモリ上限エラーが発生する経路自体を取り除きます。アプリケーション側のコード（ini_setなど）やディレクトリ設定で有限の値に戻されないよう、PHP-FPMのプール設定やApacheの設定で「php_admin_value」を使って強制指定します。
- post_max_size を小さく制限する：大量のデータを送りつけられないよう、ファイルアップロードが不要な環境では「post_max_size = 8M」、アップロードが必要な環境でも「post_max_size = 32M」程度に設定し、「upload_max_filesize」はそれ未満に抑えます。あわせてWebサーバーやプロキシ・WAF側でも、リクエストサイズや入力フィールド数、マルチパート数、ヘッダー数の上限を設けます。
- コンテナやcgroupでメモリ上限を管理する：PHPのメモリ上限を無制限にした上で、OSのコンテナやcgroup機能を使って可用性の境界を設け、メモリを過剰消費したワーカープロセスのみを強制終了（Kill）させます。なお、RLIMIT_AS や RLIMIT_DATA は脆弱なメモリ割り当て失敗を引き起こす原因になるため、代用しないでください。
PHP-FPMのプール設定ファイル（www.confなど）で設定する記述例は以下の通りです。
; PHP-FPM プール設定（www.conf 等）での緩和設定例
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4MCVE-2026-109619（古い状態の残存による脆弱性）に対する緩和策
- session.upload_progress.enabled = 0 を設定して全ワーカーを再起動する：確認されているセッション経由の攻撃パスを遮断します。リクエスト解析前に適用されるよう、必ず php.ini やFPMプール設定、サーバー設定で指定してください（ini_set() や .user.ini では防げません）。
- PHP 8.5環境では fatal_error_backtraces = 0 を設定する：PHP 8.5を利用している場合は、致命的エラー時のバックトレース機能を無効化し、すべてのワーカーを再起動します。
- 初期化前に診断メッセージを出す無効・非推奨な設定を削除する：リクエストごとに適用される設定の中に、初期化前に警告を出す古い設定や無効な記述があれば取り除きます（error_reporting や display_errors、@演算子で表示だけ隠しても効果はありません）。
- 外部から引き起こせるFatal Errorやタイムアウトを修正する：アップロード処理やインポート処理、コールバック処理などで、外部からの入力によって致命的エラーや実行タイムアウトが発生する箇所があれば修正します。
; php.ini または PHP-FPM プール設定での緩和設定例
session.upload_progress.enabled = 0
; PHP 8.5 を使用している場合は以下も追加
fatal_error_backtraces = 0まとめ：早急なバージョン確認とアップデートの実施を
今回のPHPセキュリティ勧告（CVE-2026-109618 / CVE-2026-109619）は、認証を必要とせず外部からコード実行が可能になる非常に重大な脆弱性であり、政府機関が事前から警戒を呼びかけるほどの緊急性を持っています。
今すぐ確認・実施したいチェックリスト
- 自組織のWebサイト、検証環境、コンテナ、社内ツール等で稼働しているPHPのバージョンを洗い出す
- PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35（またはOSベンダー提供の修正パッケージ）へ速やかにアップデートする
- アップデート作業後は、必ずWebサーバーおよびPHP-FPMのワーカープロセスを再起動する
- どうしても即時更新できない環境では、memory_limit や session.upload_progress の設定変更による緩和策を適用し、最短スケジュールでの更新計画を立てる
すでに修正版が公開されているため、未更新のサーバーを狙ったスキャンや攻撃が活発化するリスクが高まっています。
ご自身が管理・運営しているサイトやサーバーのPHP環境を今すぐ点検し、安全なバージョンへのアップデートを済ませておきましょう。
