WordPress debug.log 公开访问导致敏感信息泄露的验证、取证与修复

漏洞背景

WordPress 在启用调试日志后，默认可能将 PHP 错误写入 wp-content/debug.log。如果该文件位于 Web 根目录下且服务器未配置访问限制，未认证访问者即可直接下载日志。日志中常见数据库错误、绝对路径、插件版本、请求参数、邮箱地址、Nonce、第三方接口响应以及异常堆栈，可能为后续漏洞利用提供条件。

该问题通常属于配置缺陷与敏感信息暴露，可对应 CWE-200、CWE-532。本文仅讨论已授权环境中的验证、日志取证和修复，不涉及利用日志中的凭据继续访问其他系统。

适用场景与判定条件

• 目标使用 WordPress，且站点目录中存在 wp-content。
• WP_DEBUG_LOG 已启用，或应用代码主动向默认调试日志写入内容。
• Web 服务允许直接读取 /wp-content/debug.log。
• 日志中包含不应向匿名用户披露的信息。

仅发现 WordPress 并不能判定漏洞成立。至少需要同时确认“日志可匿名读取”和“日志存在敏感内容或可持续泄露运行信息”。

问题定位

先进行无副作用的 HEAD/GET 请求，记录状态码、响应头、文件大小和内容类型。不要通过构造异常请求批量制造日志，以免影响生产环境或污染取证数据。

target='
curl -k -sS -D headers.txt -o debug.log \
  --max-time 10 \
  "$target/wp-content/debug.log"

sed -n '1,20p' headers.txt
wc -c debug.log
file debug.log
sed -n '1,20p' debug.log

以下情况需要避免误报：

• 返回 200，但正文实际是统一的 404 页面或 WAF 拦截页。
• 发生 301/302 跳转，最终跳到登录页或首页。
• 文件为空，且无法证明存在持续暴露风险。
• 响应来自缓存、历史快照或反向代理默认页面，而不是当前站点文件。

可通过响应正文特征辅助确认。典型 WordPress 调试日志常包含时间戳、PHP Warning、PHP Fatal error、WordPress database error、插件目录路径或堆栈信息。

grep -Ein \
  'PHP (Warning|Notice|Fatal error)|WordPress database error|wp-content/(plugins|themes)|Stack trace' \
  debug.log | head -n 30

技术分析

常见风险配置位于 wp-config.php：

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

WP_DEBUG_DISPLAY=false 只能避免错误直接显示在页面中，并不会阻止日志写入 Web 可访问目录。启用 WP_DEBUG_LOG=true 时，默认路径通常是 wp-content/debug.log。

日志风险取决于应用及插件如何处理错误。以下内容一旦进入日志，应视为高敏感数据：

• 数据库连接错误、SQL 语句、表前缀和字段内容。
• 服务器绝对路径、部署目录、PHP 版本和调用栈。
• URL 查询参数、POST 参数、请求头或 Cookie。
• 密码重置链接、Nonce、会话标识、API Token。
• SMTP、对象存储、支付或第三方接口的错误响应。

Nonce 不等同于长期认证凭据，但在有效期内可能被用于特定敏感操作。报告中应按实际内容和有效性评级，不能仅凭出现“nonce”字样直接定为严重漏洞。

授权验证步骤

建议按以下顺序操作，确保过程可复核且尽量不改变目标状态。

• 记录测试时间、源 IP、目标域名和授权范围。
• 请求固定路径，保存原始响应头及响应体哈希。
• 确认是否无需 Cookie、Authorization 或其他认证材料。
• 检查文件是否为真实日志，而不是伪装的错误页。
• 仅提取证明风险所需的最少字段，报告中对敏感值脱敏。
• 修复后以相同请求复测，应返回 403 或 404。

url='

curl -k -sS \
  -H 'Accept: text/plain' \
  -D evidence-headers.txt \
  -o evidence-body.txt \
  "$url"

sha256sum evidence-headers.txt evidence-body.txt > evidence-sha256.txt
stat evidence-body.txt

# 只做本地分类，不向其他系统提交日志内容
grep -Ein \
  'password|passwd|secret|token|authorization|cookie|nonce|api[_-]?key|database error|stack trace' \
  evidence-body.txt | head -n 50

服务端排查

具备服务器权限时，应确认配置来源、文件权限、Web 访问记录和首次暴露时间。WordPress 常量可能不只定义在主配置文件中，也可能由环境变量、部署模板或托管平台注入。

cd /var/www/example

# 定位调试配置，避免输出配置文件中的实际密钥
grep -RIn --include='*.php' \
  -E "WP_DEBUG|WP_DEBUG_LOG|WP_DEBUG_DISPLAY" \
  wp-config.php wp-content 2>/dev/null

# 检查文件元数据和权限
namei -l wp-content/debug.log
stat wp-content/debug.log

# 查询 Apache/Nginx 访问记录，路径按实际环境调整
zgrep -h 'GET /wp-content/debug\.log' \
  /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null | tail -n 100

访问日志中应重点关注首次访问时间、来源 IP、响应状态码、响应字节数、User-Agent 和请求频率。若发现大量成功下载，应按潜在数据泄露事件处理，而不能只删除文件后关闭工单。

风险分级建议

修复建议

生产环境应关闭 WordPress 调试模式：

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

