サイガード TOP料金プラン無料診断を申し込む
無料診断を申し込む無料診断

PHP・WordPressの期限

PHP 8.1 以前は修正が出ない。動いているサイトはどうなる?

この記事の結論

  • PHP 8.1 以前は開発元のサポートが終わり、2026年10月の php2shell でも公式の修正版は出なかった
  • 多くのレンタルサーバー会社が独自に手当てしたが、応急処置で次も同じとは限らない
  • バージョンとサーバーの種類を確かめ、検証してから 8.3 以上へ上げる。すぐ無理なら移管や作り直しも比べる

PHP 8.1 以前は、開発元のサポートが終わり、新しい脆弱性が見つかっても公式の修正が出ないバージョンです。2026年10月の PHP の脆弱性でも、8.1 以前には通常の修正版が出ませんでした。

「修正が出ない」とは具体的にどういう状態かを把握すると、自社のHPがどれくらい急いで対応すべきかを判断することが可能です。今回サーバー会社がどう手当てしたかを知れば、「今回は大丈夫だった」で止まらずに済みます。

本記事では、PHP 8.1 以前に修正が出ない仕組み・2026年10月に起きたこと・自社が対象かの確かめ方をまとめています。さらに、やることの優先順位と、すぐ上げられないときの選択肢も紹介します。

PHP 8.1 以前に修正が出ないとは【早見表】

PHP 8.1 以前に修正が出ないとは【早見表】

PHP 8.1 以前に修正が出ないとは、開発元の PHP プロジェクトが、脆弱性(攻撃に使われる弱点)を直した新しい版をもう出さない状態のことです。PHP とは、WordPress などのHPを動かしているプログラムの言語で、開発元はバージョンごとに決めた期限までしか修正を出しません。

期限を過ぎてもHPはそのまま動くため、困りごとが目に見えにくいのが特徴です。ここでは、バージョン別の状態を早見表で示したうえで、サポートが終わると何が変わるかを解説します。

PHP のサポート期限とバージョン別の状態

PHP 公式サイトによると、各バージョンのサポート期限は以下のとおりです。

バージョン 開発元のサポート 状態(2026年10月時点)
PHP 8.5 2029年12月31日まで サポート中
PHP 8.4 2028年12月31日まで サポート中
PHP 8.3 2027年12月31日まで セキュリティ修正のみ
PHP 8.2 2026年12月31日まで セキュリティ修正のみ(年末で終了)
PHP 8.1 2025年12月31日に終了(最後は 8.1.34) 修正が出ない
PHP 8.0 2023年11月26日に終了(最後は 8.0.30) 修正が出ない
PHP 7.4 2022年11月28日に終了(最後は 7.4.33) 修正が出ない

※2026年10月時点・PHP 公式サイト「Supported Versions」「Unsupported Branches」より

PHP 7.3 以前や 5.x も、もちろん修正は出ません。年末に期限を迎える 8.2 を含めた全体の話は、以下の記事にまとめています。

あわせて読みたい
PHP 8.2 のサポート終了で中小企業のHPがやること

サポートが終わると何が変わるか

サポートが終わると、新しい脆弱性が見つかっても、開発元から直した版が出なくなります。PHP 公式は、サポートが終わったバージョンを使い続けると、新しい版で直された脆弱性やバグにさらされるおそれがあるとして、早めに上げるよう強く勧めています。

たとえば、PHP 8.1 で動くHPは、2026年1月以降に見つかった脆弱性について、開発元の修正を受けられません。

ただし、サポートが終わった瞬間にHPが止まったり、乗っ取られたりするわけではありません。危険が現実になるのは、攻撃に使える脆弱性が見つかったときです。

2026年10月の php2shell で 8.1 以前に起きたこと

2026年10月の php2shell で 8.1 以前に起きたこと

2026年10月21日、PHP 本体の重大な脆弱性が2件(CVE-2026-109618/109619、通称 php2shell)公表されました。ログインなしで外からプログラムを実行されるおそれがあり、深刻度は CVSS v4.0(脆弱性の深刻さの物差し)で 9.2 です。

国内でも、IPA と JPCERT/CC が2026年10月22日に注意喚起を出しています。ここでは、8.1 以前がどう扱われたかを3つに分けて解説します。

PHP 公式の扱いはバージョンで3つに分かれた

PHP 公式の発表では、php2shell への扱いがバージョンによって3つに分かれました。8.1 以前はサポートが終わっているため、通常の修正版の対象から外れたからです。

