PHPの脆弱性でなぜサービス終了?「更新するだけ」では済まない理由

古いWebサービスが脆弱性への対応を機に終了するのは、PHPの弱点を直す作業に加え、その上で動くサービスを直し、安全に保守し続ける体制まで必要になることがあるからです。
2026年10月の「PHP2shell」では、PHPの開発元が緊急の修正版を公開しました。一方で、修正の適用を待って再開するサイトもあれば、今後の運営方法を見直す必要があるサイトもあります。
「新しいPHPにすれば済むのでは?」という疑問を、修正と移行の違いから見ていきます。古いPHPへの修正が提供される例外も含めて説明するため、「古いサービスはすべて閉じるしかない」という話ではありません。
一時停止とサービス終了は、同じ意味ではない

まず分けたいのは、対策のために一時的に公開を止めることと、サービスの提供そのものを終えることです。どちらも画面は見られなくなりますが、その後の予定は異なります。
PHPはWebサービスを裏側で動かす仕組み
PHPは、サーバーでプログラムを実行するために使われる言語です。PHPで作られたログイン、投稿、検索、問い合わせフォームなどは、利用者が操作したときにサーバー側で処理されます。
今回の問題は、各サイトの文章を書き換えれば直る種類のものではありません。PHP自体の処理に弱点があり、悪用されると外部から不正なプログラムを実行されるおそれがあるため、実行環境を管理する側の対応が必要です。
PHP公式は10月21日、8.2.35・8.3.36・8.4.27・8.5.12を修正版として案内しました。これらは当該発表時の修正版であり、将来もその番号が最新版という意味ではありません。
止まっているだけでは、終了とも被害発生とも分からない
一時停止は、対策や確認が済むまでアクセスを止める対応です。奈良県事業承継・引継ぎ支援センターは、PHPの更新や動作確認を経て、10月23日に公開を再開したと発表しています。
東京科学大学の告知でも、再開した環境と、PHP7系への対応ができず停止を続ける環境が分かれています。停止中の環境については今後の方針を別途案内するとしており、これを恒久的な終了事例として数えることはできません。
「閉鎖」「停止」という短い言葉だけで、終了や情報漏えいが確定したと受け取らず、運営者の告知で理由と再開予定を確かめることが大切です。
「修正を当てる」と「新しいPHPへ移す」は作業が違う

更新とひとくくりに呼ばれていても、現在の環境へ修正を組み込む作業と、古い世代から新しい世代へ移行する作業では、確認する範囲が変わります。
同じ系統の修正版を適用する場合
公式サポート中の環境なら、その系統の修正版を適用することが基本になります。例えば8.3系の修正適用と、PHP5系で動いていたサービスを8系へ移すことは、同じ規模の仕事とは限りません。
ただし、修正版なら動作確認が不要という意味でもありません。設定、拡張機能、アプリケーションの使い方によって影響は異なります。10月23日にもPHP公式から条件付きの追加情報が出ているため、古い案内だけで対応済みと判断せず、提供元の最新情報を確認する必要があります。
古いプログラムを新しい環境へ移す場合
PHPは新しい世代になる過程で、使えなくなる機能や、以前とは結果が変わる処理があります。PHP公式の移行資料にも、過去のプログラムと互換性がなくなる変更がまとまっています。
古いサイトがその処理を使っていれば、PHPだけを切り替えると、ページが開かない、入力内容を保存できない、といった不具合につながる可能性があります。必要になるのは、環境の切り替えに加えて、影響するコードの特定、修正、テストです。
| 作業 | 何を確かめるか |
|---|---|
| 修正の適用 | 使っている環境に必要な修正が入り、サービスが正しく動くか |
| 新しい世代へ移行 | 廃止・変更された処理、関連ソフトとの組み合わせ、保存データや機能への影響 |
長年動いてきたことは、今までの組み合わせで動く証拠にはなります。しかし、環境を変えた後も同じように動くことまでは保証しません。
古いPHPでも、提供会社が修正することがある
ここには例外があります。PHP公式は、通常の更新が終わった古い系統についても、提供会社が修正を古い版へ組み込む場合があると案内しています。今回も7.4・8.0・8.1向けに最小限のソースコード修正を提供しました。
このように修正を古い版へ取り込むことを、バックポートといいます。東京科学大学の告知にも、PHP本体のバージョン表記を変えずに修正済みパッケージを適用した例があります。
したがって、古い番号だから今回の修正が必ず未適用とも、今回修正されたから将来の保守も安心とも言えません。今回の修正提供と、今後も維持できる環境かどうかを分けて考える必要があります。
直せることと、これからも続けられることは別

