PHPのサポート終了への対策｜バージョン確認・暫定対応・移行の判断

PHPのサポート終了への対策は、修正がどこから届くかを確かめ、届かない間は外部から届く範囲を絞り、移行・改修・停止を期限付きで決めることだ。

2026年10月21日には、PHPの重大な脆弱性2件も公表された。

PHPのサポート終了への対策と修正の提供範囲

PHP公式の修正が届くのは8.2〜8.5で、8.1以前に届くのは主に、OSの提供元やLTSの提供事業者が古いバージョンへ移した修正だ。どこから届くかで、同じ「8.1」でも危険の度合いが変わる。

PHPのサポート期間とEOL

PHP公式は、各系列を「アクティブサポート」「セキュリティ修正のみ」「サポート終了（EOL）」に分けて公開している。セキュリティ修正のみの期間に直るのは重大な脆弱性だけだ。EOLになってもPHPは動き続けるが、PHP公式はその系列に、修正されない脆弱性にさらされるおそれがあるとして、早い更新を求めている。

8.1以前は開発元の修正が止まり、8.2も残り2か月だ。

サポート終了後の脆弱性対応

PHP公式は2026年10月21日のセキュリティ勧告で、認証なしでのリモートコード実行につながりうる脆弱性2件（CVE-2026-109618、CVE-2026-109619）を修正した8.5.12・8.4.27・8.3.36・8.2.35を公開した。同じ勧告で、8.1以前はPHPプロジェクトから更新を受けられないとし、一部のディストリビューションやLTSの提供事業者が移植した修正を確かめるか、サポート中のバージョンへ上げるよう求めている。

今回は脆弱性の深刻さを理由に、7.4・8.0・8.1向けの最小限のソースの修正も公開された。ただし勧告は、次の脆弱性でも同じ対応をするとは書いていない。

OSのパッケージで入れたPHPなら、提供元の修正状況を見る。Debianは「セキュリティに関するFAQ」で、安定リリースには新しいバージョンを入れずに修正だけを移すため、バージョン番号が古いまま修正済みになると説明している。修正済みかは、パッケージの変更履歴か、セキュリティ勧告に書かれたパッケージのバージョンと照らして確かめる。

たとえばDebian 12はPHP 8.2を収録し、LTSの期間は2028年6月30日までだ。ただし、LTSで十分に保守できるパッケージの数は支援の規模で決まるとDebianは書いている。

PHPの修正が続いても、フレームワークは古いPHPへの対応を先に打ち切る。Laravelの公式のサポート方針では、PHP 8.2で動く最新の系列の12でも、セキュリティ修正は2027年2月24日までだ。期限の延長を当てにするなら、使っているパッケージが対象に入っているかと、フレームワークの期限まで確かめる。

PHPのサポート終了対策で調べるバージョンと依存機能

調べるのは、Web・CLI・コンテナごとに動くPHPのバージョンと入手元、拡張モジュールとライブラリの依存条件だ。

稼働PHPバージョンの確認

Webの要求を処理するPHP、cronのバッチが呼ぶPHP、コンテナの中のPHPは、別々のものでありうる。PHP公式マニュアルによれば、設定ファイルは動かし方ごとに分けられ、CLIではphp-cli.iniがあれば使われる。Webサーバーのモジュールとして動くPHPは、Webサーバーの起動時に一度だけ設定を読む。

場所ごとにバージョン・パッケージ名・入手元を書き出す。Webで確かめる表示は管理者だけに見せ、確かめたら消す。

入手元がOS標準のパッケージでなければ、OSのセキュリティ更新は届かない。パッケージを更新したら、PHP-FPMやWebサーバーを再起動し、Web側から見えるバージョンが変わったかを確かめる。

PHP拡張・アプリの依存条件

移行先で動くかは、PHP本体のほかに拡張モジュールとライブラリでも決まる。Composerのコマンドcheck-platform-reqsは、インストール済みのパッケージが求めるPHPと拡張のバージョンを、実際の環境と照らす。移行先の環境でこれを実行し、足りない拡張とバージョンの合わないライブラリを洗い出す。