バージョン PHP 公式の扱い
8.2〜8.5 修正版(8.2.35・8.3.36・8.4.27・8.5.12)を公開
8.1 以前 PHP プロジェクトからは更新を出さない。OS の配布元や長期サポートの業者に問い合わせるか、サポート中のバージョンへ上げるよう案内
7.4・8.0・8.1 自分で PHP を組み立てる人向けに、最小限の修正コードを公開

※2026年10月21日時点・PHP 公式サイトのセキュリティ発表より

最小限の修正コードは、自分でサーバーを管理し、PHP を組み立てられる人向けのものです。レンタルサーバーの利用者が自分で当てるものではありません。脆弱性の全体像は PHP の重大な脆弱性の記事 にまとめています。

レンタルサーバー各社は独自に手当てした

レンタルサーバーでは、多くの会社が 8.1 以前のバージョンにも独自に修正を当てました。共用のレンタルサーバーでは、PHP をサーバー会社が管理しているからです。

主なサーバー会社の発表は、以下のとおりです。

サーバー会社 8.1 以前への対応(各社の発表より)
ConoHa WING 5.6〜8.5 の提供中の全バージョンにパッチを適用(10月22日に完了)
さくらのレンタルサーバ コントロールパネルで選べる全バージョンに対応済み。サポート中の最新版への移行を勧める
ロリポップ! 7.4〜8.1 に開発元の修正コード、5.3〜7.3 に自社で作った修正を適用。8.2 以上への切り替えを求める
お名前.com(ベーシック・RS・AIホームページパック) 提供中の全バージョンにパッチを適用(10月22日に完了)

※2026年10月22日時点・各社の公式発表より

たとえば ConoHa WING やお名前.com では、パッチを当ててもバージョンの番号が変わりません。番号の末尾だけで判断せず、サーバー会社のお知らせで確かめてください。各社の詳しい対応は レンタルサーバー各社の対応状況まとめ にまとめています。

手当ては応急処置で、次の保証はない

レンタルサーバー各社の手当ては、今回かぎりの応急処置です。ロリポップ!は報告の中で、PHP 8.1 以下はすでに開発元のサポートが終わっていて、今回の対策は応急的なものだと明言しています。

同じ報告では、今後の脆弱性には開発元の修正も、ロリポップによる対応も提供されない可能性があると書かれています。たとえば、今回は開発元が例外的に最小限の修正コードを出しましたが、次も出るとは限りません。

ただし、すべてのサーバー会社が同じ考えとは限りません。それでも「次も守ってもらえる」と前提にするのは危険です。

自社のHPが PHP 8.1 以前か確かめる方法

自社のHPが PHP 8.1 以前か確かめる方法

自社のHPが PHP 8.1 以前かどうかは、PHP のバージョンとサーバーの種類の2つで判断します。同じ 8.1 でも、レンタルサーバーか自社で管理するサーバーかで、誰が直すかが変わるためです。

確かめるだけなら、設定は何も変わりません。ここでは、バージョンの見方から攻撃の兆候の確かめ方まで、4つの手順で紹介します。

バージョンを見る

PHP のバージョンは、WordPress の管理画面かサーバーの管理画面で確かめます。WordPress なら、「ツール」→「サイトヘルス」→「情報」→「サーバー」に PHP のバージョンが出ています。

管理画面に入れない場合は、制作会社や保守会社に「PHP のバージョンはいくつですか」と聞くのが近道です。ほかの方法は 自社HPの PHP バージョンを確認する方法 にまとめています。

サーバーの種類で、誰が直すかを確かめる

次に、HPがどんなサーバーで動いているかを確かめます。サーバーの種類によって、PHP に修正を当てる人が違うからです。

  • 共用のレンタルサーバー:サーバー会社が PHP を管理する。今回のような手当ては、サーバー会社が判断する
  • VPS・クラウド・自社サーバー:自分たち(または保守会社)が PHP を管理する。手当ても自分たちで行う

たとえば、さくらインターネットの対応状況の案内でも、レンタルサーバーとマネージドサーバ以外の VPS やクラウドは別の案内になっています。どちらか分からない場合は、毎月の請求書のサービス名を確かめてください。

状況別に判断する

バージョンとサーバーの種類が分かったら、以下の表で判断します。

状況 判断
8.3 以上 今回は対象外。次の期限に向けて計画する
8.2 修正版あり。ただし年末で終わるため、年内に 8.3 以上へ
8.1 以前・レンタルサーバー・手当て済み 当面はしのげている。早めに 8.3 以上へ上げる計画を立てる
8.1 以前・レンタルサーバー・手当てが確かめられない サーバー会社に問い合わせる。上げる準備を急ぐ
8.1 以前・VPS や自社サーバー 自分たちで手当てが必要。管理している人か専門家にすぐ相談する

上記の表で下の行ほど、急いで動く必要があります。

