WordPressのdebug=trueは危険｜エラー表示が情報漏洩に繋がる理由【Security Note】

vivisec
WordPressサイトで「debug=true」が危険な理由｜実際に起きる情報漏洩を解説【Security Note】

※本記事にはプロモーションが含まれています。

WordPressには、エラー内容を表示するためのデバッグ機能があります。

define('WP_DEBUG', true);

開発中には便利な設定ですが、本番環境で有効にしたままだと、サイトの内部情報をそのまま公開してしまう状態になります。

この記事では、debug=trueがなぜ危険なのかを、実際の攻撃の流れとあわせて解説します。

何が起きるのか｜エラー＝内部情報の公開

WP_DEBUG = true の状態でエラーが発生すると、以下のような情報がページに表示されます。

Warning: include(/home/user/public_html/wp-content/plugins/example/file.php): failed to open stream

この一行だけでも、次のような情報が分かります。

  • サーバーのディレクトリ構造
  • 使用しているプラグイン名
  • ファイルの位置

つまり、本来は外部に見せるべきではない内部情報がそのまま公開されている状態です。

攻撃の流れ｜debug=trueはどう使われるのか

攻撃者は、正常なページを見るためではなく、エラーを引き起こして情報を引き出すためにアクセスします。

例えば、次のような手順で情報収集が行われます。

  1. 存在しないURLにアクセスしてエラーを発生させる
  2. エラーメッセージからパスやプラグイン名を取得
  3. 使用している環境を特定
  4. 既知の脆弱性を検索
  5. 攻撃を試行

つまり、debug=trueは単なる設定ミスではなく、攻撃の入口になる状態です。

実際のリスク｜情報は次の攻撃につながる

例えば、エラーからテーマ名が分かった場合、

  • 古いテーマかどうかを調べる
  • 既知の脆弱性（XSS・LFIなど）を探す
  • テーマ特有の攻撃を試す

といった行動につながります。

また、ディレクトリ構造が分かれば、

  • ファイルの配置を推測
  • 狙うべきエンドポイントを特定

といったことも可能になります。

エラー表示はそれ単体で終わらず、攻撃の精度を上げるための材料として使われます。

小規模サイトでも関係あるのか？

結論から言うと、規模はほとんど関係ありません。

実際の攻撃の多くは、人間ではなくボットによって自動で行われています。

  • 個人ブログ
  • 開設直後のサイト
  • アクセスがほとんどないサイト

であっても、例外なく対象になります。

なぜ狙われるのか｜見つけたサイトを全部調べるだけ

攻撃者の挙動はシンプルです。

  • WordPressサイトを自動で検出
  • よくあるURL（/wp-login.php や /.env など）を機械的に叩く
  • エラーやレスポンスの違いをチェック

この過程でdebug=trueの状態だと、サイト側から内部情報を差し出してしまう形になります。

実際にdebug=trueと思われるサイトを見つけた話

営業リスト作成中に、WordPressのエラーがそのまま表示されているサイトを見たことがあります。

ページを開いた瞬間、PHPのエラーメッセージが画面に表示されていました。

表示されていた内容からは、

  • /wp-content/plugins/ 以下のファイルパス
  • 使用しているプラグイン名
  • サーバー上のディレクトリ構造

といった情報が読み取れる状態でした。

この時点で、開発用の設定がそのまま公開されている状態だなと分かります。

こうしたエラー表示は一見ただの不具合に見えますが、外部から見ると内部情報をそのまま公開している状態です。

実際にこのようなサイトは珍しいものではなく、設定の見落としで発生しているケースも少なくありません。

このような状態のサイトは、特別な例ではなく、探せば一定数見つかります。

※特定のサイトに影響が出ないよう、詳細なURLなどは記載していません。

実際に観測される挙動

私のサイトでも、公開直後からボットによるスキャンが確認されています。

  • 存在しないURLへのアクセス
  • 設定ファイル（/.env など）を探すリクエスト
  • WordPress特有のパスへのスキャン

こうしたアクセスは、エラーを引き出すことも目的の一つです。

▶ WordPressサイトに「/.env」スキャンが来た理由
▶ WordPress公開直後にBotが最初に確認するURL

WordPressでの具体例

例えば、存在しないファイルを読み込ませるリクエストが送られた場合、

Fatal error: require(): Failed opening required '/home/user/public_html/wp-content/themes/custom/template.php'

のようなエラーが表示されることがあります。

この時点で、

  • テーマ名（custom）
  • ディレクトリ構造
  • ファイル配置

が一気に特定されます。

よくあるミス｜「一時的にON」にしてそのまま放置

これはかなり現実的なミスです。

  • トラブル対応で一時的にON
  • 修正後にOFFにするのを忘れる
  • そのまま公開状態になる

特に、

  • サーバー移行直後
  • テーマやプラグイン調整中

はやりがちです。

安全な設定｜“表示しない・ログに残す”

本番環境では、以下の設定が基本です。

define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);

これにより、

  • エラーは画面に表示されない
  • debug.logにのみ記録される

という状態になります。

【運用メモ】debug.logの確認方法

WP_DEBUG_LOG = true の場合、ログは以下に出力されます。

/wp-content/debug.log

FTPやサーバーのファイルマネージャーから確認できます。

私の場合は、エックスサーバーのファイルマネージャーから直接確認しています。

ブラウザ上で操作できるため、FTPソフトを使わなくても手軽に確認できます。

▶ エックスサーバー公式はこちら

debug.logにも注意｜ログの公開リスク

見落としがちですが、ここも重要です。

/wp-content/debug.log

が外部からアクセス可能な状態だと、エラー情報がそのまま取得される可能性があります。

対策チェックリスト

  • WP_DEBUG が false になっている
  • WP_DEBUG_DISPLAY が false になっている
  • debug.log に直接アクセスできない
  • 本番環境でエラーが表示されない

まとめ

  • debug=true は開発用の設定
  • 本番環境では情報漏洩の原因になる
  • エラー表示は攻撃のヒントになる
  • 「非表示＋ログ保存」が基本

補足

debug=trueの問題は、単体で致命的な脆弱性になることは少ないです。

ただし、攻撃者にヒントを与える状態になる。これが本質です。

実際の攻撃は、こうした小さな情報の積み重ねから成立します。

このブログの運営環境

  • WordPress
  • GeneratePress
  • エックスサーバー

▶ エックスサーバー公式サイト