技術的に直せる見通しがあっても、調査や確認を担当する人がいなければ、すぐに公開へ戻せるとは限りません。終了判断の背景には、修正そのものと、その前後の仕事があります。
表示以外の機能も確かめる必要がある
トップページが開いただけでは、サービス全体を確認できたことにはなりません。例えば会員制サービスなら、ログイン、投稿、画像の登録、検索、メール通知など、利用者が実際に使う操作を確かめます。決済機能があれば、その接続先との連携も確認対象になります。
これは本記事で整理した確認例で、すべてのサイトに同じ機能があるわけではありません。必要なテストは、そのサービスが何を提供しているかで変わります。
古いサービスでは、当時の設計資料が残っていない、担当者が交代している、使っていた部品の保守が終わっているといった条件も考えられます。個別サービスに当てはまるかは、公表された情報や実際の調査がなければ断定できません。
無料サービスにも、調査と保守の仕事は残る
利用料金が無料でも、修正箇所を探す時間、データを守る準備、動作確認、その後の問い合わせ対応は発生します。運営者自身が作業する場合も、その人の時間が必要です。
そして今回直すだけでなく、次の弱点や環境変更が見つかったときに、誰が対応するかも決める必要があります。修正費用を一度払えるかと、これから保守を続けられるかは、別の判断です。
IPAは、継続のための人員・予算・保守体制を確保できるかを組織として検討し、見通しが立たない場合には、機能縮小や公開終了も含めて方針を決めるよう案内しています。
この観点で見ると、脆弱性は終了のきっかけであり、その背景には安全に提供し続ける条件を、これからも満たせるかという問題があると理解できます。終了したサービスを一律に「更新を怠ったから」「お金がないから」と説明するのは正確ではありません。
機能を減らして残すか、安全に閉じるか

今の仕組みを直すことが難しい場合も、すべてを同じ形で残すか、すべてを失うかの二択とは限りません。残したい価値と、動かし続ける必要がある機能を分けると、別の選択肢が見えてきます。
移行・機能縮小・静的な保存という選択肢
利用者が今も使う機能なら、保守を受けられる別の仕組みへ移す方法があります。一方、過去の記事を読むことだけが目的なら、投稿や会員登録を止め、閲覧用のページとして残す方法も検討できます。
例えば掲示板を閲覧専用にして、内容を静的なHTMLへ書き出す、という考え方です。ただし、投稿を止める設定だけでは、裏側で古いPHPが動き続ける場合があります。PHPへの依存を外すには、検索やフォーム、管理画面なども含めた点検が必要です。
| 残したいもの | 検討できる方法 |
|---|---|
| 今後も使う機能 | 保守できる環境や別サービスへ移行する |
| 過去の公開情報 | 機能を減らし、閲覧専用・静的なページとして保存する |
| 安全な提供が難しい | 必要な案内やデータの扱いを整理して終了する |
この表は、公式の対応方針を踏まえて本記事で整理したものです。静的な保存でも、個人情報、非公開の投稿、画像などの権利、公開してよい範囲を確認する仕事は残ります。保存すればそのまま公開してよいわけではありません。
利用者が確認したいのは、期限とデータの扱い
使っていたサービスが止まった場合は、運営者の告知から次の点を確認すると、必要な行動を決めやすくなります。
- 停止か終了か:再開予定があるか、方針がまだ未定なのか
- 自分のデータ:取り出せるか、どの形式か、受付期限があるか
- 予約・購入・契約:残っている手続きや代替窓口が案内されているか
- 次のお知らせ:公式サイト、公式アカウント、登録メールのどこに出るか
停止中にアクセスを繰り返したり、非公式の復旧ページへログイン情報を入力したりせず、公式の案内を待ちます。データを取り出す場合も、公開されている正規の手段を使います。
大切なサービスが終わるのは残念です。それでも、安全に動かし続ける条件を満たせないまま公開するより、残せる情報を残して区切りをつける判断には理由があります。「なぜ直さないのか」だけでなく、「直した後も誰が守り続けるのか」まで見ると、終了という判断の背景が分かります。
よくある疑問
PHPが古いサイトは、すべて閉鎖が必要ですか?
一律には決まりません。修正の提供状況、実際の構成、動作確認や今後の保守ができるかで変わります。今回の対応でも、古い版へ修正を組み込む提供会社があります。バージョン番号だけで判断せず、管理者や提供元の対応状況を確認します。
バックアップがあれば、そのまま続けられますか?
バックアップはデータやファイルを戻すための備えで、動いているPHPの弱点を塞ぐものではありません。修正や必要な移行とは別に用意します。古い環境へ戻せることと、安全に公開できることは異なります。
アクセス制限や防御サービスだけでは駄目ですか?
更新までの間に危険を減らす対策として検討できますが、修正そのものと同じではありません。PHP公式は一時的な緩和策だけで安全になるとはしていません。適用できる対策は構成によって異なるため、管理者や保守会社が最新の公式情報に基づいて判断します。