Your WordPress debug.log is public — here’s what it’s handing out
Debug logging is a development convenience that too often ships to production — writing a world-readable file that narrates your site’s internals to anyone who asks for it.
Vigil flagged this because /wp-content/debug.log returned a file whose contents match PHP’s error-log signature. That means WordPress is logging to a path inside the web root, and your server is happily serving that file to the public internet. Vigil never stores the log’s contents — but anyone with a browser can read them.
Why it matters
A debug log is a gift to an attacker doing reconnaissance. It leaks absolute server file paths (useful for local-file-inclusion and for guessing your hosting layout), the exact plugins and themes throwing errors (and therefore which known CVEs to try), fragments of failing SQL queries, and — depressingly often — API keys, tokens or database credentials that a plugin logged while erroring out. It is a map of your soft spots, kept up to date automatically.
A public debug.log doesn’t just reveal that something is broken — it reveals exactly how, and where the code lives.— golden rule: never leak internals
How to fix it
There are two things to do, and you should do both. First, stop logging in production (or move the log outside the web root). Second, make sure the file can never be served even if it reappears.
// wp-config.php — production: keep logging OFF and never display errors
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);
// If you genuinely need logging, write OUTSIDE the web root instead:
// define('WP_DEBUG_LOG', '/var/log/wordpress/debug.log');# Belt-and-braces: deny the file at the web server
# nginx
location ~* /wp-content/debug\.log$ { deny all; return 404; }
# Apache / .htaccess
<Files debug.log>
Require all denied
</Files>Then delete the existing file — it already contains whatever leaked, so rotating it out matters. Treat any credential you spot in it as compromised and rotate that too. Once done, re-run the probe: the log should return 404, not a 200 full of stack traces.
Our team can apply this fix on your site and verify it with Vigil. Already monitoring this site with Vigil? Open the failing check and hit “Request a fix” — we’ll get the exact problem and URL. Otherwise, get in touch.