すでに攻撃を受けていないかを確かめる

8.1 以前で動いていて手当てが遅れた可能性がある場合は、すでに攻撃を受けていないかも確かめます。php2shell はログインなしで外からプログラムを実行されるおそれがある脆弱性で、ロリポップ!の報告でも脆弱性を狙ったとみられるアクセスの試みが確認されているからです。

確かめるポイントは、以下のとおりです。

  • 身に覚えのないページが検索結果に出ていないか
  • HPを開くと別のサイトに飛ばされないか
  • WordPress に知らない管理者アカウントが増えていないか
  • サーバー会社から不審なファイルの連絡が来ていないか

症状ごとの確かめ方は HPの改ざんの前ぶれを症状別に確かめるチェック表 にまとめています。当てはまるものがあれば、自分で直そうとせず、先に専門家に相談してください。

PHP 8.1 以前のサイトでやること【優先順位つき】

PHP 8.1 以前のサイトでやること【優先順位つき】

PHP 8.1 以前のサイトでやることは、サーバー会社の手当ての確認から始まり、8.3 以上への引き上げで終わります。古いバージョンからの引き上げは崩れる可能性があるため、順番を守ることが重要です。

8.2 を経由せず、最初から 8.3 以上を目標にするのがポイントです。ここでは、やることを優先順位の高い順に4つ紹介します。

【1】サーバー会社の手当てを確かめる

最初に、使っているサーバー会社が今回の脆弱性に手当てをしたかを、公式のお知らせで確かめます。手当てがなければ、引き上げより先にサーバー会社への問い合わせが必要だからです。

たとえば、ConoHa WING・さくらのレンタルサーバ・ロリポップ!・お名前.com は、10月22日に対応を発表しています。ただし、同じ会社でもプランによって案内が分かれていることがあります。

【2】上げる先を 8.3 以上に決める

次に、上げる先のバージョンを 8.3 以上に決めます。8.2 は2026年12月31日でサポートが終わり、いま 8.2 に上げてもすぐに次の引き上げが必要になるからです。

WordPress のサイトなら、WordPress.org の推奨も PHP 8.3 以上です。ただし、サーバーによっては 8.3 を選べず、8.4 になる場合もあります。

【3】8.0〜8.2 で変わった点を確かめる

8.1 以前から上げる場合は、PHP 8.0〜8.2 で変わった点に自社のサイトが引っかからないかを確かめます。PHP 公式のマニュアルによると、8.0 では古い命令の削除や数字と文字の比べ方の変更が入り、8.2 でも古い書き方の一部が「非推奨」(将来なくなる予定)になったからです。

たとえば PHP 8.2 では、クラスで宣言していないプロパティ(データの入れ物)をあとから作る書き方が非推奨になりました。古いテーマや独自のプログラムでよく見られる書き方です。

ただし、どこまで影響するかはサイトの作りしだいです。WordPress のサイトなら、本体・テーマ・プラグインを最新にするだけで解決することもあります。

【4】確認用の環境で試してから切り替える

本番を切り替える前に、確認用の環境(ステージング)で 8.3 以上にして試します。古いバージョンからの引き上げは崩れる可能性が高く、本番でいきなり試すと問い合わせや注文を取りこぼすからです。

確かめる項目は、以下のとおりです。

  • トップページと主なページの表示
  • 問い合わせフォームの送信とメールの受信
  • 管理画面での投稿の保存
  • ネットショップなら、カートから決済の手前まで

上記で問題がなければ、バックアップを取ってから本番を切り替えます。崩れた場合は、すぐ元のバージョンに戻してから原因を調べてください。

PHP 8.1 以前からすぐ上げられないときの選択肢

PHP 8.1 以前からすぐ上げられないときの選択肢

PHP 8.1 以前から、すぐには上げられないサイトもあります。作った会社がいない、テストのしくみがない、独自のプログラムが新しい PHP で動かない、といった事情があるためです。

すぐ上げられない場合でも、何もしないのは危険です。ここでは、つなぎの対策の限界と、延命・移管・作り直しの比べ方を紹介します。

緩和策は「安全にする」ものではない

php.ini(PHP の動きを決める設定ファイル)の設定で、攻撃をしにくくする緩和策があります。ただし、PHP 公式は、緩和策は攻撃の経路を減らすだけで、環境を安全にするものではないと明記しています。

たとえば、PHP 公式は修正版へ更新できるまでの間だけ緩和策を使い、まず修正版へ上げることを勧めています。緩和策で済ませて、引き上げを先送りにしないでください。

ただし、レンタルサーバーでは、サーバー会社がすでに必要な設定をしている場合があります。自分で php.ini を書き換える前に、サーバー会社のお知らせを確かめてください。