如果业务确实需要保留错误日志，应将日志写到 Web 根目录之外，并限制读取权限。例如：

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', '/var/log/wordpress/example-debug.log');

同时配置文件属主和权限，使 PHP 运行账户可以写入，但普通系统用户无法读取：

install -o www-data -g adm -m 0640 /dev/null \
  /var/log/wordpress/example-debug.log

Nginx 可增加兜底规则，禁止下载日志、备份和临时文件：

location ~* /(?:wp-content/)?(?:debug|error)\.log$ {
    deny all;
    return 404;
}

location ~* \.(?:log|bak|old|swp|sql)$ {
    deny all;
    return 404;
}

Apache 环境可在虚拟主机配置中限制访问。优先修改主配置，不要只依赖可能被禁用的 .htaccess：

<FilesMatch "(?i)^(debug|error)\.log$">
    Require all denied
</FilesMatch>

修改后应执行语法检查并平滑重载：

nginx -t && systemctl reload nginx
# 或
apachectl configtest && systemctl reload apache2

泄露后的处置

• 保全现有日志和访问记录，计算哈希后限制访问，不要直接覆盖原始证据。
• 检索日志内是否出现密码、Cookie、Authorization、Token、Nonce 或第三方密钥。
• 对确认暴露的密钥执行轮换，并使相关会话失效。
• 检查 CDN、对象存储和反向代理缓存，避免源站修复后缓存副本仍可下载。
• 确认备份文件、压缩包和历史部署目录中不存在相同日志。
• 在日志策略中增加脱敏、轮转、保留周期和最小权限要求。

复测标准

修复完成后，从未登录客户端重新访问原路径，预期返回 403 或 404，且响应体不包含原日志内容。随后触发一条受控、无敏感数据的测试告警，确认日志只写入 Web 根目录之外的位置，并检查 Web 服务重载后规则仍然有效。

总结

wp-content/debug.log 暴露并非 WordPress 核心代码本身的通用漏洞，而是调试配置、日志路径和 Web 访问控制共同造成的敏感信息泄露。漏洞验证应保留完整响应证据并排除统一错误页等误报；修复不能停留在删除文件，还应关闭生产调试、迁移日志目录、增加服务器拒绝规则，并根据访问记录评估是否需要执行凭据轮换和事件响应。

这类问题建议分成“可访问性确认、泄露范围取证、阻断与密钥轮换”三步处理。验证时不要只看 HTTP 200，部分站点会把 404 页面也返回 200；应同时检查响应体、Content-Type 和重定向链：

curl -sS -L -D /tmp/debug.headers \
  -o /tmp/debug.body \
  --max-filesize 1048576 \
  

sed -n '1,20p' /tmp/debug.headers
file /tmp/debug.body
head -n 20 /tmp/debug.body

如果响应体出现 PHP Warning、PHP Fatal error、插件路径或堆栈信息，基本可以确认文件真实暴露。取证时保留时间、URL、状态码、响应头和文件哈希即可，避免在生产机上反复完整下载可能很大的日志：

date -u +"%FT%TZ"
sha256sum /tmp/debug.body
stat /tmp/debug.body
grep -Ein \
  'DB_(NAME|USER|PASSWORD|HOST)|password|passwd|secret|token|authorization|cookie|session|api[_-]?key|BEGIN (RSA|OPENSSH|PRIVATE)' \
  /tmp/debug.body | head -n 100

还要从 Web 访问日志反查暴露窗口和访问来源。注意轮转日志、CDN/WAF 日志也应一起查，否则容易低估访问次数：

zgrep -hE '"(GET|HEAD) /wp-content/debug\.log([? ][^"]*)?' \
  /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null

find /var/www -type f -path '*/wp-content/debug.log' \
  -printf '%TY-%Tm-%Td %TH:%TM:%TS %s %p\n'

临时止血应先在 Web 层拒绝访问，再处理 WordPress 配置。Nginx 可使用精确匹配，避免仅按扩展名拦截时被路径变体绕过：

location = /wp-content/debug.log {
    deny all;
    access_log off;
    log_not_found off;
}

location ~* /(?:debug|error)\.log$ {
    deny all;
}

Apache 2.4 可放在站点配置或允许覆盖规则的 .htaccess 中：

<FilesMatch "^(debug|error)\.log$">
    Require all denied
</FilesMatch>

修改后先检查并平滑重载配置，再从外部网络复测，预期应为 403 或 404：

nginx -t && systemctl reload nginx
apachectl configtest && systemctl reload apache2

curl -I 

WordPress 生产环境建议关闭调试展示；如果短期必须记录错误，应将日志写到站点根目录之外，而不是继续留在可公开访问的 wp-content 下：

define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', '0');

需要临时排障时，可以显式指定站外路径，并确保 PHP-FPM 用户可写、Web 服务无法直接提供该目录：

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', '/var/log/wordpress/example-debug.log');

最后不要只删除日志。如果其中出现数据库口令、WordPress salts、SMTP 凭据、云服务密钥或插件 API Token，应按已泄露处理：逐项轮换、使现有会话失效，并检查对应服务的登录和调用记录。旧文件建议先按事件响应流程封存哈希副本，再从 Web 目录移除；同时排查备份文件、压缩包和历史副本，例如 debug.log.1、debug.log.gz、debug.log.bak，这些经常被漏掉。