PHP2Shellは朝のニュースから昼のワイドショーまで取り上げられ、高市総理もXで修正パッチの適用準備を呼びかけるほどの話題になりました。この週末、各レンタルサーバー事業者から、PHP2Shellへの対応が完了したという案内が続々と届いています。
参考：高市総理のX投稿
私も対応が完了したという案内にひとまず安心していました。
ところが、少し気になることがあり、ChatGPTの力も借りながらPHP公式の情報やGitHubの修正内容など、原典にあたって調べてみました。
そこで、少し考えさせられることがありました。
PHP 7.4にもパッチが提供された
PHP公式は10月21日、今回のPHP2Shellに対応するPHP 8.2、8.3、8.4、8.5の修正版を公開しました。一方、既に公式サポートが終了しているPHP 7.4向けには、GitHub上で修正コードが公開されました。
PHP公式のGitHubリポジトリでそのコミットを確認すると、次のちょっと気になる記述がありました。
Minimal mitigation for EOL version.
「サポート終了バージョン向けの最小限の緩和策」といった意味でしょうか。
コミットメッセージには、今回のPHP2Shellに関係するCVE-2026-109618とCVE-2026-109619の両方が記されています。サポート中の各系列とPHP 7.4では、修正の提供方法に違いがあります。もちろん、このコミットメッセージだけを根拠に、PHP 7.4向け修正の防御効果が低いと判断することはできません。
出典：PHP公式GitHub ― PHP 7.4向け修正コミット
今回のPHP2Shellでも、公式サポートが終了したPHP 7.4に対し、PHP開発元が公開した修正コードを利用するなどして対応したホスティング事業者が数多くあります。
こうした対応は評価されるべきだと思います。しかし、今回の脆弱性に対応できたことと、今後も継続的にセキュリティ修正が提供されることは、別の話です。
そもそも、PHP 7.4は2022年11月28日に公式サポートを終了しています。
リリースからではなく、公式サポートが終了してから、既に4年近くが経過しています。
今回の修正によってPHP 7.4の公式サポートが再開されたわけではなく、今後発見される脆弱性に対して継続的に修正が提供される保証もありません。PHP公式が現在サポート対象としている系列は、公式の一覧で確認できます。
選択できることと、安全に使えることは別
ここで気になったのが、レンタルサーバーのPHPバージョン選択機能です。
現在でも、ホスティング事業者によってはPHP 7.4などの古いバージョンを選択できます。
事業者が独自にセキュリティ修正を提供している場合もありますが、それはPHP公式によるサポートとは別のものです。
私自身、それは以前から知っていました。
既存のWebアプリケーションとの互換性を考えれば、古いバージョンを簡単に廃止できない事情も理解できます。
ただ、利用者から見ればどうでしょう。
「サービスとして提供されているのだから、使っても問題ないのだろう」
「セキュリティパッチの適用が完了したのだから、もう安心だろう」
そう受け取ってしまうこともあるのではないでしょうか。
何を隠そう、私自身も今回、各事業者の対応完了という案内を見て安心していた一人です。
「今回の脆弱性に対応できたこと」と「今後も安心して使い続けられること」は、別の話だったわけです。
その後の公式情報も確認する
記事をまとめるにあたり、10月23日にPHP公式から、PHP2Shellとは別のCVE-2026-115560について追加の注意喚起が出ていることも確認しました。特定の設定とアプリケーションコードの組み合わせでは、まれにリモートコード実行（RCE）につながる可能性があり、次の通常リリースまで session.upload_progress.enabled=0 とする緩和策が案内されています。公式案内によれば、この緩和策は10月21日のアドバイザリにも記載されていました。
ここで設定方法を詳しく解説することはしませんが、「対応完了」という案内を見たあとも、公式情報の更新を確認することが大切だと改めて感じます。具体的な影響や対処は、利用しているPHPの提供元や環境の案内もあわせて確認してください。
出典：PHP公式 ― 2026年10月23日の追加注意喚起、10月21日のセキュリティ情報
本来の対応は何なのか
PHP 7.4を利用しているのであれば、今回の修正は当面のリスクを低減するための措置と考え、本筋はPHP公式のサポート対象バージョンへの移行ではないかと思います。
もちろん、簡単な話ではありません。
PHPのバージョンを上げれば、既存のプログラムが動かなくなるかもしれません。改修や検証に相応の費用が必要になることもあります。
しかし、だからといって、サポートが終了したシステムを無期限に使い続けてよいわけでもありません。
移行が難しいのであれば、代替手段や公開範囲の見直し、場合によってはサービスの停止・終了まで含めて考える必要があると思います。
これは技術担当者だけで解決できる問題ではなく、費用とリスクを踏まえた事業上の意思決定です。
自社のシステムをどこまで把握しているか
昨今、サプライチェーン全体でのセキュリティ強化が求められ、SCS評価制度への対応なども話題になっています。
こうした取り組みも重要だと思います。
ただ、制度への対応を進める一方で、足元にある具体的なリスクの把握や対処が後回しになっていないかも、確認する必要があると思います。
例えば、自社で稼働しているシステムについて「PHPを使っている」ということは知っていても、それがPHPのどのバージョンなのか、現在もサポートされているのかまで把握しているでしょうか。
これはPHPに限った話ではありません。
OS、データベース、フレームワーク、ミドルウェアなどについても同様です。
システムが正常に動作していることと、安全に運用できる状態にあることは別問題です。
脆弱性が公表されてから慌てて調査するのではなく、普段から自社システムの構成やサポート状況を把握しておくことが、実効性のあるセキュリティ対策につながるのだと思います。
最後に
今回の件で改めて感じたのは、「対応完了」という言葉の受け取り方の難しさです。
ホスティング事業者が迅速に対策を実施し、既存のサービスを止めずに利用者を守ろうとすることは、評価すべき取り組みだと思います。
一方で、それを受け取る私たち利用者も、何についての対応が完了したのか、その対応によって何が解決し、何が解決していないのかを考える必要があります。
私自身、今回、少し原典を調べてみるまで、そこを十分に意識できていませんでした。
「パッチが当たったから安心」ではなく、「そのシステムをこれからも使い続けてよいのか」。
今回のPHP2Shellは、そんなことを改めて考える良いきっかけになりました。