BLOG
2026 年 10 月 22 日
PHP に緊急度「Critical」の RCE 脆弱性。公式パッチが提供されない PHP 5 / 7 / 8.0 / 8.1 をどう守るか
2026 年 10 月 20 日（協定世界時間）、PHP 開発チームより、CVSS v4.0 スコア 9.2 と評価される深刻な脆弱性 2 件の修正版を、日本時間 10 月 21 日 23:00（14:00 UTC）に公開する旨の事前告知が行われました。複数のセキュリティ機関や研究者からの事前情報によると、これらはリモートコード実行（RCE）につながるおそれがあると報じられています。
公式の修正版が提供される見込みである一方、懸念されるのが「EOL（サポート終了）を迎えた古いバージョンの PHP を利用しており、公式修正版を直接適用できない環境」の存在です。本記事では、現時点で判明している客観的事実を整理したうえで、EOL 版 PHP を抱える環境における現実的な対応選択肢を解説します。
サイバートラストではお問い合わせから最短でライセンスを発行する 「TuxCare ELS PHP 緊急対策パック」を 2026 年 10 月 30 日（金）までの期間限定販売で提供しています。詳しくはこちら
1. 何が起きたのか
| 項目 | 内容 |
|---|---|
| CVE 番号 | CVE-2026-109618、CVE-2026-109619 |
| 深刻度 | CVSS v4.0： 9.2（Critical） |
| 想定される影響 | メモリ不足（OOM）のエラー処理に起因する脆弱性によるリモートコード実行（RCE） リクエスト処理に関する脆弱性によるリモートコード実行（RCE） |
| 原因箇所 | PHP コア（特定のアプリケーションやフレームワークではなく、PHP 処理系そのもの） |
| 影響バージョン | PHP 8.5 、8.4、8.3 、8.2 および、それ以前の PHP |
| 修正バージョン | PHP 8.5.12、8.4.27、8.3.36、8.2.35 |
| 悪用状況 | 10 月 21 日時点では、実環境での悪用は未確認です。一方、複数のセキュリティ企業が脆弱性の実在を確認・再現済みとしています。 |
PHP は Web サイトのサーバー言語として約 7 割のシェアを持ち、WordPress や Drupal、Magento など主要 CMS の基盤でもあります。CERT-EU（欧州連合コンピュータ緊急対応チーム ） や IPA（独立行政法人情報処理推進機構） は、自組織の PHP アプリケーションの棚卸しと修正版の即時適用準備、即時対応が困難な場合のインターネット公開停止やアクセス制限の検討を呼びかけています。
2. 本当の問題：パッチが提供されないバージョンが半数を超える
PHP の公式な修正版リリースが提供されるのは、サポート対象である PHP 8.2 以降です。ただし、今回の脆弱性の深刻度を鑑みた例外措置として、すでにサポートが終了している PHP 7.4、8.0、8.1 に対しても PHP セキュリティチームから最小限のソースコード用パッチ（バックポート）が提供されています。なお、PHP 5.x および PHP 7.3 以前に対しては公式パッチの提供はありません。
では、そうしたバージョンはどの程度残っているのでしょうか。セキュリティ企業 Mallory 社によると、インターネットからバージョン情報が確認できる PHP ホスト約 260 万台のうち、約 190 万台（73.5％）が修正版の提供されないブランチで稼働していると推計しています（※2026 年 10 月 22 日 14:00 時点）。
| ブランチ | ホスト数（推計） | 公式の修正版 |
|---|---|---|
| PHP 4.x～5.1 | 約 5.7 万 | なし |
| PHP 5.2～5.6 | 約 79.7 万 | なし |
| PHP 7.x | 約 85.8 万 | PHP 7.4 に対して最小限のソースコード用パッチ（バックポート）が提供される |
| PHP 8.0 / 8.1 | 約 21.3 万 | PHP 8.0 / 8.1 に対して最小限のソースコード用パッチ（バックポート）が提供される |
| PHP 8.2 〜 8.5 | 約 69.3 万 | あり |
（出典）Mallory「PHP2Shell CVE-2026-109618 CVE-2026-109619 | Am I affected?」
さらに、現在修正版が提供される PHP 8.2 についても、2026 年 12 月 31 日にセキュリティサポートが終了します。「8.2 にアップグレードしたから当面は安心」とは言えない点にも注意が必要です。
3. バージョンアップを即座に実施できない現場の事情
理想的な対策はサポート中のバージョンへのアップグレードですが、EOL 版を利用し続けざるを得ないのには、いくつかの理由が挙げられます。
- OS 標準の PHP をそのまま利用している：たとえば CentOS 7 の標準 PHP は 5.4 系、RHEL / CentOS 8 系では 7.x 系が中心です。OS 自体が EOL を迎えている場合、OS ベンダーからのバックポートも提供されません。
- アプリケーションの互換性：PHP 7 から 8 への移行では非互換の変更が多く、自社開発の業務システムや古い CMS プラグインは改修および再テストが前提となります。
- パッケージ製品・アプライアンスへの同梱：ベンダー製品の中に組み込まれた PHP は、利用者の判断だけでは更新することができません。
- 予算と体制：改修には工数と検証期間が必要で、突発的にリソースを確保することは容易ではありません。
今回のような緊急事案において、短期間で全ての環境をアップグレードすることは現実的ではないケースが多いと考えられます。
4. EOL 版 PHP を抱える環境における 3 つの選択肢
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| ① サポート中の PHP へアップグレード | 改修範囲が小さい / すでに移行計画が進んでいる | 互換性検証に時間がかかります。8.2 はあと 2 か月強でサポートが終了します。 |
| ② 隔離・緩和策（WAF、VPN 配下への移行、公開停止） | すぐに対応ができない公開系システムの当座しのぎ | 根本対策ではありません。技術詳細が不明なうちは WAF ルールの有効性も限定的です。 |
| ③ 延長サポートで EOL 版にパッチを適用する | アップグレードまで時間を確保したい / アプリを停止できない | 提供元の対応範囲や対応時期を確認する必要があります。 |
推奨されるアプローチは、選択肢 ② で直近のリスクを低減しつつ、選択肢 ③ によって「パッチが適用される状態」を確保し、最終的に選択肢 ① の移行を計画的に進めるという組み合わせです。延長サポートを活用することで、アップグレードを「緊急対応」ではなく「計画案件」として扱うことが可能になり、安全性を担保しながらスムーズな移行準備を進めることができます。
5.今すぐやるべきこと チェックリスト
- PHP の棚卸し：Web サーバーだけでなく、CMS、コントロールパネル（cPanel / Plesk）、ベンダー製品やアプライアンスに同梱された PHP も洗い出す。
- バージョンによる仕分け：8.2 以降の場合は公式修正版を即時適用する準備を進め、それ以外の場合は前述の選択肢（隔離・緩和策、延長サポートなど）を検討する。
- インターネット公開系の最優先対応：EOL 版で外部公開しているシステムについては、WAF の導入、VPN 配下への移行、一時公開停止などを最優先で検討する。
- 不審な挙動の監視：php-fpm や httpd などの PHP ワーカープロセスが、シェルやダウンロードツールを起動していないかを監視する。
- 延長サポートの検討：アップグレードまでの期間を延長サポートサービス（TuxCare ELS など）でカバーできるか検討する。
上記チェックリストについてサイバートラストがまとめてご相談を承ります。お客様の環境に最適な対策について、お気軽にお問い合わせフォームよりご相談ください。
サイバートラストではお問い合わせから最短でライセンスを発行する 「TuxCare ELS PHP 緊急対策パック」を 2026 年 10 月 30 日（金）までの期間限定販売で提供しています。詳しくはこちら
