「動いているから」とPHPのバージョンを何年も上げていないサイトは、攻撃者にとって格好の標的です。本記事は 自社サイトやWordPressをサポート切れ(EOL)PHPで動かしている運営者・制作会社 向けに、何が危険なのかと、サイトを止めずに安全にバージョンを上げる手順 を、コピペで使えるコマンド付きで解説します。所要時間は確認だけなら5分です。
まず自分のPHPバージョンを確認する
何はともあれ、いま動いているPHPのバージョンを知るのが第一歩です。サーバにSSHで入れるなら次のコマンドで確認できます。
# CLI版のバージョン(Webと別物のことがある点に注意)
php -v
# 実際にWebで動いているPHPを確認(Web版とCLI版は別設定なことが多い)
php-fpm -v 2>/dev/null || php-cgi -v 2>/dev/null
# 設定ファイルの場所も確認しておく
php --ini
SSHに入れない場合は、ドキュメントルートに一時的な確認用ファイルを置きます(確認後は必ず削除してください。放置するとサーバ情報が外部に漏れます)。
<?php
// phpcheck.php — 確認したらすぐ削除すること
echo 'PHP version: ' . PHP_VERSION;
WordPressなら、管理画面の [ツール] → [サイトヘルス] → [情報] → [サーバー] に「PHPのバージョン」が表示されます。プラグインを入れずに確認できる最短ルートです。
外部から大まかに推測するだけなら、レスポンスヘッダの X-Powered-By でも分かることがあります(出力していない設定も多い)。
curl -sI https://example.com | grep -i x-powered-by
EOLスケジュール:あなたのPHPは「もう直らない」かもしれない
PHPは リリースから2年が通常サポート(バグ+セキュリティ修正)、その後2年がセキュリティ修正のみ、合計約4年でEOL(End of Life) という公式ポリシーです。EOLを過ぎると、新たに脆弱性が見つかっても公式の修正パッチは一切出ません。
2026年6月時点の状況を整理すると次のとおりです(出典: PHP: Supported Versions)。
| バージョン | 初回リリース | 通常サポート終了 | セキュリティ修正終了(EOL) | 2026年6月時点 |
|---|---|---|---|---|
| 7.4 | 2019-11 | 終了済 | 2022-11-28(EOL) | 危険 |
| 8.0 | 2020-11 | 終了済 | 2023-11-26(EOL) | 危険 |
| 8.1 | 2021-11 | 終了済 | 2025-12-31(EOL) | 危険 |
| 8.2 | 2022-12 | 2024-12-31 | 2026-12-31 | セキュリティ修正のみ(年内終了) |
| 8.3 | 2023-11 | 2025-12-31 | 2027-12-31 | サポート中 |
| 8.4 | 2024-11 | 2026-12-31 | 2028-12-31 | サポート中(推奨) |
| 8.5 | 2025-11 | 2027-12-31 | 2029-12-31 | 最新 |
ポイントは2つです。
- 7.4 / 8.0 / 8.1 はすでにEOL。 これらで本番サイトを動かしているなら、いま最優先で計画を立てるべき状態です。
- 8.2 も2026年12月31日でEOL。 「8系だから大丈夫」ではありません。半年後に同じ問題が来るので、上げるなら 8.3以上(できれば8.4) をゴールにします。
サポート切れPHPで動かす「実害」
EOLのPHPを使い続ける危険は、抽象的な「なんとなく不安」ではなく、具体的なものです。
- 脆弱性が修正されない。 PHP本体やバンドルされた拡張に深刻な脆弱性が出ても、公式パッチが出ません。攻撃者は「EOLバージョンを狙えば確実に穴が残っている」と分かって探しています。
- プラグイン・ライブラリが切り捨てる。 WordPressのコアやプラグイン、Composer製ライブラリは新しいPHPを前提に進化します。古いPHPのままでは、セキュリティ更新を含む最新版に上げられず、「PHPが古い→プラグインも上げられない→二重に穴が残る」 という悪循環に陥ります。
- コンプライアンス・取引上の不利。 PCI DSS(クレジットカード取扱い)などのセキュリティ基準では「サポートされたソフトウェアの利用」が求められます。EOLのPHPは監査やセキュリティチェックシートで指摘対象になり、取引先審査で不利になります。
- 障害時に逃げ場がない。 いざ問題が起きても、サポート切れでは公式に頼れず、原因切り分けも情報が乏しくなります。
要するに、「同じ被害を防ぐ」最も確実な手段が、サポート内バージョンへ上げておくこと です。
安全に上げる手順:いきなり本番を切り替えない
PHPのバージョンアップで怖いのは「上げたら画面が真っ白(Fatal error)になった」というダウンです。これは 事前の互換チェックとステージング検証 でほぼ防げます。本番をいきなり触らないのが鉄則です。
Step 1. 構文チェックで明らかな非互換を洗い出す
まず php -l(lint)で構文エラーを見つけます。ただし php -l は 構文エラーしか検出しません(後述の「非推奨」は見つけられない)。一次フィルタと割り切ります。
# プロジェクト配下の全PHPファイルを構文チェック
find . -type f -name '*.php' -print0 \
| xargs -0 -n1 -P4 php -l 2>&1 \
| grep -v '^No syntax errors'
何も出力されなければ構文上の問題はありません。
Step 2. PHPCompatibility で「上げ先バージョン」との互換を静的解析
構文だけでなく 「PHP 8.3で削除/非推奨になった書き方」 まで洗い出すには、PHP_CodeSniffer の PHPCompatibility ルールセットを使います。実際にコードを実行せず、静的に問題箇所を一覧化できます。
# プロジェクトに開発用として導入
composer require --dev phpcompatibility/php-compatibility
composer require --dev dealerdirect/phpcodesniffer-composer-installer
# 上げ先(例:8.3)との互換性をチェック
vendor/bin/phpcs -p . \
--standard=PHPCompatibility \
--runtime-set testVersion 8.3 \
--extensions=php \
--ignore=*/vendor/*,*/node_modules/*
ERROR で出た箇所が、上げると壊れる可能性が高い部分です。古い関数(each() など)、削除された設定、引数の仕様変更などがここで見つかります。
Step 3. 非推奨(Deprecation)警告をログに記録する
静的解析をすり抜ける問題は、実際に動かしながら非推奨警告をログに集める のが確実です。ステージング環境で次のように設定し、サイトをひと通り操作・巡回してログを溜めます。
; php.ini(ステージング専用設定。本番では画面表示はOFFのまま)
error_reporting = E_ALL
log_errors = On
error_log = /var/log/php/deprecation.log
; 画面には絶対に出さない(情報漏えい防止)
display_errors = Off
# 溜まった非推奨警告を集計して、対応が必要な箇所を把握
grep -i 'Deprecated' /var/log/php/deprecation.log | sort | uniq -c | sort -rn
Step 4. ステージングで上げて検証する
本番と同じ構成のステージング環境 を用意し、そこでPHPを上げて動作確認します。最低限、次は必ず確認します。
- トップページ・主要導線・問い合わせフォーム送信
- ログイン/管理機能(WordPressなら管理画面とプラグイン全機能)
- バッチ・cron・決済など裏側の処理
WordPressの場合、管理画面から確認できる 「Site Health(サイトヘルス)」 に加え、ステージングでプラグイン互換を確認します。プラグイン・テーマは先に最新へ更新してからPHPを上げると、非互換が出にくくなります。
Step 5. バックアップ → 本番切替 → すぐ切り戻せる状態に
本番切替の前に、ファイルとデータベースのフルバックアップ を取ります。これが切り戻しの命綱です。
# DBバックアップ(WordPress / wp-cli の例)
wp db export "backup-$(date +%Y%m%d).sql"
# ファイル一式のバックアップ
tar czf "files-$(date +%Y%m%d).tar.gz" /var/www/example.com
本番のPHP切替は環境によって方法が異なります。共用レンタルサーバなら管理パネルでバージョンを選ぶだけ、自前サーバ(Ubuntu + nginx + PHP-FPM)なら次のように使うFPMソケットを切り替えます。
# 例:nginx が参照する PHP-FPM を 8.1 から 8.3 へ
sudo apt install php8.3-fpm php8.3-mysql php8.3-mbstring php8.3-xml
# nginx の fastcgi_pass を php8.3-fpm.sock に向けて
sudo nginx -t && sudo systemctl reload nginx
sudo systemctl enable --now php8.3-fpm
切替直後は アクセスログとエラーログを張り付いて監視 し、500 エラーや新しい Fatal error が出ていないか確認します。問題が出たら迷わず元のバージョンに戻し(設定を戻すだけ)、Step 2〜4に戻ってつぶし込みます。「切り戻せる状態を常に保つ」 ことが、止めない上げ方の本質です。
まとめ
- まず 自サイトのPHPバージョンを確認。7.4/8.0/8.1なら脆弱性が出ても直らないEOL状態、8.2も2026年末で終了。
- 上げ先は 8.3以上(推奨は8.4) をゴールに。「8系だから」で8.2に留めない。
- 安全な手順は php -l → PHPCompatibility → 非推奨ログ → ステージング検証 → バックアップして本番切替 → 切り戻せる状態を維持。本番をいきなり触らない。
「動いているから」は、脆弱性が見つかるまでの猶予でしかありません。サポート内に上げておくことが、最も確実な再発防止策です。
関連記事
本記事のようなサーバ・Web設定の弱点は、サイトドック(無料・登録不要)で外側から自動チェックできます → https://sitedock.jp