レンタルサーバーやCMSで使っているPHPのバージョンを、導入時のまま一度も確認していない担当者は少なくありません。

PHPには公式のサポート終了日があり、終了後は脆弱性が見つかっても修正プログラムが提供されません。

この記事では、PHPのサポート終了（EOL）がリスクになる理由、バージョンごとの終了日、そして自分の手元で安全に確認する方法までを解説します。

サポートが終了したPHPは、脆弱性が見つかっても修正プログラムが提供されません！

まず、主要なPHPブランチのセキュリティサポート終了日を一覧で示します。

この一覧は、PHP公式サイトが公開している現時点のセキュリティサポート終了日をもとにしています。

引用元：The PHP Group「Supported Versions」 https://www.php.net/supported-versions.php

終了日は新しいバージョンがリリースされるたびに更新されるため、最新の日付は都度php.net公式サイトで確認しましょう。

サーバーやCMSの構成によって実際に選べるバージョンは異なるため、この一覧はあくまで目安として扱ってください。

PHPのサポートには期限がある｜バージョンごとの終了日

なぜPHPにサポート期限があるのか

PHPは毎年11月ごろに新しいメジャーバージョンをリリースするサイクルで開発されています。

古いバージョンを無期限に保守し続けると、開発チームの負担が増え、新しい機能や性能改善への対応が遅れます。

そのためPHP公式は、各バージョンに「アクティブサポート」と「セキュリティサポート」という2段階の期限を設けています。

この仕組みは、PHPを使う側と開発チームの両方にとって保守の見通しを立てやすくするためのものです。

引用元：The PHP Group「Supported Versions」 https://www.php.net/supported-versions.php

現在サポートされているPHPのバージョンと終了日

リリースから2年間は「アクティブサポート」としてバグ修正とセキュリティ修正の両方が提供されます。

その後の2年間は「セキュリティサポート」として、セキュリティ修正のみが提供される期間になります。

2026年10月時点で、PHP 8.2・8.3・8.4・8.5の4ブランチがセキュリティサポート中です。

このうちPHP 8.2は、2024年12月31日にアクティブサポートを終え、現在はセキュリティサポートのみの期間に入っています。

最新のPHP 8.5は2025年11月にリリースされたばかりで、アクティブサポートは2027年12月31日まで続きます。

引用元：The PHP Group「Supported Versions」 https://www.php.net/supported-versions.php

Web・モバイルアプリ・AIアプリの実績多数

Last Sceneへお任せください！

• 開発は丸投げしたいがプロジェクトができるか不安
• リードエンジニアがいない
• パフォーマンスはもちろんのことコストにもこだわりたい

八木（Last Scene）

大規模アプリ開発や、0からのサービス開発など
案件の規模に合わせた最適なご提案が可能です。

事例・相見積りの問い合わせはこちら

セキュリティ顧問のご相談は、LINEの友だち追加から気軽にどうぞ。 LINEで相談する

すでにサポートが終了しているバージョン

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日にそれぞれ終了しています。

引用元：The PHP Group「Unsupported Branches」 https://www.php.net/eol.php

自社で使っているサーバーがこの一覧に含まれるバージョンのままであれば、すでにサポート外の状態です。

サーバー会社が初期設定で古いバージョンのままにしているケースもあるため、導入時の設定を引き継いでいる場合は注意しましょう。

契約時の設定を見直す機会がないまま運用を続けていると、古いバージョンが残っていることに気づきにくくなります。

今使っているバージョンの残りサポート期間を自分で計算する

残りのサポート期間は「セキュリティサポート終了日－今日の日付」で計算できます。

例えば2026年10月24日にPHP 8.2（終了日2026年12月31日）を使っている場合、残りは約2か月です。

同じ計算をPHP 8.3（終了日2027年12月31日）に当てはめると、残りは1年以上あることが分かります。

このように自社のPHPバージョンと今日の日付を照らし合わせれば、アップグレードまでに使える期間を自分で把握できます。

残り期間が1年を切っている場合は、早めに影響調査に着手しましょう。

