A diagnostic page or log file is public

SeverityMedium

ScopeWhole site

EffortSmall

Verified bySecurity scan (weekly, or Re-scan)

Rule keysec_exposed_debug

Short answer

Anyone can open a diagnostic page or log on your site: phpinfo() output, Apache's /server-status page or a PHP debug.log. Delete the phpinfo file, stop writing logs into the public web folder, and restrict server-status to your own IP address.

Why it matters

phpinfo() prints the exact PHP version, every loaded extension, the server's file paths and its environment variables, which on some hosts include database or API credentials. Apache's server-status lists the requests being served right now, with full URLs (password-reset and login links included) and client IP addresses. A WordPress debug.log collects warnings with file paths, plugin names, SQL fragments and sometimes e-mail addresses.

Automated scanners request these well-known names on every site they find, and the version details let an attacker pick an exploit that matches your server. There is no direct ranking effect, but a public log can be indexed and show up in search results with its contents.

How Glimana detects it

Glimana requests five fixed addresses on your HTTPS host: /phpinfo.php, /info.php, /server-status, /debug.log and /wp-content/debug.log, reading only the first 2 KB of each. A file counts only when the response is 200 or 206 and its content matches: a phpinfo title or "PHP Version x.y" line, the Apache Server Status page, or log lines in PHP's format ([07-Nov-2026 10:00:00 UTC] PHP Warning: …, served as non-HTML). A response identical to the one for a random non-existent address is treated as your error page and ignored. Any match is reported with medium severity, listing the addresses; nothing is stored beyond the match type.

How to fix it

Watch out

Deleting wp-content/debug.log is not enough while WP_DEBUG_LOG is on: WordPress recreates the file on the next warning. Turn logging off or point it to a path outside the web root. Also note that .htaccess rules have no effect on Nginx servers.

Find the finding in Glimana. Open Security; this check is in the Exposed files group, with the evidence from the last scan under its title. The same problem is listed under Issues › A diagnostic page or log file is public.
Apply the fix on your platform.

WordPressApache / LiteSpeedNginx

In wp-config.php, above the "That's all, stop editing" line, set define( 'WP_DEBUG', false ); and define( 'WP_DEBUG_LOG', false );. If you need the log, give it a private path instead: define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-debug.log' ); (WordPress 5.1+). Then delete wp-content/debug.log and any phpinfo.php or info.php left in the site root with your host's file manager or SFTP.

Restrict server-status in the server configuration:
<Location "/server-status"> SetHandler server-status Require ip 203.0.113.10 </Location>
(replace the IP with yours, or use Require local). To block a log file that must stay in place, add to .htaccess: <Files "debug.log"> Require all denied </Files>. Delete phpinfo files rather than hiding them.

Nginx ignores .htaccess. In the server block add location ~* /debug\.log$ { deny all; }, delete any phpinfo files, then run nginx -t && systemctl reload nginx. If Apache runs behind Nginx, restrict its server-status as in the Apache tab.
Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.

How the fix is verified

After the fix, press Re-scan on the Security page (or wait for the weekly Sunday 04:00 scan); the problem closes when the check passes.