Vulnerabilities
WordPress debug.log vs Framework Debug on Production
July 2, 2026
WordPress debug.log vs framework debug on production is two leftover operator surfaces. WP_DEBUG plus WP_DEBUG_LOG writes PHP notices and often paths into wp-content/debug.log — a file that too often is fetchable as a static object. APP_DEBUG / Django DEBUG=True turns every 500 into a yellow page. phpinfo() is a cousin dump. Production belongs on generic client errors and logs that are not in the document root. RoastMyOpsec does not currently score /wp-content/debug.log. It may heuristic-scan common API error bodies. It does not set WP_DEBUG, does not download logfiles, and does not send exploit payloads.
The practical difference
debug.log is a file. Framework debug is a response. XML-RPC and wp-admin are other WordPress surfaces — see those guides. display_errors in php.ini is yet another switch. Turning off WP_DEBUG_DISPLAY while leaving the log in a public directory is a common stall.
robots.txt Disallow: /wp-content/debug.log advertises the name. Deny at the CDN instead.
How to choose production settings
WP_DEBUG false, WP_DEBUG_LOG false, WP_DEBUG_DISPLAY false on production. Logs: server syslog or a private path outside the web root. CDN: deny debug.log, debug.log.*, and error_log names. CI: fail if WP_DEBUG is true in the production wp-config. Staging: debug behind auth, not on the marketing host.
| Surface | Typical leak | Public origin | Takeaway |
|---|---|---|---|
| /wp-content/debug.log | Paths, plugin errors, sometimes queries | No | Not a scored roast path; deny anyway |
| WP_DEBUG true (on-page) | Notices in HTML | No | See framework debug |
| /phpinfo.php | Runtime dump | No | See phpinfo vs verbose errors |
| XML-RPC | Auth surface | Disable if unused | See XML-RPC vs wp-login |
When a debug log still wins (off the public origin)
Logging to a private file or SIEM still wins for operators. The miss is a world-readable object on 443. Pair with composer.json if the same deploy also published PHP inventory.
What the roast can prove
Heuristic error-body hits can surface. debug.log is not a scored path. A 404 is not proof WP_DEBUG_LOG is off. Confirm wp-config on the host you submitted. Pair with exposed .env if secrets leaked from a public file.
Common mistakes
The first mistake is WP_DEBUG_LOG true 'only for this hotfix' on the brand hostname.
The second mistake is moving the log to /wp-content/uploads because it was easier.
The third mistake is Disallow: /debug.log and calling it access control.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is a public debug.log a vulnerability?
- Yes — it is an information-leak class. Delete it, deny the name, and turn WP_DEBUG_LOG off.
- Does RoastMyOpsec fetch debug.log?
- Not as a scored path today. Deny /wp-content/debug.log at the edge anyway.
- Does Cloudflare hide the log?
- No. It proxies whatever your origin returns unless you add a deny rule.
Sources
Related guides
Vulnerabilities
Framework Debug Mode vs Verbose API ErrorsVulnerabilities
WordPress XML-RPC vs wp-login.php for Public Site OPSECVulnerabilities
wp-config.php.bak vs .env on Production Origins