PHPサイトのセキュリティ対策：PHP 8.2のサポート終了前に確認すべきこと

PHPはいまもWebの標準的な言語です。W3Techsの2026年10月時点のデータでは、サーバー側言語が判明しているWebサイトの69.2%がPHPを使っています。WordPress、多くの共用レンタルサーバー、そして古い自社開発の業務システムの多くがここに含まれます。言語そのものは活発に保守されており、各ブランチには2年間の通常サポートと、その後2年間のセキュリティ修正が提供されます。

つまり問うべきは「PHPが安全か」ではなく、「自社サイトがサポート中のバージョン、保守されているプラグイン、安全なコードで動いているか」です。同じW3Techsのデータでは、PHPサイトの26.8%がバージョン7、7.7%がバージョン5で動いており、いずれもセキュリティ修正は提供されていません。リスクの大半はここにあります。

PHPプロジェクトはサポート期間をphp.netで公開しています。サポートが終了したブランチについては、修正されない脆弱性にさらされる可能性があるため、できるだけ早くアップグレードするよう案内しています。2026年10月時点でサポートされているのは次の4つです。

いま最も重要なのは2026年12月31日です。サイトやサーバープランがPHP 8.2なら、8.3以降への検証と移行に残された時間は約2か月です。8.4や8.5へ一気に上げれば、次のアップグレードまでの期間を長く取れます。

PatchstackのState of WordPress Security in 2026レポートによると、2025年にWordPress関連で新たに見つかった脆弱性は11,334件で、2024年より42%増えました。このうち91%がプラグイン、9%がテーマにあり、WordPress本体はわずか6件でいずれも優先度の低いものでした。Patchstackは、そのうち4,124件（36%）を実際の脅威と判断しています。

同じレポートの2つの数字は、更新の運用を見直す理由になります。集中的に狙われた脆弱性では、最初の悪用までの加重中央値が5時間でした。また、46%の脆弱性は公開時点で開発者による修正がありませんでした。月1回の更新作業では前者に間に合わず、後者にはそもそも効果がありません。自社開発のPHPアプリケーションでComposerのパッケージを使う場合も同じで、依存しているコードはすべて自社が責任を負うコードです。

CVE-2024-4577は、PHPのバージョンと同じくらい、設定やロケールが重要になることを示した脆弱性です。PHP公式のアドバイザリによると、Windows上のPHP-CGIに引数インジェクションの欠陥があり、リモートから任意のコードを実行できます。原因はWindowsの「Best-Fit」文字変換で、対象はコードページ932・936・950、つまり日本、中国、香港、マカオ、シンガポール、台湾で使われるシステムロケールです。アドバイザリは、Windows版XAMPPの既定のインストールがそのままで脆弱だったと指摘しています。修正はPHP 8.3.8、8.2.20、8.1.29で提供されました。

Cisco Talosは2025年3月、遅くとも2025年1月から、この脆弱性を悪用した攻撃が主に日本の組織を対象に行われていたと報告しました。対象はテクノロジー、通信、エンターテインメント、教育、ECの各業界です。日本企業や、日本のチームが構築したサーバーを使うカナダ企業が確認すべきことはシンプルです。WindowsでPHPをCGIとして動かさないこと、XAMPPなどの開発用パッケージを本番で使わないこと、マイナーバージョンだけでなくパッチバージョンまで確認することです。

OWASP Top 10:2025では、1位がアクセス制御の不備（Broken Access Control）、続いてセキュリティ設定のミス、ソフトウェアサプライチェーンの不備、暗号化の失敗、インジェクションの順です。その多くは、PHPコードのいくつかの習慣に対応しています。PHPのコードベースをレビューするとき、ITLが最初に確認するのは次の項目です。

セキュリティ設定のミスはOWASP Top 10:2025の2位で、PHPサイトでは開発時の設定がそのまま残っていることが典型です。以下はコードを変えずに半日ほどで確認できる項目です。

PHPサイトを所有していても自社で保守していない場合、最大のリスクを見つけるのにコードを読む必要はありません。開発会社やサーバー会社に、次の質問を上から順に確認してください。順番は前述のデータに沿っています。侵害の入口になりやすいのはサポート切れのバージョンと外部の部品なので、コードレビューより先に確認します。

回答は日付とともに記録しておきます。点検は繰り返してこそ意味があり、記録した回答が次回の比較基準になります。

PHP 8.2や8.3で動き、プラグインも保守されているサイトなら、多くの場合ステージング環境で検証してからサーバー管理画面でバージョンを切り替えるだけです。作業は数日程度で、その大半はフォーム、決済、管理画面の動作確認です。

PHP 7や5で動くサイトでは、バージョンの切り替え自体が難しいことはまれです。本当のコストは、対応版のないプラグインやライブラリと、削除された関数に依存する独自コードです。主要な部品のうち複数が保守終了しているなら、修正のコストと、保守されている技術での作り直しを比べましょう。どちらを選ぶにしても、現在のPHPブランチのサポート終了日を、ドメインや証明書の更新日と同じカレンダーに入れておけば、次の期限に慌てずに済みます。