PHP のサポート期限一覧。8.2 は 2026 年 12 月 31 日で終了、期限が切れた PHP に起きること
想定読者は、自社のサイトや業務システムの PHP を誰が更新するかを決める方と、その相談を受ける技術者です。
10 月 21 日、PHP に深刻な脆弱性が見つかったというニュースを見て、「うちのサイトは関係あるのか」と調べた方も多いと思います。調べてみると、修正版の番号や CVE といった言葉が並び、結局どうすればいいのかが分かりにくかったはずです。
関係があるかどうかは、2 つのことで決まります。サイトが動いている PHP のバージョンと、その PHP を誰が管理しているかです。そしてバージョンについては、それがサポート期限の内側にあるかが分かれ目になります。期限の内側なら、緊急のときも修正版を入れるだけで済みます。期限が切れていると、公式の修正版そのものが出ません。
この記事では、PHP のサポート期限の一覧と、期限が切れた PHP に実際に何が起きたか (当社が保守する API で 10 月に起きたこと) を書きます。最後に、御社のサイトのバージョンを確かめる方法と、PHP 8.2 を使っている場合に年内にすべきことをまとめます。
PHP のサポート期限は「修正版が届く期限」
サポート期限を過ぎた PHP には、深刻な脆弱性が見つかっても公式の修正版が出ません。サポート期限とは「いつまで安全に使えるか」の目安ではなく、「問題が起きたときに、公式の直し方が届くか」の期限です。
PHP の各バージョンには、2 種類の期限があります。
- 機能の改善 (アクティブサポート): 不具合の修正が入る期間。リリースから 2 年
- 安全のための修正 (セキュリティサポート): 脆弱性の修正だけが入る期間。リリースから 4 年。これを過ぎると、公式の修正は一切出ない
2026 年 10 月時点の期限は次のとおりです (出典: php.net の Supported Versions)。
| バージョン | リリース | 機能の改善 | 安全のための修正 |
|---|---|---|---|
| 8.1 以前 | 〜2021 年 | 終了 | 終了 (8.1 は 2025 年 12 月 31 日) |
| 8.2 | 2022 年 12 月 | 終了 | 2026 年 12 月 31 日まで |
| 8.3 | 2023 年 11 月 | 終了 | 2027 年 12 月 31 日まで |
| 8.4 | 2024 年 11 月 | 2026 年 12 月 31 日まで | 2028 年 12 月 31 日まで |
| 8.5 | 2025 年 11 月 | 2027 年 12 月 31 日まで | 2029 年 12 月 31 日まで |
新しいバージョンは毎年 11 月ごろに出て、4 年後の 12 月 31 日に期限を迎えます。いま期限の内側にあるのは 8.2 から 8.5 までで、8.2 はあと 2 か月ほどで期限が切れます。
期限が切れた PHP には、緊急の脆弱性でも公式の修正が出なかった
10 月の緊急脆弱性で、公式の修正版が出たのは 8.2 以降だけでした。2026 年 10 月 21 日の夜に公開された修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 の 4 つで、すでに期限が切れていた 8.1 以前には何も出ていません。
当社が保守するシステムでも、この差がそのまま出ました。
| サーバー | PHP のバージョン | 期限 | 対応 |
|---|---|---|---|
| レンタルサーバーのサイト | 8.3 | 内側 | 提供元が修正版を当てた。当社は待つだけ |
| 3 つの事業の API (VPS 3 台) | 8.1 | 切れていた | 公式の修正なし。配布元が独自に用意した修正版へ入れ替え |
期限の内側にあった 8.3 は、提供元が修正版を当てるのを待つだけで終わりました。一方、期限の切れていた 8.1 の 3 台は、公式の修正版がないため、PHP の配布元 (remi) が独自に用意した修正版を探し、古いプログラムがそのバージョンで動くことを確かめてから入れ替える必要がありました。公開翌日の 10 月 22 日に 3 台とも更新を終え、止まったのは再起動の数秒だけでしたが、これは 3 台の構成を普段から把握していたからできたことです。作業の詳細は 対応報告の記事 に書いています。
期限が切れた PHP を使っていると、緊急のときに取れる手は 3 つしかありません。
- 配布元の修正版を探して入れ替える。 出ているかどうか、いつまで出るかは配布元次第
- 期限の内側のバージョン (8.2 以降) へ急いで上げる。 古いプログラムが動かなくなる危険を抱えたまま、急ぎの作業になる
- 何もしない。 攻撃を受けるかもしれない状態のまま動かし続ける
どれも、期限の内側にいれば選ばずに済んだ手です。
期限が切れても、サイトは普通に動き続ける
PHP は期限が切れても止まりません。サイトは昨日と同じように表示され、お問い合わせも届きます。だから、誰も気づかないまま何年も動き続けます。
期限が切れたときに何が起きるかは、PHP を誰が管理しているかで変わります。
| サイトが動いている場所 | PHP を上げるのは | 期限が切れたときに起きること |
|---|---|---|
| レンタルサーバー | 提供元 | 提供元が古いバージョンの提供をやめ、新しいバージョンへ切り替えたときに、古いプログラムが動かなくなることがある |
| VPS・クラウド | 自社か委託先 | 誰かが上げない限り、期限切れのまま動き続ける |
| 分からない | 決まっていない | いちばん危ない状態。緊急のときに、誰も動けない |
特に気をつけたいのは、2 つ目と 3 つ目です。サイトを作った会社や担当者がもういない、レンタルサーバーだと思っていたら実は VPS だった、というケースでは、期限が切れていることにも、緊急の脆弱性が出たことにも気づけません。
自社サイトの PHP のバージョンを確かめる 3 つの方法
バージョンを確かめる方法は、サイトの置き場所によって 3 つあります。どれか 1 つで分かれば十分です。
-
レンタルサーバーなら、管理画面で確かめる。 多くのレンタルサーバーには「PHP のバージョン設定」の画面があり、いまのバージョンが表示されます。
-
VPS・クラウドなら、サーバーを触れる人に頼む。 サーバー上で
php -vというコマンドを実行するとバージョンが出ます。作った会社や委託先には、次のように聞くと伝わります。本番のサーバーで動いている PHP のバージョン (
php -vの結果) と、PHP を更新するのは誰か (サーバーの提供元か、御社か、当社か) を教えてください。 -
どちらも分からないなら、URL を入れて確かめる。 当社の 無料 URL 診断 は、サイトの URL を入れるだけで、PHP で動いているかと、サーバーがレンタルか VPS かの目安を返します。トップページを 1 回読み込むだけで、サイトに負荷や変更は加えません。ただし外から見える範囲の目安なので、バージョンはレンタルサーバーや CDN を通したサイトではほとんど分かりません。分からなかったときは、1 か 2 で確かめてください。
確かめた後にすることは、次の図のとおりです。
flowchart TD
A["PHP のバージョンを確かめる"] --> B{"バージョンは 8.3 以降か"}
B -->|"はい"| C["期限の内側。緊急時は修正版を入れるだけ"]
B -->|"8.2"| D["年内に期限切れ。11〜12 月に 8.3 以降へ上げる計画を立てる"]
B -->|"8.1 以前"| E["すでに期限切れ"]
E --> F{"PHP を管理しているのは"}
F -->|"レンタルサーバーの提供元"| G["提供元の案内に沿ってバージョンを切り替え、動作を確かめる"]
F -->|"自社か委託先"| H["上げる計画を立てる。決まるまでは緊急時の手順を決めておく"]
F -->|"分からない"| I["まず誰が管理しているかを確かめる"]
8.2 を使っているなら、年内に 8.3 以降へ上げる計画を立てる
PHP 8.2 は 2026 年 12 月 31 日で期限が切れるので、11〜12 月のうちに 8.3 以降へ上げる計画を立ててください。年が明けてから緊急の脆弱性が見つかれば、8.2 には公式の修正が出ません。10 月の 8.1 と同じことが起きます。
上げるときに一緒に確かめたいのが、サイトを動かしているフレームワーク (プログラムの土台) です。PHP だけを上げると、土台が新しい PHP に対応しておらず、動かなくなることがあります。業務システムでよく使われる Laravel の場合、対応する PHP とサポート期限は次のとおりです (出典: Laravel の Release Notes)。
| Laravel | 対応する PHP | 安全のための修正 |
|---|---|---|
| 8 | 7.3〜8.1 | 2023 年 1 月で終了 |
| 9 | 8.0〜8.2 | 2024 年 2 月で終了 |
| 10 | 8.1〜8.3 | 2025 年 2 月で終了 |
| 11 | 8.2〜8.4 | 2026 年 3 月で終了 |
| 12 | 8.2〜8.5 | 2027 年 2 月 24 日まで |
たとえば Laravel 9 のシステムは、PHP を 8.3 に上げると公式の対応から外れます。PHP を上げる前に、土台のバージョンも確かめて、どこまで一緒に上げるかを決めておく必要があります。
当社の判断: 緊急時は配布元の修正版でしのぎ、必要なタイミングで土台ごと上げる
当社の API 3 台は Laravel 8 で動いています。Laravel 8 が対応する PHP は 8.1 までなので、PHP を期限の内側 (8.2 以降) へ上げるには、Laravel を 12 以降まで、4 段階ほど上げる必要があります。これは数日で済む作業ではありません。
そこで 10 月は、配布元の修正版で 8.1 のまま安全を確保しました。そのうえで、3 台は必要なタイミングで Laravel ごと上げます。配布元の修正版は時間稼ぎで、期限の内側に戻ることの代わりにはならないからです。
ここで伝えたいのは、期限が切れた PHP を今すぐ全部上げるべきだ、ということではありません。大事なのは、期限が切れていることを知っていて、緊急のときに誰が何をするかが決まっていることです。当社が 10 月に翌日で対応できたのは、バージョンも構成も把握していて、配布元の修正版で済むかどうかをすぐに判断できたからです。作った人がいなくなったシステムでは、この判断をする人がいません (この問題は エンジニアは採用か外注か でも書いています)。
当社では、作って終わりではなく、PHP の更新のような保守まで含めた業務システムや Web サービスの開発をお手伝いしています。サイトの PHP のバージョンや、誰が更新するのかが分からない場合は、無料 URL 診断で確かめるところから始めてください。期限切れの PHP の更新や、作った会社がもういないシステムの引き継ぎは、お問い合わせフォームか LINE 公式アカウントからご相談いただけます。
