PHP 7.4.33は、PHP 7シリーズの最終バージョンとして、現在でも多くのエンタープライズシステムやレガシーなWebアプリケーションで稼働し続けています。

しかし、2022年11月にコミュニティによる公式サポート（EOL：End of Life）が終了しており、セキュリティ面でのリスクは年々高まっているのが実情です。

本記事では、どうしてもPHP 7.4.33を使い続けなければならない現場に向けて、最新のセキュリティ脅威からシステムを守るための具体的な対策と、保守運用における重要なポイントを詳しく解説します。

目次 [ close ]
  1. PHP 7.4.33を使い続けることのリスクと現状
    1. 公式サポート終了による影響
  2. セキュリティを強化するための環境構築
    1. WAF（Web Application Firewall）の導入と最適化
    2. OSおよびミドルウェアのセキュリティアップデート
    3. サードパーティによる延長サポートサービスの検討
  3. PHP 7.4.33の内部設定による要塞化
    1. php.iniの推奨設定例
    2. オープンベースディレクトリの活用
  4. 保守運用における具体的なポイント
    1. エラーログの常時監視と分析
    2. 依存ライブラリのセキュリティチェック
  5. 将来的な移行を見据えた「塩漬け」からの脱却
    1. 移行に向けた準備：PHPStanやRectorの活用
    2. コンテナ化による分離
  6. まとめ

PHP 7.4.33を使い続けることのリスクと現状

公式サポートが終了したソフトウェアを利用し続ける最大の懸念は、新たに発見された脆弱性に対して修正パッチが提供されないことです。

2026年現在、攻撃者はEOLを迎えた古いバージョンを標的にした自動攻撃ツールを常に稼働させています。

PHP 7.4.33自体に致命的な欠陥が見つかった場合、自力でソースコードを修正するか、サードパーティの有償サポートを利用する以外の選択肢がありません。

また、最新のライブラリやフレームワークがPHP 7.4をサポート対象外としているケースが増えており、エコシステムからの孤立も進行しています。

このような状況下では、単なるプログラムの修正だけでなく、システム全体のアーキテクチャを見直す包括的なセキュリティ戦略が求められます。

公式サポート終了による影響

PHPの開発コミュニティからは、セキュリティアップデートを含むすべての更新が停止しています。

これにより、共通脆弱性識別子（CVE）として登録されるような深刻な脆弱性が放置されるリスクが生じます。

特にWebサーバーと直接連携するPHPは、外部からのリクエストを処理するため、攻撃の入り口になりやすいという特徴があります。

コンプライアンスの観点からも、サポート切れのソフトウェアを使用していることは、セキュリティ監査において大きな指摘事項となるでしょう。

セキュリティを強化するための環境構築

PHP 7.4.33を安全に運用するためには、PHPそのものの設定だけでなく、それを取り巻くインフラ環境の強化が不可欠です。

ネットワークレベルでの防御を固めることで、脆弱性が悪用される隙を与えない仕組みを構築しましょう。

WAF（Web Application Firewall）の導入と最適化

WAFの導入は、PHP 7.4を運用し続ける上で最も効果的な防御手段の一つです。

WAFは、SQLインジェクションやクロスサイトスクリプティング（XSS）といった既知の攻撃パターンを検知し、アプリケーションに到達する前に遮断します。

最新のWAFであれば、PHP 7.4固有の脆弱性を狙った攻撃に対する「仮想パッチ」機能を提供している場合があります。

クラウド型WAFを活用することで、常に最新のシグネチャに基づいた防御をリアルタイムで適用することが可能です。

OSおよびミドルウェアのセキュリティアップデート

PHP本体が更新できなくても、その基盤となるOSやWebサーバー（Apache, Nginx）は常に最新の状態に保つ必要があります。

多くの脆弱性は、複数の要素を組み合わせることで成立するため、周辺環境を最新に保つだけでも攻撃の成功率を下げることができます。

例えば、OpenSSLの脆弱性を修正することで、通信の機密性を維持し、中間者攻撃のリスクを低減できます。

また、AlmaLinuxやRHELなどの長期サポートが提供されているOSを採用し、OSベンダーが提供するバックポートパッチの恩恵を受けることも検討してください。

サードパーティによる延長サポートサービスの検討

独自にパッチを適用するのが困難な場合、商用の延長サポートサービスを利用する価値があります。

これらのサービスでは、コミュニティが提供を終了したPHP 7.4に対して、独自のセキュリティ修正パッチを提供しています。

これにより、アプリケーションのコードを大きく書き換えることなく、最新のセキュリティ基準を維持することが可能です。

コストは発生しますが、ゼロデイ攻撃に対するリスクヘッジとしては非常に強力な手段となります。

PHP 7.4.33の内部設定による要塞化

PHPの挙動を制御する php.ini の設定を見直すことで、攻撃の被害を最小限に抑える「要塞化」が可能です。

デフォルトの設定は利便性を優先していることが多いため、運用環境に合わせて不要な機能を制限することが重要です。