引用元：The PHP Group「Supported Versions」 https://www.php.net/supported-versions.php

終了日ギリギリで一斉にアップグレードすると、動作確認の時間が足りなくなります。

サポートが終わったPHPを使い続けるとどうなるか

脆弱性が見つかっても修正プログラムが提供されない

サポートが終了したソフトウェアは、新たに脆弱性が見つかっても開発元による修正が行われません。

その結果、脆弱性を悪用した攻撃による情報漏えいやサービス停止が起きる可能性が高まります。

引用元：IPA「複数のMicrosoft社製品のサポート終了に伴う注意喚起」 https://www.ipa.go.jp/archive/security/security-alert/2020/win7_eos.html

Web・モバイルアプリ・AIアプリの実績多数

Last Sceneへお任せください！

• 開発は丸投げしたいがプロジェクトができるか不安
• リードエンジニアがいない
• パフォーマンスはもちろんのことコストにもこだわりたい

八木（Last Scene）

大規模アプリ開発や、0からのサービス開発など
案件の規模に合わせた最適なご提案が可能です。

事例・相見積りの問い合わせはこちら

セキュリティ顧問のご相談は、LINEの友だち追加から気軽にどうぞ。 LINEで相談する

PHPも例外ではなく、サポート終了後は同様のリスクを抱え続けることになります。

2026年10月に見つかったPHPの重大な脆弱性

2026年10月21日、The PHP Groupは2件の脆弱性（CVE-2026-109618、CVE-2026-109619）に対するセキュリティリリースの公開を予告しました。

引用元：IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」 https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html

これらの脆弱性は「PHP2shell」と呼ばれ、悪用されると遠隔の第三者に任意のコードを実行されるおそれがあります。

対象はPHP 8.2系が8.2.35より前、8.3系が8.3.36より前、8.4系が8.4.27より前、8.5系が8.5.12より前のバージョンです。

引用元：IPA「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」 https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html

IPAは、PHP 8.1以前はすでにサポートが終了しているため修正プログラムが提供されないと明記しています。

JPCERT/CCも同じ2件の脆弱性について注意喚起を出し、修正済みバージョンへのできるだけ速やかな更新を推奨しています。

引用元：JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」 https://www.jpcert.or.jp/at/2026/at260033.html

この件は、サポート中のバージョンを使っていても、更新作業を後回しにできないことを示す事例です。

同時に、サポートが終了したPHP 8.1以前を使い続けている環境は、今後も同種の脆弱性に対して無防備な状態が続くことになります。

修正版が出てから適用するまでの時間が短いほど、被害を受ける前に対策できる可能性が高まります。

WordPressなどCMSを巻き込むリスク

WordPressなどのCMSはPHP上で動作しているため、土台となるPHPの脆弱性はCMS全体のリスクになります。

サーバー側でPHPを更新しても、サイト側のテーマやプラグインが古いPHPを前提に作られていれば、表示崩れやエラーが起きることもあります。

そのため、PHPの更新はCMS側の対応状況も含めて確認する必要があります。

複数のサイトを1つのサーバーで運用している場合、サイトごとにPHPバージョンを切り替えられない構成だと、1つのサイトの古いPHPが他のサイトの切り替えを妨げることもあります。

問い合わせフォームや会員ページを持つサイトでは、個人情報を扱っている分だけ影響範囲も大きくなります。

古いシステムの放置がトラブルに発展する流れは、PHPに限った話ではありません。システム開発が失敗する7つの原因も、あわせて確認しておきましょう。

WordPressが推奨するPHPのバージョン

公式が推奨するバージョンと動作する最低バージョン

WordPress公式サイトは、ホスティング環境としてPHP 8.3以上を推奨しています。

一方で、WordPress自体はPHP 7.4以上でも動作するとしています。

ただし公式は、7.4や8.0・8.1のようにすでに公式サポートが終了したバージョンはセキュリティ上のリスクにつながると明記しています。

引用元：WordPress.org「Requirements」 https://wordpress.org/about/requirements/

