ThinkPHP漏洞修复后扫描分数仍低，根本原因在于修复不全面：仅修补代码而忽视配置、中间件顺序、依赖组件漏洞及运行时环境风险，导致扫描器探测到参数绕过、信息泄露、危险函数未禁用等隐性问题。
ThinkPHP漏洞修复后扫描分数仍低，往往不是“修没修”，而是“修得全不全、深不深、稳不稳”。很多团队只解决了表面报出的漏洞，却忽略了框架生态、配置层、依赖链和运行时环境带来的隐性风险。
修复只覆盖了代码，没动配置和中间件
比如RCE漏洞打了补丁，但public/index.php里加的参数拦截规则写错了路径，或漏掉了_method以外的危险键（如s、callback、filter）；又或者安全中间件被放在了路由之后，导致未登录用户也能触发高危逻辑。扫描器会直接探测这些绕过点，分数自然上不去。
- 检查所有入口文件（尤其是
index.php和router.php）是否统一拦截了['s','_method','function','vars','callback','filter']等高危参数 - 确认中间件注册顺序：安全类中间件（如输入过滤、路由白名单）必须在
AppMiddleware最前，不能被其他中间件跳过 - 验证
app_debug = false且show_error_msg = false已生效——调试信息泄露会被扫描器直接扣分
依赖组件本身带漏洞，和框架代码无关
ThinkPHP升级到6.0.13+，但项目里还用着guzzlehttp/guzzle:6.5.0（含CVE-2021-29455）、monolog/monolog:1.25.0（反序列化风险）或phpunit/phpunit:9.3.0（CVE-2020-13952）。这些组件哪怕一行ThinkPHP代码都没改，也会被扫描器识别为“已知漏洞组件”，大幅拉低整体评分。
- 运行
composer audit --format=json查看全部依赖漏洞报告 - 重点检查
vendor/下非ThinkPHP但高频使用的包：guzzle、monolog、swiftmailer、ramsey/uuid - 对无法升级的旧组件，用
composer replace声明替代，或加运行时黑名单（如禁用unserialize()调用路径）
修复引入新问题，反而暴露更多攻击面
有些临时补丁会开启详细日志、强制重定向、插入调试输出，甚至启用display_errors=On。扫描器一抓一个准：错误页面泄露PHP版本、路径、数据库结构；302跳转响应头缺失Secure和HttpOnly标识；JSON接口返回X-Powered-By: ThinkPHP——这些都属于“信息泄露”类中高危项，直接拉低CVSS基础分。
立即学习“PHP免费学习笔记（深入）”；
- 关闭所有调试输出：确认
php.ini中display_errors=Off、log_errors=On、error_reporting不含E_NOTICE或E_DEPRECATED - 清理HTTP头：在
app/middleware/SecurityHeader.php中统一移除X-Powered-By、X-ThinkPHP-Version等敏感头 - 检查Cookie设置：登录态Cookie必须带
Secure（HTTPS下）、HttpOnly、Samesite=Strict
扫描器检测的是“运行态”，不是“代码态”
你本地测试时一切正常，但上线环境可能：OPcache未预热导致部分补丁逻辑未加载；Nginx配置漏掉了fastcgi_param PHP_VALUE "disable_functions=exec,system,passthru"；或Docker容器里/tmp可写且未挂载为tmpfs——这些环境级弱点，静态代码扫描看不到，但RexHa、Nessus、Acunetix这类动态扫描器一扫就中。
- 用
curl -I https://yoursite.com/核对关键安全头：Content-Security-Policy、Strict-Transport-Security、X-Frame-Options - 检查
phpinfo()是否仍可访问（即使关了display_errors，也需禁止phpinfo路由） - 验证
disable_functions是否生效：php -r "echo exec('id');"应返回空或报错