php.iniの推奨設定例

以下の表に、セキュリティ向上のために見直すべき主要な設定項目をまとめました。

設定項目推奨値理由
expose_phpOffPHPのバージョン情報を隠蔽するため
display_errorsOffエラー情報からパスなどの内部情報漏洩を防ぐため
allow_url_fopenOff外部ファイルの読み込みを禁止し、RFI攻撃を防ぐため
disable_functionsexec,system,shell_exec...OSコマンド実行系の関数を無効化するため

特に disable_functions は、万が一スクリプトの実行権限を乗っ取られた際の被害を限定的にするために非常に重要です。

以下は、実際に php.ini で設定する際の手順例です。

INI
; セキュリティ設定のカスタマイズ例
expose_php = Off
display_errors = Off
log_errors = On
error_log = /var/log/php_errors.log
allow_url_fopen = Off
allow_url_include = Off

; 危険な関数の無効化
disable_functions = "exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source"

オープンベースディレクトリの活用

PHPがアクセスできるディレクトリを制限することで、システム上の重要なファイル（/etc/passwd など）の読み取りを防ぐことができます。

open_basedir ディレクティブを使用し、アプリケーションが動作するために必要なディレクトリのみを許可します。

INI
; アプリケーションのドキュメントルートのみを許可
open_basedir = "/var/www/html:/tmp"

保守運用における具体的なポイント

PHP 7.4.33を運用し続けるフェーズでは、日々の監視とコードレベルでの保守が生命線となります。

新しい脆弱性が発表された際に、迅速に対応できる体制を整えておく必要があります。

エラーログの常時監視と分析

予期しないエラーや不自然なアクセス試行は、エラーログに記録されます。

log_errors を On に設定し、ログを外部の監視ツール（DatadogやCloudWatch Logsなど）に転送する仕組みを構築しましょう。

特定のパスに対する集中したエラーアクセスは、攻撃者が脆弱性を探している兆候である可能性があります。

依存ライブラリのセキュリティチェック

PHP本体だけでなく、Composerで管理しているライブラリ群にも脆弱性が潜んでいる可能性があります。

composer audit コマンド（Composer 2.4以降で利用可能）を定期的に実行し、既知の脆弱性が含まれるパッケージを特定しましょう。

Shell
# プロジェクト内の脆弱なパッケージをチェック
composer audit
実行結果
Found 2 security vulnerability advisories affecting 2 packages:
+-------------------+----------------------------------------------------------------------------------+
| Package           | symfony/http-foundation                                                          |
| CVE               | CVE-2022-24894                                                                   |
| Title             | Prevent sensitive headers leakage when following redirects                        |
| URL               | https://github.com/advisories/GHSA-798r-6rgg-m346                                |
+-------------------+----------------------------------------------------------------------------------+

もし脆弱性が見つかった場合、PHP 7.4をサポートしている最新のマイナーバージョンへアップデートするか、代替のライブラリを探す必要があります。

将来的な移行を見据えた「塩漬け」からの脱却

安全な運用を続ける努力は重要ですが、PHP 7.4.33の運用はあくまで「時間稼ぎ」であることを忘れてはいけません。

並行して、最新バージョン（PHP 8.x）への移行計画を立てることが、最終的なリスク回避につながります。

移行に向けた準備：PHPStanやRectorの活用

最新バージョンへの移行を容易にするために、現在のコードベースを静的解析ツールで分析します。

PHPStan を使用すると、PHP 7.4の時点でも、将来的に互換性の問題が発生しそうなコードを特定できます。

また、Rector を利用すれば、コードを自動的にPHP 8.xの文法に変換することが可能です。

Shell
# Rectorを使用してPHP 8.1向けの互換性チェックを実行
vendor/bin/rector process src --dry-run --set php81

このように、ツールを活用して「現在のコードの状態」を可視化しておくことが、スムーズな移行への第一歩となります。

コンテナ化による分離

レガシーシステムをVM上で直接動かすのではなく、Dockerなどのコンテナ技術を用いて分離することを推奨します。

コンテナ化することで、古いPHP環境をカプセル化し、ホストOSとの依存関係を切り離すことができます。

万が一コンテナ内が侵害されても、ホストOSや他のコンテナへの影響範囲を最小限に抑えることが容易になります。

まとめ

PHP 7.4.33を2026年現在も運用し続けることは、非常に高い技術的ハードルとセキュリティリスクを伴います。

公式サポートがない以上、WAFによる外部防御、php.iniによる内部の要塞化、そして徹底した監視体制の3段構えが必須です。

また、サードパーティの延長サポートサービスといった外部リソースの活用も、現実的な選択肢として検討すべきでしょう。

しかし、最も本質的なセキュリティ対策は、一刻も早くPHP 8.x以降の最新環境へ移行することに他なりません。

本記事で紹介した保守ポイントを押さえつつ、システムの健全な将来のために、段階的なアップデート計画を進めていくことを強く推奨します。