つまり「動く」ことと「安全に動く」ことは別で、推奨バージョンとの差が大きいほど見直しの優先度は上がります。

契約しているレンタルサーバーの初期値がどのバージョンになっているかも、あわせて確認しておきましょう。

サイトヘルスに表示される警告の意味

WordPressのサイトヘルス画面では、古いPHPを使っている場合に「サイトは更新が必要なバージョンのPHPで稼働しています」という警告が表示されます。

この警告は「セキュリティ」に分類されており、見た目の不具合ではなく保守上の問題として扱われています。

引用元：WordPress.org「Site Health screen」 https://wordpress.org/documentation/article/site-health-screen/

Web・モバイルアプリ・AIアプリの実績多数

Last Sceneへお任せください！

• 開発は丸投げしたいがプロジェクトができるか不安
• リードエンジニアがいない
• パフォーマンスはもちろんのことコストにもこだわりたい

八木（Last Scene）

大規模アプリ開発や、0からのサービス開発など
案件の規模に合わせた最適なご提案が可能です。

事例・相見積りの問い合わせはこちら

セキュリティ顧問のご相談は、LINEの友だち追加から気軽にどうぞ。 LINEで相談する

この警告が出ている場合は、後回しにせず早めに対応を検討しましょう。

サイトヘルスの「状態」タブを定期的に開く習慣をつけておくと、警告の見落としを防げます。

プラグイン・テーマ側の対応バージョンも確認する

WordPressのプラグインやテーマは、それぞれが対応するPHPバージョンの範囲を持っています。

サーバー側のPHPだけを先に上げると、対応していないプラグインがエラーを起こすことがあります。

サイトヘルスの「情報」タブからは、有効化しているプラグインとテーマの一覧も確認できるため、アップグレード前の棚卸しに活用しましょう。

利用頻度の低いプラグインは、アップグレードを機に無効化や削除を検討するのも一つの方法です。

自分で今のPHPバージョンを確認する方法

ここからは、専門知識がなくても自分で確認できる方法と、確認時に見落としやすい注意点を紹介します。

レンタルサーバーの管理画面で確認する

多くのレンタルサーバーでは、管理画面の「PHP設定」や「PHP Ver.切替」といった項目で現在のバージョンを確認できます。

同じ画面からバージョンの切り替えもできる場合が多く、最も手軽な確認方法です。

サーバー会社によって画面名や操作は異なるため、不明な場合はサーバー会社のサポートに問い合わせましょう。

複数のドメインを1契約で運用している場合は、ドメインごとに設定が分かれていないかも確認しておきましょう。

WordPressのサイトヘルスで確認する

WordPressの管理画面から「ツール」→「サイトヘルス」→「情報」タブを開き、「サーバー」の項目を展開するとPHPバージョンが表示されます。

確認方法の詳細は、前述のサイトヘルスの解説を参照してください。

WordPressを使っているなら、最も手早く確認できる方法です。

画面右上の「情報をクリップボードにコピー」を使えば、確認した内容をそのまま社内共有やベンダーへの問い合わせに使えます。

サーバー側で確認する方法（SSH／PHP-FPM／PHP_VERSION／phpinfo）

サーバーにSSHで接続できる環境であれば、ターミナルでphp -vコマンドを実行するとバージョンが表示されます。

サーバーによってはCLI用とWeb用でPHPのバージョンが異なる場合があるため、両方を確認しておくと安心です。

Web側がPHP-FPMというプロセスマネージャーで動いている場合は、php-fpm -vまたはphp-fpm --versionコマンドで、実際にサイトを表示しているバージョンを確認できます。

引用元：Ubuntu Manpages「php-fpm」 https://manpages.ubuntu.com/manpages/noble/en/man8/php-fpm8.3.8.html

コマンドを使わずに確認したい場合は、PHP_VERSIONという定数をecho文で出力する方法もあります。

PHP_VERSIONは、現在のバージョンを「メジャー.マイナー.リリース」形式の文字列で返す定数で、設定値やサーバー環境の詳細までは表示されません。

