- 0120-972-655（お問い合わせ電話窓口）平日9:00∼17:30
「Webサイトを公開してから、PHPを更新した記憶がない」 「制作会社からPHPのバージョン変更を案内されたが、必要性が分からない」 という企業の担当者の方もいるのではないでしょうか。
PHPは、WordPressをはじめとするWebサイトや業務システムで利用されるプログラミング言語です。 PHP本体や関連するソフトウェアの脆弱性を放置すると、 情報漏えい、Webサイトの改ざん、不正アクセスなどにつながるおそれがあります。
ただし、PHPを更新するだけで、Webサイトに存在するすべての問題が解消するわけではありません。 PHP本体、CMS・プラグイン、独自に開発したプログラムを分けて確認することが大切です。
本記事では、PHPの脆弱性とは何か、放置した場合のリスク、 利用環境の確認方法、企業が取り組むべき対策を解説します。
脆弱性とは、ソフトウェアなどに存在する、攻撃に悪用され得る弱点のことです。 PHPを利用するWebサイトでは、 「PHP本体」「CMSなどの構成要素」「Webアプリの実装」 を分けて確認する必要があります。
| 確認する領域 | 主な確認対象 | 対策の例 |
|---|---|---|
| PHP本体・拡張機能 | 実行環境の不具合、利用する拡張機能の脆弱性 | 修正版への更新、サポート状況の確認 |
| CMS・フレームワーク・ライブラリ | WordPress、プラグイン、テーマ、外部ライブラリなど | 各製品の更新、不要な構成要素の削除 |
| Webアプリの実装 | 入力値の処理、認証・認可、ファイル操作など | プログラムの修正、設計の見直し、脆弱性診断 |
PHPの実行環境自体に問題が見つかり、修正版が公開されることがあります。 影響を受ける条件は、PHPのバージョンや実行方式、設定、利用する機能などによって異なります。
「PHPを使っているから危険」「特定のOSだから安全」と一括りにせず、 公式の注意喚起と自社の構成を照らし合わせて判断しましょう。
PHP公式のセキュリティ情報も確認しましょう
2026年10月21日、PHP公式は、認証なしで遠隔からコードを実行されるおそれがある 重大な脆弱性への注意喚起を公開しました。 修正版としてPHP 8.5.12、8.4.27、8.3.36、8.2.35が案内されています。
これは特定の更新時点の情報です。実際の対応では、 PHP公式サイト と、利用するOS・サーバー事業者の最新情報を確認してください。 OSベンダーが修正を取り込んだパッケージを提供する場合もあります。
情報確認日：2026年10月23日
PHP本体を更新していても、WordPress本体やプラグイン、テーマなどに 脆弱性が残っていれば、攻撃を受けるおそれがあります。
Webサイトを構成するソフトウェアを把握し、それぞれの更新状況を確認することが必要です。
独自開発したお問い合わせフォームや管理画面などでは、 入力値の扱い方やアクセス権限の確認に問題があると、脆弱性につながります。
これらはPHP以外の言語でも発生する問題です。 PHP本体の更新とは別に、Webアプリ側の修正が必要になります。
脆弱性を悪用された場合、被害はWebサイトの表示異常だけにとどまらないことがあります。
データベースや設定ファイルへ不正にアクセスされると、 顧客情報、問い合わせ内容、外部サービスの認証情報などが盗まれるおそれがあります。
例えばSQLインジェクションは、データベースへの問い合わせを不正に操作する攻撃です。 Webアプリの実装に問題がある場合、情報の取得や改ざんにつながる可能性があります。
企業サイトの内容を書き換えられたり、訪問者を不正なサイトへ誘導する処理を埋め込まれたりする場合があります。 顧客への影響に加え、企業の信用低下にもつながります。
脆弱性やファイルアップロード機能の不備などが悪用されると、 攻撃者に不正なプログラムを実行されるおそれがあります。
その結果、サーバー内の情報窃取、ファイルの変更、不正な処理の実行などに つながる可能性があります。
Webサイトや業務システムの停止により、問い合わせ受付、予約、受注などの業務が止まるおそれがあります。
さらに、侵害されたサーバーから社内の重要システムへ接続できる構成や、 権限の広い認証情報が保存されている場合には、被害が広がる可能性があります。
PHPの脆弱性が、必ずランサムウェア被害に直結するわけではありません。 ただし、不正侵入後の行動やネットワーク構成によっては、 ランサムウェアの実行を含む追加の攻撃につながるおそれがあります。
レンタルサーバーでは、管理画面から利用中のPHPバージョンを確認できる場合があります。 自社で把握できない場合は、制作会社やサーバー保守会社へ問い合わせましょう。
同じサーバーでも、サイトごとに異なるPHPが動作している場合があります。 また、コマンドラインで確認したバージョンと、 Webサイトが使用するバージョンが異なることもあるため注意が必要です。
PHPには、通常の不具合修正が提供される期間と、 重大なセキュリティ問題への修正が提供される期間があります。
PHP公式のサポートが終了したバージョンを利用している場合は、 対応中のバージョンへの移行を計画しましょう。 OSベンダーやサーバー事業者が独自に修正を提供する場合は、 その対象と期限を確認します。
最新のサポート状況は、 PHP公式のSupported Versions で確認できます。
PHPの設定情報を表示する確認用ページは、構成情報を第三者へ知らせる原因になります。 調査で作成する場合はアクセスを制限し、確認後に削除するなど適切に管理してください。
PHP本体だけでなく、OS、Webサーバー、拡張機能、CMS、プラグイン、 フレームワーク、ライブラリを含めて更新状況を確認します。
PHPのバージョン変更では、古いプログラムが動作しなくなる場合もあるため、 検証環境で動作確認を行い、バックアップや切り戻し手順を準備します。
一方で、重大な脆弱性への対応を通常の更新予定まで先送りすることも適切ではありません。 影響と悪用状況を確認し、緊急対応として更新や一時的な公開停止を判断できる体制を整えましょう。
データベースへ渡す値をSQL文へ直接連結せず、 プリペアドステートメントとパラメータのバインドを適切に利用します。
テーブル名や並び順など、値としてバインドできない部分は、 あらかじめ許可した候補から選択するなどの対策が必要です。
クロスサイトスクリプティング（XSS）対策では、 入力されたデータを表示する場所に応じたエスケープなどを行います。 HTML、JavaScript、URLでは必要な処理が異なるため、 一つの処理だけで対応できると考えないことが大切です。
ファイルアップロード機能では、許可する種類や容量を制限し、 拡張子だけでなく内容も検証します。 保存先は可能な限り公開ディレクトリの外へ分離し、 アップロードされたファイルがプログラムとして実行されないようにします。
管理画面には多要素認証やアクセス制限を導入し、 不要なアカウントを削除します。
Webアプリが使用するデータベースやファイルの権限も、 必要な範囲に限定します。 設定ファイルやバックアップファイルがWeb経由で公開されていないかも確認しましょう。
WAFは、Webアプリへの不正な通信を検知・遮断するための対策です。 既知の攻撃パターンへの防御や、修正までの一時的なリスク低減に役立つ場合があります。
ただし、WAFを導入しても、PHPやWebアプリの脆弱性そのものが修正されるわけではありません。 更新やプログラム修正と組み合わせて運用します。
また、公開前や大きな改修後などに脆弱性診断を行い、 見つかった問題の修正と再確認まで実施しましょう。
不審なアクセスや予期しないファイル変更を把握できるよう、 ログの収集・監視と、異常時の連絡体制を整えます。
バックアップは、侵害されたサーバーから自由に削除・変更できないよう保護し、 復元できるかを定期的に確認しましょう。
古い業務システムとの互換性や、開発会社との契約状況によって、 すぐにPHPを更新できない場合もあります。
その場合は、更新できない理由と影響範囲を明確にし、 改修や移行の担当者・期限を決めます。 並行して、脆弱性の内容に応じた一時的な対策を検討します。
一時的な対策は、修正版への更新やプログラム修正の代わりにはなりません。 公開サービス全体に影響する脆弱性では、管理画面だけを制限しても 十分な対策にならない場合があります。
また、サポート対象のPHPへ更新しても、既に侵入されている場合は 攻撃者が設置したファイルや奪われた認証情報が残る可能性があります。 侵害が疑われるときは、専門家による調査と復旧対応が必要です。
PHPの脆弱性対策では、Webサイト側の更新・修正とともに、 侵入された場合の被害範囲を抑える設計も重要です。
公開Webサーバーと社内の基幹システムを分離し、 業務上必要な通信だけを許可することや、 接続用アカウントの権限を限定することを検討しましょう。
顧客情報を扱うデータベースへWebアプリから接続する必要がある場合は、 その接続を前提に、アクセス権限や取得できる情報の範囲を見直す必要があります。
バルテックでは、重要システムへの不正アクセス対策として 「VALTEC SAMANTHA（サマンサ）」 をご案内しています。
重要システムへの接続方法を見直したい場合は、 保護したいシステム、必要な通信、現在のネットワーク構成を整理したうえで、 導入条件や既存の対策との役割分担をご相談ください。
なお、重要システムへのアクセス対策と、 公開WebサイトのPHP・CMSの更新や脆弱性修正は、 それぞれの対象に応じて実施する必要があります。
PHPを利用しているだけで、直ちに危険というわけではありません。 サポート状況、修正の適用状況、Webアプリの実装、 サーバー設定などを確認して判断する必要があります。
PHPの更新だけでは十分ではありません。 WordPress本体、プラグイン、テーマの更新に加え、 アカウントや設定の管理も必要です。
サービスによって管理の範囲が異なります。 サーバー側のPHP更新は事業者が担当していても、 PHPバージョンの選択やWordPress・プラグインの更新は 利用者側の作業となる場合があります。 契約内容と担当範囲を確認してください。
表示される番号だけでは判断できない場合があります。 OSベンダーなどが、従来のバージョンへセキュリティ修正を取り込む 「バックポート」を提供することがあるためです。 パッケージのリリース番号や提供元の脆弱性情報も確認しましょう。
不要にはなりません。 WAFで防げる攻撃には限界があり、 脆弱性そのものを修正するものでもありません。 更新・修正を基本とし、WAFは追加の防御策として利用します。
PHPを利用するWebサイトの安全性を保つには、 PHP本体だけでなく、CMS・プラグイン・独自プログラムまで含めた管理が必要です。
自社サイトの確認ポイント
まずは制作会社や保守会社と、 「現在のPHPバージョン」「修正の適用状況」「更新の担当範囲」を確認しましょう。 そのうえで、Webサイトへの侵入を防ぐ対策と、 重要システムへの被害拡大を抑える対策を進めることが大切です。
参考情報
「人と情報とをつなぐ物理ネットワークの制約やセキュリティの脅威から人々を開放する」 という理念に基づいた、セキュアリモートアクセスサービスである SWANStor（スワンストア）の開発と販売を行う。
重要システムの不正アクセス対策
自社の重要システムへの接続方法や、 現在のセキュリティ対策を見直したい方へ。 サービスの仕組みと導入条件をご確認いただけます。
無料で資料をダウンロードする →
