WordPress debug.log Exposure: Preventing Error and Credential Leaks
When debugging mode is enabled (WP_DEBUG_LOG = true), WordPress logs runtime PHP errors, database queries, and plugin warnings to /wp-content/debug.log.
Because this file resides in a public directory, anyone can download it, uncovering stack traces, database queries, and transmitted authorization tokens.
Vulnerability Risk & Threat Impact
Disclosure of secret keys, database credentials, and internal filesystem paths.
How Our Scanner Inspects for This Flaw
Site Check checks HTTP availability of /wp-content/debug.log to detect unauthenticated log access.
Auditing WordPress environments inspects default operational endpoints (/wp-json/, /xmlrpc.php, /wp-content/plugins/) to identify user enumeration vectors, debugging logs, and vulnerable plugin footprints without generating database query strain.
Remediation Guide (Step-by-Step Fix)
To resolve this vulnerability, apply the following configuration or code snippet to your web server:
# In wp-config.php, disable public debug logging for production:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);
- Disable WP_DEBUG_LOG in production environments.
- Remove existing debug.log files from the /wp-content/ directory.
- Block public HTTP requests to *.log files in Nginx or Apache.
Attack Anatomy & Real-World Business Impact
Publicly readable /wp-content/debug.log files contain PHP stack traces, database query logs, and sensitive session information generated during debugging.
Compliance Framework Impact: Violation of fundamental security controls specified in OWASP Top 10 (A05:2021 Security Misconfiguration), SOC 2 Type II trust criteria, and ISO 27001 Annex A.
Defense-in-Depth Engineering Matrix
| Defense Layer | Technical Action | Tool / Enforcement |
|---|---|---|
| Edge Perimeter & Ingress Gateway | Enforce granular path restrictions and deny rules for routes matching wordpress-debug-log-exposure | Nginx Ingress Directives |
| Application Runtime Hardening | Disable verbose runtime telemetry and enforce least privilege controls for wordpress-debug-log-exposure | Runtime Configuration Hardening |
| CI/CD DevSecOps Automation | Incorporate automated verification gates for wordpress-debug-log-exposure within continuous deployment pipelines | Site Check Security Scanner |
CLI Remediation Verification: Terminal Commands
After applying configuration changes or patching source code, verify that the exposure is neutralized using command-line diagnostic tools:
curl -I -s https://your-domain.com/wp-content/debug.log | grep "HTTP/"
# Expected: 404
DevSecOps Best Practices & CI/CD Hardening
Ensure WP_DEBUG_DISPLAY is disabled in wp-config.php and deny web access to all .log files in web server rules.
Frequently Asked Remediation Questions
WordPress installations represent high-frequency targets for automated credential stuffing and exploit bots. Disabling obsolete XML-RPC endpoints, restricting user enumeration via REST API, and enforcing automated plugin updates eliminates over 95% of typical attack vectors.
To permanently close the «WordPress debug.log Exposure: Preventing Error and Credential Leaks» threat vector, integrate verification gates into your CI/CD pipeline and maintain automated perimeter checks with Site Check.