PHP日志泄露漏洞本质是配置失当与权限失控，核心在于调试模式开启、日志目录可Web访问、日志含明文敏感信息；修复需关闭DEBUG、隔离runtime目录、清理并过滤日志内容。
立刻关闭调试模式
ThinkPHP、Laravel、自建日志系统等，只要 APP_DEBUG 或 debug = true 开着，就会把 SQL、POST 数据、数据库配置、错误堆栈全写进日志。生产环境必须关掉：
- ThinkPHP 5/6：检查 config/app.php 中
'debug' => false；同时确认 .env 文件里没有APP_DEBUG=true（会覆盖配置） - Laravel：确保
APP_DEBUG=false且APP_LOG_LEVEL=error，避免 info/debug 级别记录敏感字段 - 纯 PHP 项目：删掉或注释掉类似
define('DEBUG', true)、error_reporting(E_ALL)、ini_set('display_errors', '1')这类语句
让 runtime/log 目录彻底不可访问
日志路径（如 /runtime/log/202610/22.log）一旦能用浏览器直接打开，攻击者两分钟就能下载一周的日志。不能只靠 .htaccess 或临时屏蔽，要从架构上隔离：
-
最优方案：把
runtime目录移出 Web 根目录。例如 Web 服务器 root 指向/var/www/myapp/public/，就把runtime放在/var/www/myapp/runtime/（与 public 同级），完全不在 URL 映射范围内 -
次选方案（必须验证）：Nginx 加 location 规则：
location ^~/runtime/ { deny all; }
Apache 加<Directory "/path/to/runtime"> Require all denied </Directory> -
验证是否生效：浏览器访问
https://yoursite.com/runtime/log/202610/22.log，应返回 403（不是 404），否则说明规则没生效或路径写错
清理已有日志并限制内容记录
已生成的日志文件可能早已被爬取，必须清空；同时防止新日志再记敏感数据：
- 进入服务器，递归删除
runtime/log/下所有子目录和 .log 文件（不是只清空文件，要删掉整个日期目录） - ThinkPHP：在
config/app.php的 log 配置中设'sql' => false、'trace' => false，或启用自定义日志驱动过滤$_POST、$_SERVER['HTTP_AUTHORIZATION']等字段 - 通用建议：禁用
log_errors = On时的error_log输出到 Web 可读文件；改用 syslog 或远程日志服务
额外加固项（常被忽略）
很多团队修复后又被通报，往往栽在这几处：
立即学习“PHP免费学习笔记（深入）”；
- 检查入口文件（如
public/index.php）是否硬编码了define('APP_DEBUG', true)—— 删除它 - 给
runtime/目录设权限：chmod 750 runtime，确保只有 PHP 进程用户（如 www-data）可写，其他用户不可读 - 数据库配置文件（如
database.php或.env）绝不能放在 Web 根目录下；若必须共存，用 Web 服务器规则禁止访问.env、config/*.php