延命・移管・作り直しを比べる

すぐ上げられないサイトは、延命・移管・作り直しの3つを比べて道を決めます。直す費用と期間が、作り直しと変わらないこともあるからです。

選択肢 向いているケース 注意点
延命(独自のプログラムを直して上げる) プログラムの量が少なく、直せる人がいる 直す人がいないと進まない
長期サポートの業者に頼る(自社サーバーの場合) 業務システムですぐ作り直せない 費用がかかり、根本の解決ではない
移管(安全な環境へ移す) 見た目や内容はそのまま使いたい 移せる作りかを先に確かめる
作り直し 古すぎて直すより早い 期間がかかるため、それまでの守りが必要

※長期サポートの業者への問い合わせは、PHP 公式のセキュリティ発表で 8.1 以前の利用者に案内されている方法です

移管と作り直しの判断のしかたは、移管で済む? 作り直す? にまとめています。

PHP 8.1 以前のサイトを専門家に相談すべきとき

PHP 8.1 以前のサイトを専門家に相談すべきとき

PHP 8.1 以前で動いているサイトは、作ってから年数がたっていることが多く、上げるとどこが崩れるかは中を見ないと分かりません。特に、自社で管理するサーバーで動いている場合は、誰かが手当てしないかぎり守られません。

自分で進めるのが難しい条件があります。ここでは、専門家に相談すべき場面を整理します。

  • VPS や自社サーバーで動いていて、管理している人がいない
  • 改ざんの兆候が1つでも当てはまる
  • 作った会社と連絡が取れず、独自のプログラムか分からない
  • 確認用の環境を作れる人がいない

「自社が対象か分からない」「作業する人がいない」場合は、HPの移管・保守サービス『サイガード』の無料診断をご利用ください。URLを送るだけで、外から見える範囲をセキュリティの専門家が確認します。

まとめ

まとめ

  • PHP 8.1 以前は開発元のサポートが終わり、2026年10月の php2shell でも公式の修正版は出なかった
  • 多くのレンタルサーバー会社が独自に手当てしたが、応急処置で次も同じとは限らない
  • バージョンとサーバーの種類を確かめ、自社サーバーなら自分たちで手当てが必要
  • 上げる先は 8.3 以上。すぐ無理なら緩和策で済ませず、延命・移管・作り直しを比べる

まずは自社のHPの PHP のバージョンと、サーバー会社のお知らせを確かめてください。

よくある質問

PHP 8.1 以前でも、レンタルサーバーなら守られているのでは?

2026年10月の php2shell では、ConoHa WING・さくらのレンタルサーバ・ロリポップ!・お名前.com などが、古いバージョンにも独自に修正を当てたと発表しました。ただしロリポップは、8.1 以下への対策は応急的で、今後の脆弱性には修正が提供されない可能性があるとしています。

PHP 公式が出した「最小限の修正コード」を当てれば直るのでは?

PHP 公式が 7.4・8.0・8.1 向けに出したのは、自分で PHP を組み立てる人のための最小限の修正コードです。レンタルサーバーの利用者が自分で当てるものではなく、当てるかどうかはサーバー会社しだいです。

PHP 8.1 から 8.2 に上げれば十分ですか?

PHP 8.2 も2026年12月31日で開発元のサポートが終わります。いま上げるなら、2027年12月31日まで修正が出る 8.3 以上を目安にしてください。

VPS や自社のサーバーで PHP 8.1 以前を動かしている場合は?

サーバー会社は手当てしてくれません。PHP 公式は、8.1 以前は OS の配布元や長期サポートの業者が修正を出している場合があるので問い合わせるか、サポート中のバージョンへ上げるよう案内しています。管理している人がいなければ、専門家に相談してください。

php.ini の設定を変えれば、PHP 8.1 以前でも安全になりますか?

安全にはなりません。PHP 公式は、設定による緩和策は攻撃の経路を減らすだけで、環境を安全にするものではないと明記しています。修正が当たったバージョンへ上げるまでのつなぎと考えてください。

SUPERVISORこの記事の監修

田中 省吾

システムエンジニア/AIコンサルタント

CAREER経歴

  • 元 大手空調メーカーのシステムエンジニア
  • 業務系Webアプリケーションの設計・開発・運用
  • バックエンド・フロントエンド・インフラ構築

元大手空調メーカーのシステムエンジニア。現在はシステムエンジニア兼AIコンサルタントとして活動。業務系Webアプリケーションの設計から運用、バックエンド、フロントエンド、インフラ構築まで一貫して対応する。

監修者の一覧を見る

出典・参考

  • #PHP
  • #サポート終了
  • #脆弱性
  • #レンタルサーバー