2026年10月21日、PHPプロジェクトは深刻度の高い2件の脆弱性の修正を公開しました。サポート中のバージョンを利用しているシステムは、修正をそのまま適用できます。
一方、5〜10年前に構築された業務システムに多い古いバージョンでは、別の対応方針が必要です。本記事では、公開された内容、確認したいポイント、アップグレードと再構築の選び方を整理します。
10月21日に公開された内容
今回のリリースでは、CVE-2026-109618とCVE-2026-109619が修正されました。いずれもCVSS v4.0で9.2（緊急）と評価されており、条件によっては認証なしでサーバー上のコードを実行される可能性があります。
修正版は8.5.12、8.4.27、8.3.36、8.2.35です。
国内では、IPAと国家サイバー統括室が、PHPの利用箇所の把握と速やかな修正の適用を呼びかけました。10月21日には、複数のオンラインサービスが緊急メンテナンスを実施しています。
PHPブランチ別の修正状況
| ブランチ | 10月21日リリースでの修正 | セキュリティサポート終了 |
|---|---|---|
| 8.5 | 8.5.12で修正済み | 2029年12月31日 |
| 8.4 | 8.4.27で修正済み | 2028年12月31日 |
| 8.3 | 8.3.36で修正済み | 2027年12月31日 |
| 8.2 | 8.2.35で修正済み | 2026年12月31日 |
| 8.1 | 限定的なソースバックポートのみ | 終了（2025年12月31日） |
| 8.0 | 限定的なソースバックポートのみ | 終了（2023年11月26日） |
| 7.4 | 限定的なソースバックポートのみ | 終了（2022年11月28日） |
| 7.3以前、5.x | 修正の公開なし | 終了（2018〜2021年） |
Linuxディストリビューションによっては、古いバージョン番号のまま修正を取り込んだパッケージ（バックポート）が提供される場合があります。ご利用中のディストリビューションやホスティング事業者のアドバイザリ（公式の告知）をご確認ください。
確認したい4つのポイント
- PHPのバージョン：8.2〜8.5には修正版があります。7.4〜8.1は限定的なソースバックポートのみで、7.3以前は修正が公開されていません。
- PHPの実行方式：Apacheのmod_php、PHP-FPM、CGIでは、攻撃が成立する条件が異なります。Apacheのmod_phpは、最も優先して対応すべき構成とされています。
- 修正が実際に有効か：php -vで表示されるPHPと、Webリクエストを処理しているPHPが異なる場合があります。修正の適用後は、ワーカー（処理プロセス）の再起動が必要です。
- サポート終了日：PHP 8.2のサポートは2026年12月31日に終了します。今8.2へ移行したシステムは、近いうちに再度のアップグレードが必要になります。
古いPHPシステムのアップグレードが難しい理由
- フレームワークやプラグインが新しいPHPに対応していない：古いバージョンのフレームワーク、ECパッケージ、プラグインは、新しいPHPでは動作しなくなります。旧mysql_*関数など、PHPから削除された関数を使うコードは書き換えが必要です。
- 開発当時の担当者がいない：コードを安全に変更できるほど内容を把握している担当者が、身近にいません。
- 最新の仕様書がない：最新の資料がないため、システムが本来どう動くべきかが分からず、アップグレード後のテスト範囲を決められません。
アップグレードか再構築か：判断の目安
どちらの方法でも、サポートが終了したPHPへの依存は解消できます。どちらが適しているかは、コードの状態と今後の事業計画によって変わります。
| アップグレードが向いているケース | 再構築が向いているケース |
|---|---|
| フレームワークに、新しいPHPに対応したサポート版がある | フレームワークやECパッケージに、アップグレードの道筋がない |
| コードが現在も保守されており、内容をある程度把握できている | 仕様書がない、または内容が古い |
| システムの機能が、現在の業務に合っている | 構築当時から業務プロセスが変わっている |
| テスト、またはテスト手順がある | 次のサポート終了時に、同じ問題が繰り返される |
TPSのご支援内容
1. 現状確認
PHPのバージョン、実行方式、フレームワークとプラグイン、10月21日の修正が有効かを確認します。アップグレードの阻害要因と、推奨する次のステップをまとめた簡潔なレポートをお渡しします。
2. バージョンアップ
8.2のサポート終了日を踏まえ、8.3以降のサポート対象ブランチへ移行します。互換性のないコードを修正し、回帰テスト（既存機能に影響がないかの確認）を行います。
3. 復元した仕様にもとづく再構築
アップグレードが現実的でない場合は、現在の動作をソースコードから復元し、各要件とコードを対応づけた要件ナレッジベースにまとめます。業務部門の皆様にご確認いただいたうえで、それをもとにシステムを再構築します。
国内のプラットフォームでは、3つの本番システムから38の業務フローを復元し、657の作業ステップをソースコードと対応づけた実績があります（事例・英語）。
現状確認の対象は、バージョン、設定、アップグレードの実現可能性です。ペネトレーションテスト（侵入テスト）は含まれないため、専門のセキュリティ事業者へのご依頼をおすすめします。現在の開発ベンダー様と並行して進めることも可能です。
どの方法がシステムに合うか、迷われていませんか？
PHPのバージョンとシステムの種類を、分かる範囲でお知らせください。現状確認の進め方について、TPSよりメールでご連絡します。コードや設定ファイルをご共有いただく前に、NDA（秘密保持契約）を締結することも可能です。
TPSは、ISO/IEC 27001:2022に沿った情報セキュリティマネジメントシステム（ISMS）を運用しています（詳しくはこちら・英語）。
よくあるご質問
1. 10月21日の修正を適用すれば十分ですか？
8.2〜8.5のシステムでは、修正を適用し、そのバージョンが実際にWebリクエストを処理していることを確認すれば、今回の2件の脆弱性への対応となります。ただし8.2のシステムは、2026年12月31日までにアップグレードが必要です。
2. PHP 7.4、8.0、8.1のシステムはどうすればよいですか？
これらのブランチには限定的なソースバックポートが公開されており、一部のディストリビューションやサポート事業者は修正済みのビルドを提供しています。ただし通常の修正はすでに提供されていないため、サポート対象バージョンへの移行は引き続き必要です。
3. 現状確認に、サーバーへのアクセスは必要ですか？
必ずしも必要ではありません。バージョン情報の出力結果、設定ファイル、ソースコードの写しなど、お客様からご提供いただく情報から始めることができます。アクセスが必要な場合は、範囲と方法を事前に取り決めます。
4. 現在の開発ベンダーと並行して依頼できますか？
はい。運用は現在のベンダー様のご担当のまま、アップグレードやテストなど作業の一部をTPSが担うことができます。