引用元：The PHP Group「PHP Manual: Predefined Constants」 https://www.php.net/manual/en/reserved.constants.php

phpinfo()という関数を実行すると、PHPのバージョンに加えて設定値やサーバー環境の詳細が一覧で表示されます。

引用元：The PHP Group「PHP Manual: phpinfo」 https://www.php.net/manual/en/function.phpinfo.php

この情報にはサーバー構成の詳細が含まれるため、確認用のファイルは公開サーバーに置いたままにせず、確認後すぐに削除しましょう。

検索エンジンに情報が残ってしまうこともあるため、公開ディレクトリに置く運用自体を避けるのが安全です。

composer.jsonのplatform設定を確認する

Composerを使っているプロジェクトでは、composer.jsonのrequireにある「php」の指定で想定バージョンを確認できます。

config.platform.phpが設定されている場合は、実機のバージョンと異なる値で依存解決している可能性もあるため、あわせて確認しましょう。

引用元：Composer「The composer.json schema」 https://getcomposer.org/doc/04-schema.md

社内に開発を担当する人がいない場合は、委託先のベンダーにファイルの内容を一緒に確認してもらいましょう。

確認したバージョン番号だけで判断しない

Red Hat Enterprise LinuxなどRHEL系のディストリビューションは、パッケージのバージョン番号を大きく変えずに、セキュリティ修正だけを後から適用する運用をしています。

引用元：Red Hat「Backporting security fixes」 https://access.redhat.com/security/updates/backporting/

Ubuntuも同様に、安定版のパッケージ本体を大きく変えずに、問題ごとの修正だけを当てる方針を取っています。

引用元：Ubuntu Wiki「SecurityTeam/FAQ」 https://wiki.ubuntu.com/SecurityTeam/FAQ

そのため、php -vで表示される番号が古く見えても、ディストリ側で修正パッチだけが先に適用されている場合があります。

レンタルサーバー事業者が独自に修正パッチを適用している場合もあるため、バージョン番号だけで判断せず、契約しているサーバー会社の案内も確認しましょう。

確実に判断したい場合は、php.net公式のChangeLogで、使っているバージョンに該当する修正が反映済みかどうかを確認しましょう。

引用元：The PHP Group「ChangeLog」 https://www.php.net/ChangeLog-8.php

バージョンを確認するときは、本番環境と検証環境でバージョンが揃っているか、composer.jsonで指定しているバージョンと実際に動いているバージョンに差がないかもあわせて照らし合わせておくと、見落としを防げます。

PHPのバージョンアップで次にやること

現在のバージョンとサポート終了日がわかったら、次は実際のアップグレードに向けた準備を進めましょう。

影響調査（プラグイン・ライブラリの対応状況を確認する）

使用しているCMSのプラグインやライブラリが、アップグレード後のPHPバージョンに対応しているかを確認します。

対応状況は各プラグインの配布元ページや、ライブラリのリリースノートで確認できます。システムの作り直しも検討する規模であれば、システム開発の要件定義ガイドも参考にしてください。

自社で開発した独自のプログラムがある場合は、ソースコードの中で非推奨の書き方を使っていないかもあわせて調べましょう。

調査結果は一覧表にまとめておくと、どの機能から着手すべきかの判断がしやすくなります。

テスト環境で動作確認する

本番環境のPHPを直接切り替える前に、ステージング環境など本番と分離した環境で動作を確認しましょう。

主要なページの表示、フォームの送信、決済などの重要な機能は個別に確認しておくと安心です。

管理画面の操作やバッチ処理など、普段の運用で使っている機能もあわせて確認しておきましょう。

エラーログを有効にして、警告レベルのメッセージも見逃さないようにしましょう。

段階的にアップグレードする

複数バージョンを一度に飛び越えるアップグレードは、不具合の原因を特定しづらくなります。

可能であれば1つずつバージョンを上げて、都度動作確認する進め方を選びましょう。

切り替え作業は、アクセスが少ない時間帯を選んで実施すると、不具合が起きた場合の影響を抑えられます。

ベンダー・レンタルサーバーに確認する

