tp5.0控制器执行漏洞本质是路由解析失控导致的rce，源于框架默认对控制器名缺乏强校验，攻击者可通过invokefunction绕过白名单或_method变量覆盖触发命令执行，补丁需手动应用且业务层风险仍存。
TP5.0控制器执行漏洞本质是路由解析失控导致的远程代码执行（RCE），攻击者无需登录、不依赖调试模式，即可调用框架内部敏感方法执行任意系统命令或读取敏感文件。核心问题不在“有没有写错代码”，而在于框架默认行为对控制器名缺乏强校验。
漏洞触发的两个典型路径
实际利用中，主要通过以下两种方式落地：
-
路径一：invokefunction 路由绕过
构造类似/index.php?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=whoami的请求。TP5.0 默认允许反斜杠\分隔命名空间，将think\app识别为控制器，invokefunction识别为操作方法，最终调用call_user_func_array执行system——这一步完全绕过控制器白名单机制。 -
路径二：_method 变量覆盖
当url_param_type=0（默认）且未禁用自动路由时，POST 请求中传入_method=__construct&filter[]=system&method=GET&get[]=whoami。框架在初始化 Request 对象时，会用__construct覆盖实例属性，把filter设为system；后续在参数过滤阶段，input()方法会调用该filter回调，直接执行命令。
为什么补丁不能只靠升级版本号
很多项目误以为“升级到 TP5.1 或 TP6 就安全了”，但若原始 TP5.0 项目中已存在硬编码调用eval、system或未过滤的file_get_contents($_GET['file'])等逻辑，这些代码在新版本里依然能运行——漏洞载体从框架层下沉到了业务层。
更关键的是，TP5.0 的漏洞补丁（如 App.php 第555行正则校验）必须手动打上。官方补丁包不会自动覆盖你本地修改过的thinkphp/library/think/App.php。如果项目曾定制过路由逻辑或重写过dispatch流程，补丁位置可能偏移，需逐行比对。
生产环境必须做的三件事
防御不是加个配置就完事，要卡住入口、堵死链路、验证效果：
-
入口拦截：在
public/index.php最顶部加入硬性过滤，例如：if (strpos($_SERVER['QUERY_STRING'], '\think') !== false || strpos($_SERVER['QUERY_STRING'], 'invokefunction') !== false) { die('Access Denied'); } -
关闭高危开关：确认
config/app.php中'app_debug' => false、'url_route_on' => true（关路由反而更危险）、'url_param_type' => 0（避免路径顺序解析被利用）；特别注意'var_method' => '_method'必须删除或注释，这是变量覆盖漏洞的导火索。 -
运行时加固：在
php.ini中启用disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source，并确保allow_url_include = Off。这不是万能方案，但能大幅抬高攻击成本。
验证是否真修复了
别信日志，要实测。用以下三个 payload 分别发起请求，任一返回非404或非空响应即代表未修复：
- GET：
/index.php?s=index/\think\app/invokefunction&function=phpinfo&vars[0]=1 - POST：
_method=__construct&filter[]=phpinfo&method=GET（Content-Type: application/x-www-form-urlencoded） - GET：
/index.php?s=captcha&_method=__construct&filter[]=assert&server[REQUEST_METHOD]=1
测试时务必使用真实生产配置（app_debug=false），避免误判“调试模式下打不通=已修复”。
