結論から書くと、サポートが切れた PHP を使い続けることの本質的な問題は、脆弱性が見つかっても公式の修正版が出ないこと です。ただ、サポートが切れた瞬間に被害が出るわけではありません。すべてを同時に直そうとして止まるより、公開範囲と扱うデータで順番を決めて、危ないものから手を付けるのが現実的です。
まず公式の期限を確認する
PHP には 公式のサポート期限 があります。各バージョンは最初の2年間がアクティブサポートで、バグとセキュリティの問題が修正されます。その後の2年間は重大なセキュリティの問題だけが修正され、合計4年で終了します。2026年11月時点の状況は次のとおりです。
| バージョン | セキュリティサポートの期限 | 状態 |
|---|---|---|
| PHP 8.5 | 2029年12月31日 | アクティブサポート中 |
| PHP 8.4 | 2028年12月31日 | アクティブサポート中（2026年12月31日まで） |
| PHP 8.3 | 2027年12月31日 | セキュリティ修正のみ |
| PHP 8.2 | 2026年12月31日 | セキュリティ修正のみ（まもなく終了） |
| PHP 8.1 | 2025年12月31日 | 終了 |
| PHP 8.0 | 2023年11月26日 | 終了 |
| PHP 7.4 | 2022年11月28日 | 終了 |
| PHP 7.3 | 2021年12月6日 | 終了 |
| PHP 7.2 | 2020年11月30日 | 終了 |
| PHP 7.1 | 2019年12月1日 | 終了 |
| PHP 7.0 | 2019年1月10日 | 終了 |
| PHP 5.6 | 2018年12月31日 | 終了 |
終了したバージョンの一覧は Unsupported Branches で確認できます。PHP 公式は、終了したバージョンについて、修正されていない脆弱性にさらされる可能性があるとして、できるだけ早い更新を勧めています。
今のバージョンは、サーバーで php -v を実行するか、レンタルサーバーの管理画面で確認できます。コマンドラインと Web で別のバージョンが動いていることがあるので、Web 側の確認も必要です。
放置すると実際に何が起きるか
「古くても動いているから大丈夫」と感じるのは自然です。実際に問題になるのは、次のような形です。
脆弱性が見つかっても直せなくなる
サポートが終わると、PHP 本体の脆弱性が公表されても修正版が出ません。公開された情報は攻撃する側も読めるので、時間がたつほど条件は悪くなります。
ライブラリの更新も止まる
見落とされがちなのがこちらです。新しいバージョンのフレームワークやライブラリは、古い PHP をサポートしなくなります。PHP が古いままだと、ライブラリに脆弱性が見つかっても修正版を入れられません。PHP の問題がアプリケーション全体の問題に広がるわけです。
ある日、更新を迫られる
レンタルサーバーやクラウドでは、提供元が古いバージョンの提供を終えることがあります。OS の更新やサーバーの移転のときに、古い PHP が使えないことが判明する場合もあります。こうなると、準備のないまま短い期限で対応することになり、費用も失敗の可能性も大きくなります。
取引先や監査で問題になる
セキュリティチェックシートの提出を取引先から求められて、はじめて問題になることもあります。IPA の中小企業の情報セキュリティ対策ガイドラインでも、基本的な対策である「情報セキュリティ6か条」の最初に「OSやソフトウェアは常に最新の状態にしよう」が挙げられています。
対応の優先順位の決め方
複数のシステムがある場合や、予算が限られる場合は、次の2つの軸で順番を決めます。
軸1: インターネットから誰でもアクセスできるか。 公開サイトや顧客向けのシステムは、攻撃を受ける機会が多くなります。
軸2: 何のデータを扱っているか。 個人情報、決済、ログイン情報を扱うシステムは、被害の影響が大きくなります。
| 優先度 | 条件 | 対応の考え方 |
|---|---|---|
| 高 | 公開されていて、個人情報や決済を扱う | 最優先で計画する。すぐ直せないなら暫定対策も併用する |
| 中 | 公開されているが、機微なデータは扱わない | 改ざんや踏み台の恐れがあるため、次に対応する |
| 中 | 社内限定だが、個人情報や機密情報を扱う | アクセス経路を確認して、計画的に対応する |
| 低 | 社内限定で、機微なデータも扱わない | 他の更新と合わせて対応する。廃止の可否も検討する |
同じ優先度なら、古いバージョンのものを先にします。また、そもそも今も必要か の確認も忘れないでください。使っていない問い合わせフォームや旧サイトを止めるだけで、リスクと費用の両方が減ることがあります。
どのバージョンへ上げるか
移行先は、セキュリティサポートの期間が十分に残っているものを選びます。上の表でいえば、PHP 8.4 か 8.5 が候補です。PHP 8.2 へ上げても、2026年12月末でサポートが終わるので意味がありません。
ただし、最新版を選べばよいわけではありません。使っているフレームワークとライブラリ、サーバーで提供されているバージョンの3つが揃う範囲で決めます。Laravel なら 公式の対応表 で確認できます。
古いフレームワークのまま新しい PHP に上げられるかどうかは、コードを見ないと判断できません。PHP の移行ガイドはバージョンごとに公開されているので、非互換の項目を確認しながら影響を調べます。PHP 7.4 と 8.0 の間には特に大きな変更があります。
なお、OS のパッケージで入れた PHP は、OS の提供元が独自にセキュリティ修正を提供している場合があります。バージョン番号が古いだけで未修正とは限らないため、その OS とパッケージのサポート状況も確認してください。逆に、これに頼れるのはその OS のサポート期間だけで、古いアプリケーションやライブラリの問題が解決するわけでもありません。
すぐに上げられない場合の暫定対策
調査や予算の都合で、すぐに対応できないこともあります。その場合は、更新までの間のリスクを下げます。ただし、これらはあくまで時間を稼ぐものです。
- 公開範囲を絞る。 管理画面を IP アドレスで制限する、社内システムを VPN の内側に置くなど。
- 不要な機能を止める。 使っていないフォーム、アップロード機能、古いページを削除する。
- WAF を導入する。 よくある攻撃を入口で減らせます。ただし、脆弱性そのものが直るわけではありません。
- バックアップと復旧を確認する。 取得しているだけでなく、実際に戻せることを確認します。
- ログを残して確認する。 異常に気づけるようにし、一定期間保管します。
- アプリケーションの実装を確認する。 IPA の安全なウェブサイトの作り方は、SQL インジェクションなどの代表的な脆弱性と対策をまとめた資料で、確認の出発点になります。
大切なのは、「対応しない」と決めたのか、「いつまでに対応する」と決めたのかをはっきりさせて、記録に残すことです。担当者が替わると、古いままである理由が分からなくなり、そのまま放置されるからです。
自社の案件では、PHP 7 系から 8 系へ上げた業務システムで、期間は数週間でした。ライブラリの対応状況やテストの有無で変わるため、あくまで一例です。
h-system でできること
h-system では、サポートが切れた PHP の調査とバージョンアップを、開発者本人がお引き受けしています。使っている PHP・フレームワーク・ライブラリのバージョンと公開されている脆弱性情報を確認し、リスクと対応の優先順位を整理してお伝えします。すぐに改修しなくても、現状を確かめる調査だけのご依頼も可能です。なお、網羅的な脆弱性診断や侵入テストは行っていないため、必要な場合は専門の診断会社をおすすめしています。初回のご相談と概算のお見積りは無料です。