削除された機能に当たることもある。PHP公式マニュアルの移行ガイドによれば、PHP 7.0では古いMySQL接続用の拡張（mysql）が削除された。使っていれば、データベースへの接続部分の書き直しが要る。

更新できない理由は、項目ごとに分けて書き出す。

• 削除された拡張や関数を使っている
• フレームワーク・CMS・プラグインが、移行先のPHPに対応していない
• OSが古く、新しいPHPのパッケージがない
• 改修できる開発者や委託先がいない、テスト環境がない

委託先が作ったシステムなら、保守契約にPHPの更新が含まれるかを確かめる。

PHPのサポート終了から移行までの暫定対策：公開範囲・WAF・監視

移行までの暫定対策は、接続元を絞って外部から届く範囲を減らす、WAFや勧告にある設定で攻撃を減らす、勧告を追い続けるの3つで、どれも脆弱性そのものは消さない。NISTも「企業のパッチ管理計画ガイド」で、脆弱性を機能を損なわずに消せるのは修正の適用か、修正済みのバージョンへの更新だけだとし、EOLのソフトウェアには修正が出ないことを、すぐに適用できない理由の一つに挙げている。暫定対策は、移行の期限とセットで決める。

社内向けのシステムや管理画面は、接続元を絞りやすい。誰でも開けるWebサイトは絞れないので、移行を先にする。

IPAは「Web Application Firewall 読本」で、WAFは脆弱性を直すといった根本的な対策ではなく、攻撃による影響を低減する対策だとしている。OWASPも「仮想パッチ チートシート」で、仮想パッチは検査した通信とルールが認識する攻撃にしか効かず、脆弱性そのものは残るとし、迂回の試験とコードや提供元の修正を続けるよう求めている。WAFを入れたら、対象の脆弱性に合うルールがあるかを確かめる。

設定による軽減も同じだ。10月21日の勧告は、すぐ更新できない場合の設定を挙げたうえで、それらは特定の攻撃経路を減らすが、導入環境を安全にはしないと明記している。

PHP公式とOS提供元の勧告は追い続け、新しい脆弱性が出たら、修正が届くか、暫定対策で足りるかを判断し直す。

公開したままの修正前のPHPにどんな攻撃が届き、乗っ取られたサーバーが何に使われるかは、おとりサーバーで観測したPHP2Shellの攻撃の解析で確かめられる。

PHPのサポート終了対策としての移行・改修・停止の判断

移行・改修・停止は、互換性、修正の範囲、止められる時間を並べて選ぶ。

PHP更新の影響と移行・改修の判断

PHPの更新で怖いのは、エラーにならずに結果だけが変わる変更だ。PHP公式マニュアルの移行ガイドによれば、PHP 8.0では数値と数値でない文字列の比較の仕方が変わった。

入力チェックや権限の判定がこの比較に頼っていれば、更新後は画面が動いても判定の結果が変わる。

移行先の期限も見る。8.2へ上げても、修正が届くのは2026年12月31日までだ。

判断には次の材料をそろえる。

• 依存条件の確認で見つかった、直す必要のある拡張・ライブラリ・コード
• 業務の流れを確かめる試験を、移行先の環境で回せるか
• 本番を止められる時間帯と、切り戻しの方法
• 作り直しに近い規模なら、作り直す費用と期間

LTSの提供事業者から修正を受けるなら、対象のバージョン・拡張・OSと契約期間、費用を確かめ、契約が切れるまでの移行計画と一緒に決める。

更新困難なPHP環境の停止判断

NISTは同じガイドで、脆弱性への対応を受容・軽減・移転・回避の4つに分けている。回避には、脆弱なソフトウェアを外すことや、資産を廃止することが含まれる。修正の届け手がおらず、直せる人もいない公開システムでは、停止や機能の縮小も選択肢に入る。

止めるかは、止まったときの業務への影響と、公開している範囲、乗っ取られたときに届くデータや鍵の重さを並べて決める。残す場合も、暫定対策の内容、期限、責任者、見直す日を記録する。NISTも、保守計画の例外は追跡して定期的に見直すよう求めている。