本記事は、当社が2026年10月に社内のWebサーバーを棚卸しし、PHPの稼働環境と既知の脆弱性を調査した記録をもとにしています。記事中のサイト名・環境名はすべて伏せるか架空のものに置き換えています。攻撃の手口は、防御のために一般に知られている範囲で紹介します。
PHP製サイトが狙われ続ける理由
会社案内のサイト、問い合わせフォーム、WordPress で作ったブログ、受注管理の画面——世の中のWebサイトの多くは PHP で動いています。サーバー側の言語としてもっとも広く使われているぶん、攻撃のツールも PHP 向けがもっとも充実しています。攻撃者は相手を選びません。インターネット上のサーバーを機械的に巡回し、「古いPHPか」「よく知られた脆弱性のあるプラグインが入っているか」「設定ファイルが置き忘れられていないか」を試して回ります。
厄介なのは、PHP製サイトは作った時点では安全でも、時間とともに危なくなることです。PHP 本体にはサポート期限があり、期限を過ぎると新しく見つかった脆弱性が修正されなくなります。2026年10月の時点で、PHP 7.4・8.0・8.1 はすでにサポート終了、PHP 8.2 も2026年12月31日で終了します。WordPress のプラグインや、メール送信・PDF 生成に使うライブラリも同様に、更新を止めた瞬間から古くなっていきます。
IPA（情報処理推進機構）の「情報セキュリティ10大脅威 2026」でも、組織向けの脅威として「システムの脆弱性を悪用した攻撃」が4位に挙がっています。本記事では、PHP製サイトのどこに穴ができるのか、何をすれば塞げるのか、そして当社がどう対応するのかを順に説明します。
穴は4か所にある
「PHPの脆弱性」と一口に言っても、穴が空く場所は1つではありません。当社では、PHP製サイトの穴を次の4か所に分けて考えています。対策が違うので、分けて見ることが大切です。
| 穴の場所 | 具体例 | 何が起きるか |
|---|---|---|
| 1. PHP本体 | サポート終了（EOL）の PHP 7.4・8.0・8.1。古い Apache・nginx | 公開済みの脆弱性がそのまま残り、既知の手口で侵入される |
| 2. CMS・プラグイン・ライブラリ | WordPress 本体と更新が止まったプラグイン、古いメール送信・PDF生成ライブラリ、古い jQuery | プラグインの脆弱性からファイルの書き換え、Webシェルの設置へ進む |
| 3. 自作部分の実装 | SQL文への文字列連結、エスケープ漏れ、ファイル名の直接指定、アップロードの検査漏れ、権限確認の漏れ | SQLインジェクション・XSS・パストラバーサルで、データの読み出しや画面の改ざん |
| 4. 設定と置き忘れ | エラー表示が有効、PHPのバージョンをヘッダーで公開、公開領域に残った phpinfo・テスト用ファイル・バックアップ・SQLダンプ | 内部構造やパスワードが読まれ、次の攻撃の足がかりになる |
3の「実装」は、作った会社の技量に左右される部分です。一方、1・2・4はきちんと作られたサイトでも、運用の中で自然に発生します。PHP のサポートは切れ、プラグインは更新を止め、作業の途中で置いたファイルは忘れられます。そして攻撃ツールが最初に試すのは、まさにこの1・2・4です。代表的な攻撃手法とログに残る痕跡は、別の記事で10種類を整理しています。
必要な対策は5つ
4か所の穴に対して、当社が必要だと考える対策は次の5つです。どれか1つで済む話ではなく、上から順に積み上げるものです。
対策1. 棚卸し——どこで、どのPHPが動いているかを知る
意外に思われるかもしれませんが、最初の壁はここです。「このサイトの PHP は何系ですか」と聞かれて即答できる会社は多くありません。制作会社に任せたまま、サーバーを借り換えたまま、担当者が代わったまま、という状態がふつうです。公開中のドメインごとに、どのサーバーで・どのPHPバージョンで・どのCMSとプラグインが・どのライブラリとともに動いているかを一覧にします。使っていないのに残っているサイトや、ドメインが消えたのに残っている転送設定も、このとき見つかります。
対策2. 更新——PHP本体・CMS・ライブラリをサポート内に保つ
サポート終了の PHP は、サポート中のバージョン（2026年10月時点では 8.3 以降が望ましい）へ更新します。WordPress は本体とプラグインを最新にし、使っていないプラグインは「無効化」ではなく削除します。無効化してもファイルは Web から到達できる場所に残るためです。メール送信や PDF 生成のライブラリも、同梱されたまま何年も更新されていないことが多いので、バージョンを確認して入れ替えます。
対策3. 設定の強化——攻撃者に情報を渡さない
公式の PHP には、本番向けの設定の雛形（php.ini-production）が同梱されていますが、Docker の公式イメージなどでは設定ファイルを置かない限り開発向けの既定値で動きます。本番で最低限そろえたい設定は次のとおりです。
- エラー表示を止める——
display_errors=Off。エラー画面には、ファイルの場所や SQL 文などの内部情報が含まれます - バージョンを隠す——
expose_php=Off。応答ヘッダーのX-Powered-Byで PHP のバージョンを名乗らないようにします - 外部ファイルの読み込みを禁止——
allow_url_include=Off。外部 URL のプログラムを読み込ませる攻撃を根元で防ぎます - Cookie を守る——
session.cookie_httponly=1・session.cookie_secure=1。XSS や盗聴でログイン状態を盗まれにくくします - 公開領域を掃除する——phpinfo の呼び出し、テスト用ファイル、
.git・.env・バックアップ・SQL ダンプを公開領域から取り除きます。アップロード先では PHP を実行させません
対策4. 実装の点検——自作部分の典型的な穴を塞ぐ
自作の PHP には、SQL 文をプレースホルダで組み立てているか、画面に出す値をエスケープしているか、ファイル名やIDを利用者から直接受け取っていないか、アップロードされたファイルの種類を検査しているか、表示のたびに「その人が見てよいデータか」を確認しているか、という定番の確認項目があります。IPA の「安全なウェブサイトの作り方」に沿って点検し、見つかった箇所を直します。
対策5. 監視——すり抜けた攻撃に気づく
対策1〜4は「防ぐ」ための対策です。ただし、更新の合間に新しい脆弱性が公開されることもあれば、点検で見落とした箇所が残ることもあります。防御には必ずどこかに穴が残る前提で、ログを見て攻撃の試行と成功の兆候を見分け、被害が広がる前に気づく仕組みを最後に置きます。
| 対策 | 主に塞ぐ穴 | 一度やれば終わりか |
|---|---|---|
| 1. 棚卸し | すべての前提 | サイトの追加・廃止のたびに更新 |
| 2. 更新 | 1. PHP本体 / 2. CMS・ライブラリ | サポート期限ごとに繰り返す |
| 3. 設定の強化 | 4. 設定と置き忘れ | 一度整えれば、環境の作り直し時に再確認 |
| 4. 実装の点検 | 3. 自作部分の実装 | 機能追加のたびに対象を点検 |
| 5. 監視 | すり抜けたすべて | 継続 |
当社の社内棚卸しでわかったこと
対策を人に勧める前に、まず自分たちの足元を見ました。当社は顧客向けの検証環境や社内ツールを多数のコンテナで運用しています。2026年10月、それらを対象に読み取りだけの棚卸しを行いました。各コンテナの中で PHP の設定値を読み、同梱ライブラリと WordPress プラグインのバージョンを集め、公開領域に危険なファイルが無いかを探す、という手順です。設定の変更や攻撃を模したアクセスは一切していません。
結果は、率直に言って反省の多いものでした。
- PHP が動く8環境のうち5環境がサポート終了のバージョン——7.4 が3環境、8.0 と 8.1 が1環境ずつ。そのうち1環境は、顧客確認用の検証サイトとしてインターネットに公開されたままでした
- 設定はほぼ開発向けの既定値——1環境を除いてエラー表示が有効、PHP のバージョンを応答ヘッダーで公開。本番向けの設定ファイルを置く運用が標準化されていませんでした
- 公開領域の置き忘れ——phpinfo だけを呼ぶファイル、テスト用のスクリプト、移行時の SQL ダンプ、zip ファイルが、ドキュメントルートに残っていました
- 「無効化」したつもりのプラグイン——WordPress の検証環境で、名前を変えて無効化したプラグインの複製が17個、Web から到達できる場所に残っていました。移行ツールのバックアップ用ディレクトリやデバッグログも同様です
- 古いライブラリの同梱——サポートの切れた 5 系のメール送信ライブラリ、古い PDF 生成ライブラリ、jQuery 1.8 系
- 消し忘れの転送設定——ドメインを廃止したのにリバースプロキシの転送ルールが10件残っており、誤って DNS を再登録すると、意図しない社内ツールが外部に公開される状態でした
どれも「動いているから大丈夫」と思っていた環境です。検証環境の大半は社内ネットワークからしか届かないため、直ちに被害が出る状態ではありませんでした。しかし、検証環境と本番が同じコードで動いているなら、本番にも同じ穴がある可能性が高く、各保守案件で本番側の確認に進めています。この棚卸しの手順と確認項目を、そのままお客様向けの診断に使っています。
当社が受け付ける対応の進め方
当社では、PHP製Webサイトの脆弱性対策を、診断から継続監視までの一連の作業として受け付けています。自社で制作したサイトに限らず、他社が制作したサイト、WordPress のサイト、担当者が代わって中身がわからなくなったサイトも対象です。進め方は次の4段階です。
段階1. 現状診断（読み取りのみ・サイトは止めない）
社内の棚卸しと同じ手順で、PHP とミドルウェアのバージョン、設定値、CMS・プラグイン・ライブラリのバージョン、公開領域の危険なファイルの有無を確認します。設定の変更や、攻撃を模した大量アクセスは行いません。結果は高・中・低の3段階に分けた指摘事項と対応案として報告します。「公開中かどうか」と「サポート終了かどうか」の組み合わせで優先度を決めるので、何から手を付けるべきかが明確になります。
段階2. 優先順位と暫定策
もっとも急ぐのは「インターネットに公開中で、サポート終了の PHP」です。更新には検証の時間がかかるため、まずアクセス制限（IP 制限や BASIC 認証）で攻撃面を減らす暫定策を先に入れ、そのうえで更新の計画を立てます。消し忘れのファイルや転送設定の削除も、この段階で済ませます。
段階3. 更新・設定強化・実装修正
PHP 本体の更新は、本番と同じ構成の検証環境で先に行い、エラーの洗い出し・修正・動作確認を済ませてから本番を切り替えます。PHP 7 系から 8 系への更新では、廃止された関数や型の扱いの変更で修正が必要な箇所が出るのがふつうです。当社が Docker で環境を組む場合は、本番向けの設定ファイルを最初から含めた構成に作り直します。あわせて、CMS とプラグインの更新、不要プラグインの削除、ライブラリの入れ替え、自作部分の点検と修正を行います。
段階4. 継続——監視と定期的な再診断
更新が終わったあとも、サポート期限は次々にやってきます。当社の情報漏洩未然検知サービス「Previento（プレビエント）」で Web サーバーのログを24時間監視し、SQLインジェクションなどの攻撃の試行と成功の兆候、Webシェルの設置、設定ファイルの探索を検知します。あわせて、PHP とライブラリのサポート期限を一覧で管理し、期限の前に再診断と更新を提案します。
どの対策を組み合わせても、攻撃をゼロにはできません。当社が約束できるのは、既知の手口で簡単に入られる状態をなくすことと、すり抜けた攻撃に早く気づける状態にすることの2つです。また、古い PHP の更新はサイトの作りによって修正量が大きく変わるため、段階1の診断結果を見てから作業量と期間をお見積りします。
よくある質問（FAQ）
- Q. PHPのバージョンが古いと、なぜ危険なのですか？
- A. サポートが終了したPHPには、新しく見つかった脆弱性の修正が提供されません。脆弱性の情報は公開されるため、攻撃側は手口を知っているのに、守る側だけが直せない状態になります。PHP 7.4・8.0・8.1はすでにサポート終了、8.2も2026年12月31日で終了するため、8.3以降への更新が必要です。
- Q. 診断の際にWebサイトを止める必要はありますか？
- A. いいえ。当社の診断はPHPの設定値・ライブラリやプラグインのバージョン・公開領域のファイルを読み取るだけで、設定の変更や攻撃を模した大量アクセスは行いません。サイトを停止せず、通常の業務時間内に実施できます。WordPressや他社が制作したサイトも対象です。
- Q. PHPを更新するとサイトが動かなくなりませんか？
- A. PHP 7系から8系への更新では、廃止された関数や型の扱いの変更により、修正が必要な箇所が出ることがあります。当社は本番と同じ構成の検証環境で先に更新し、エラーの洗い出しと修正、動作確認を済ませてから本番を切り替えます。更新が終わるまでの間は、アクセス制限などの暫定策で攻撃面を減らします。
まとめ
PHP製Webサイトの穴は、PHP本体・CMSとライブラリ・自作部分の実装・設定と置き忘れの4か所にできます。当社が社内の8環境を棚卸ししたところ、5環境がサポート終了の PHP で動き、設定は開発向けの既定値のまま、公開領域には置き忘れのファイルが残っていました。きちんと作られたサイトでも、放置すれば穴は自然に増えます。
必要な対策は、棚卸し・更新・設定の強化・実装の点検・監視の5つです。最初の一歩は、どこで何が動いているかを知ることから始まります。更新には検証と修正の手間がかかりますが、公開中かつサポート終了という状態を放置するより、ずっと小さいコストです。
当社では、読み取りだけの診断から、暫定策、更新と設定強化、Previento による継続監視までを一連の作業として受け付けています。「自社サイトの PHP が何系か分からない」「制作会社と連絡が取れなくなった」という段階のご相談も歓迎です。