PHP重大脆弱性の影響と対応手順

2026年10月21日、PHPの開発チームが認証なしのリモートコード実行につながるおそれのある脆弱性2件の修正版を公開しました。自社のサイトやシステムでPHPのどのバージョンが動いているのか、すぐに答えられない企業も少なくありません。何が起きたのか、まず何を確認し、どう対処するのかを順に整理します。

何が起きたのか

2026年10月21日(日本時間23時)、PHPの開発チームは、深刻度が「Critical(緊急)」に分類される脆弱性2件の修正版を公開しました。

CVE-2026-109618
CVE-2026-109619

どちらも、国際的な評価指標であるCVSS v4.0で9.2と評価されています。認証を必要とせず、外部から不正なプログラムを実行される(リモートコード実行)おそれがあるものです。

10月23日には、別の脆弱性(CVE-2026-115560)も告知されました。こちらは、特定のセッション設定とアプリケーションの処理が重なった場合に限られ、実際には起こりにくい構成とされています。修正は次回のリリースに合わせて行われる予定で、それまでの対処としてsession.upload_progress.enabled=0の設定が案内されています。

影響を受けるバージョンと修正版

今回の修正版は次のとおりです。これより前のバージョンが影響を受けます。

系統	修正版
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

PHP 8.1以前は、公式のサポートがすでに終了しているため、通常の修正版は公開されていません。ただし開発元は、深刻度を考慮して、PHP 7.4・8.0・8.1向けに最小限の修正をソースコードの形で提供しました。主な対象は、ソースからビルドして使っている場合や、ベンダーの長期サポートを受けられない場合です。

ディストリビューションやレンタルサーバーで使っている場合は、事業者側で修正版が提供されているかどうかを確認する必要があります。

まず確認すること

最初にやることは、使っているPHPのバージョンの確認です。

サーバーを直接管理している場合: コマンドでphp -vを実行して確認します。PHP-FPMやApacheのモジュールなど、Webを実際に動かしているPHPが、コマンドラインのPHPと別のバージョンになっている場合もあるため、Webサーバー側の設定も確認してください。
WordPressの場合: 管理画面の「ツール」→「サイトヘルス」→「情報」で、PHPのバージョンを確認できます。
レンタルサーバーの場合: 管理画面のPHP設定で確認します。事業者が緊急のメンテナンスを行っている場合もあるため、お知らせも見てください。
開発会社や運用会社に任せている場合: どのバージョンで動いているか、更新の予定があるかを問い合わせます。

「どこで、どのバージョンのPHPが動いているのか」を一覧にしておくと、以降の判断が早くなります。コーポレートサイトだけでなく、キャンペーン用のサイトや、過去に作って放置されているサイトも対象です。

対処は、修正版への更新が最優先

完全な対処には、修正版への更新が必要です。確認の結果、修正版より前のバージョンが動いていた場合は、次の順で進めます。

更新の前に、ファイルとデータベースのバックアップを取ります。
修正版(上の表)に更新します。同じ系統の中の更新は、機能の追加を含まないため、影響は比較的小さい傾向にあります。
更新後に、主要な画面や機能が動くかを確認します。WordPressであれば、テーマ・プラグインの互換性も確認します。

すぐに更新できない場合の暫定対策

既存のシステムとの互換性などで、すぐには更新できない場合があります。開発元が案内している緩和策は、特定の攻撃経路にだけ有効なものです。開発元自身も、攻撃の経路を減らすが安全にはしない、と位置づけています。あくまで更新までの時間を稼ぐ手段として使います。

memory_limit=-1を設定し、アプリケーションから上書きできないようにする
Webサーバーやプロキシで、リクエストの大きさを制限する
session.upload_progress.enabled=0を、php.iniなど、リクエストの解析前に適用される場所で設定する(ini_set()や.user.iniには頼らない)
PHP 8.5ではfatal_error_backtraces=0も設定できる

これらの設定は、すべてワーカーの再起動が必要です。また、コンテナーのメモリ制限は、メモリ確保の失敗を確実に防ぐものではありません。エラーの表示を抑えるだけでは対策にならず、ログにエラーが出ていないことも、安全の証明にはなりません。

あわせて、公開範囲の限定(VPNの内側に置く、接続元のIPを制限する)、WAFの導入、脆弱性診断の実施も、更新までの守りとして有効です。

8.2のサポート終了と、その先の選択肢

今回の修正を受けて、あらためて意識したいのがサポートの期限です。PHP公式の情報では、各バージョンのセキュリティサポートは次の日付までとされています。

バージョン	セキュリティサポートの終了
8.1	2025年12月31日(終了済み)
8.2	2026年12月31日
8.3	2027年12月31日
8.4	2028年12月31日
8.5	2029年12月31日

8.2は、あと2か月ほどでサポートが終了します。8.1以前を使っているシステムは、すでにサポートの外です。

古いバージョンのまま使い続ける場合の選択肢は、大きく3つです。

バージョンアップ: PHPとフレームワークを、サポート中のバージョンに上げます。コードが比較的新しく、仕様がわかる人がいる場合に向いています。ただし、上げた後にも次の期限が来るため、改修の規模を先に調べておく必要があります。
作り直し: 業務を整理し直して、新しい基盤で作り直します。フレームワークが古すぎる場合や、仕様が分からない場合に向いています。公開リスクの大きい部分から、段階的に移す方法もあります。
延長サポートの利用: サポートが終了したバージョンに対し、有償でセキュリティ修正を提供するサービスがあります。改修までの時間を稼ぐ手段として使われますが、一時的な措置として、移行の計画と併せて考えるのが現実的です。

どれを選ぶにしても、更新を判断し作業する担当を決めておく、つまり運用保守の体制を明確にしておくことが、次の脆弱性が出たときの初動の速さにつながります。