The fix, in one snippet
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
rm wp-content/debug.logIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now sends GET /wp-content/debug.log and reads only the first few kilobytes of any 200 response using a Range header. A finding requires the body to look like a PHP error log: lines that begin with a bracketed timestamp followed by PHP Notice, PHP Warning, PHP Deprecated or PHP Fatal error and reference a file path, or WordPress's own WordPress database error lines. An HTML page returned with status 200 does not match. The report states that the log is readable and roughly how large the response was; the content is not stored beyond the match. This is the file WordPress writes when WP_DEBUG and WP_DEBUG_LOG are both true and no custom path is set, so a finding almost always means debugging was switched on in production, or left on after troubleshooting. Rated high. Related leaks of configuration and backup copies are covered under exposed-backup-files and exposed-env-file.
Why it matters
A debug log is a running commentary on your server written for developers and read by attackers. At minimum it contains absolute paths (/home/acme/public_html/wp-content/plugins/...), which reveal the hosting layout and the system username, and it names every plugin and theme that throws a notice, with line numbers that map to specific versions. Database errors print the failing query, exposing the table prefix and the schema. The dangerous part is what plugins log: developers drop error_log(print_r($response, true)) calls into payment, mail and API integrations and forget them, so the log can hold API keys, OAuth tokens, webhook secrets, customer email addresses and password-reset URLs. It is also a live channel: an attacker probing a plugin can send malformed input and read the resulting error, turning a blind test into a visible one. Because the log is appended to constantly, a single leaked secret is the least of it; the file keeps giving until it is closed. The broader pattern is described in the exposed files guide.
How to fix it
Turn debugging off in production. In wp-config.php, above the "That's all, stop editing" line:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);If you genuinely need a log on a live site, write it outside the document root; since WordPress 5.1 the constant accepts a path:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/var/log/wordpress/debug.log'); // not under the web root
define('WP_DEBUG_DISPLAY', false);Before deleting the existing file, skim it for anything that must be rotated (keys, tokens, reset links), then remove it and block the path so a future mistake is not public. nginx:
location ~* /wp-content/debug\.log { deny all; return 404; }Apache:
<Files "debug.log">
Require all denied
</Files>Check your access log for earlier readers, and treat the file as disclosed:
grep -c 'wp-content/debug.log' /var/log/nginx/access.logWhere this fits
Exposed wp-content/debug.log is check 2 of 10 that the website vulnerability scanner runs under wordpress plugins, themes and core, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits WordPress install or upgrade script reachable (critical), where the WordPress installer or database upgrader answers with its setup page instead of 'already installed'. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Exposed wp-content/debug.log closes one route in. Immediately below it: Plugin version with known vulnerabilities, where at least one installed plugin is at a version with published vulnerabilities; Theme version with known vulnerabilities, where the identified theme is at a version with published vulnerabilities; WordPress core version has known vulnerabilities, where the WordPress core version on this site falls inside the affected range of at least one published vulnerability.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Exposed wp-content/debug.log (high severity)
Scanner check id: wordpress-debug-logThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
