Web Plura

Problem

WordPress Debug Log Exposed

Investigate an exposed WordPress debug log by confirming public access, rotating leaked secrets, fixing configuration, and verifying the file is no longer reachable.

WordPress security guideRun SiteCheck

Problem, cause, fix, verify

Problem

A debug log may be readable from the public web, exposing paths, errors, emails, tokens, or other sensitive details.

Audience

Site owners and agencies responding to exposed debug output or public log findings.

First check

Treat exposed logs as an information disclosure issue, not only a cleanup task.

Verify

When production debugging is unavoidable, write logs to a protected path, hide display errors, limit the collection window, and remove the setting after the incident is understood.

Editorial trust

Published
Updated
Content type
Problems
Review editorial policy

On this page

Symptom

A debug log may be readable from the public web, exposing paths, errors, emails, tokens, or other sensitive details.

For: Site owners and agencies responding to exposed debug output or public log findings.

Diagnosis

What to check before changing the site

Quick Diagnosis

Treat exposed logs as an information disclosure issue, not only a cleanup task.

After Removal

If credentials or tokens appeared in the log, removing the file is not enough; rotate the exposed values.

Check Copies

Look for copied logs in backups, migration folders, support archives, staging directories, and old public paths. A fixed debug.log file can still leave older evidence exposed.

Production Debugging

When production debugging is unavoidable, write logs to a protected path, hide display errors, limit the collection window, and remove the setting after the incident is understood.

WordPress SecuritySeverity: HighLast reviewed: 2026-09-16

Diagnosis

Symptoms, causes, checks, and fixes

Symptoms

  • A scanner reports exposed debug.log.
  • Public URLs under wp-content reveal log output.
  • Logs contain paths, plugin names, emails, keys, or stack traces.

Most Common Causes

  • WP_DEBUG_LOG writes to a public path.
  • Server does not deny .log files.
  • Debugging stayed enabled after troubleshooting.
  • Backup or copied logs were left public.

How To Confirm The Cause

  • Request the suspected log URL without authentication.
  • Inspect server rules for log-file denial.
  • Review whether secrets or PII appear in exposed content.

Fixes

  • Disable public debug logging after troubleshooting.
  • Move logs outside the web root when possible.
  • Block public access to log files.
  • Rotate secrets that appeared in the log.

How To Verify The Fix

  • Confirm the log URL returns 403 or 404.
  • Run SiteCheck or equivalent public checks.
  • Verify new logs do not appear under public paths.

When To Contact Support

Escalate to hosting/security support if sensitive data was exposed or server rules cannot block log access.

References

Official references

WordPress debugging documentation