利用しているシステムに開発会社やベンダーがいる場合は、対応可能なPHPバージョンとスケジュールを事前に確認しましょう。新たに開発会社を探す場合は、失敗しないシステム開発会社の選び方も参考になります。

レンタルサーバー側の切り替え手順や反映タイミングも、サーバー会社のサポートに確認しておくと移行がスムーズです。

社内に判断できる担当者がいない場合は、外部のセキュリティ顧問に相談する方法もあります。株式会社Last Sceneのセキュリティ顧問サービスでは、PHPバージョンの確認やアップグレード計画の整理にも対応しています。

見直しを後回しにした結果、サポート終了日の直前に慌てて対応する事態は避けましょう。

よくある質問

PHPのバージョンを上げるとサイトの表示は変わりますか

基本的な表示は変わりませんが、古い書き方のコードが残っているテーマやプラグインでは、警告やエラーが表示されることがあります。

そのため、本番反映の前にテスト環境で表示や動作を確認しましょう。

表示崩れが起きた場合も、原因となっているテーマやプラグイン側の対応バージョンを確認すれば切り替えの判断がしやすくなります。

サポートが終了していてもすぐに攻撃されるわけではないのでは

すぐに攻撃を受けるとは限りませんが、サポート終了後に見つかった脆弱性は修正プログラムが提供されないため、リスクは時間とともに積み重なります。

2026年10月の脆弱性のように、サポート中のバージョンでも速やかな対応が呼びかけられる事例もあります（前述のIPA・JPCERT/CCの注意喚起を参照）。

「今は問題が起きていない」ことと「安全である」ことは同じではないと考えておきましょう。

バージョンアップにはどれくらいの期間がかかりますか

システムの規模やプラグインの数によって変わります。

影響調査からテスト環境での確認、本番反映までを含めて余裕を持った計画を立てましょう。

独自開発のプログラムが多いシステムほど、影響調査とテストに時間がかかる傾向があります。

まとめ｜PHPのサポート終了日を把握し、計画的にアップグレードする

PHP 8.1以前はすでにサポートが終了しており、PHP 8.2のセキュリティサポートも2026年12月31日までです。

サポート終了後は脆弱性が見つかっても修正プログラムが提供されず、2026年10月のPHP2shellのようにサポート中のバージョンでも速やかな対応が求められる事例が実際に起きています。

自社のPHPバージョンとサポート終了日を確認し、残り期間に応じて計画的にアップグレードを進めることが大切です。

まずは自分のPHPバージョンとサポート終了日を確認し、計画的にアップグレードを進めましょう！

アップグレード前の確認チェックリスト

1. 現在のPHPバージョンとサポート終了日を確認したか
2. 使用中のプラグイン・ライブラリの対応バージョンを確認したか
3. テスト環境で主要機能の動作を確認する計画があるか
4. 段階的なアップグレードのスケジュールを決めたか
5. ベンダーやレンタルサーバーへの確認窓口を把握したか

株式会社Last Sceneでは、PHPのサポート状況の確認からアップグレード計画の整理まで、要件定義の段階から伴走しています。

現在の構成を棚卸しして、どのバージョンまで安全に使い続けられるか、どの順序でアップグレードを進めるべきかを一緒に整理します。影響調査からテスト環境での確認、本番反映までを継続してサポートできる体制を整えています。

何から手をつければよいか分からない段階でも、まずは今お使いの環境についてお聞かせください。発注の進め方に迷う場合は、システム開発の発注ガイドもあわせてご覧ください。

Web・モバイルアプリ・AIアプリの実績多数

Last Sceneへお任せください！

• 開発は丸投げしたいがプロジェクトができるか不安
• リードエンジニアがいない
• パフォーマンスはもちろんのことコストにもこだわりたい

八木（Last Scene）

大規模アプリ開発や、0からのサービス開発など
案件の規模に合わせた最適なご提案が可能です。

事例・相見積りの問い合わせはこちら

セキュリティ顧問のご相談は、LINEの友だち追加から気軽にどうぞ。 LINEで相談する