内容摘要：2018年12月，ThinkPHP官方发布了一个安全更新，修复了5.0.23和5.1.31版本中的一处远程代码执行漏洞。这个漏洞后来被标记为CNVD-2018-24942，圈内人更习惯叫它"Think

2018年12月，漏洞ThinkPHP官方发布了一个安全更新，漏洞修复了5.0.23和5.1.31版本中的漏洞一处远程代码执行漏洞。这个漏洞后来被标记为CNVD-2018-24942，漏洞圈内人更习惯叫它"ThinkPHP 5.x RCE"。漏洞当时我在一个甲方做安全巡检，漏洞内部扫描器一夜之间爆出上百条告警，漏洞全是漏洞这个。那会儿离春节还有不到两个月，漏洞运维群里哀嚎一片。漏洞

漏洞的漏洞根子出在Request类的method()方法上。ThinkPHP 5为了兼容各种HTTP方法伪造场景，漏洞允许通过POST参数里的漏洞_method变量来覆盖实际请求方法。问题在于，漏洞这个覆盖动作发生在路由解析之前，漏洞而路由解析又会把用户可控的字符串拼进call_user_func_array之类的动态调用里。攻击者构造一个POST请求，把_method设成__construct，再配合路由参数里的filter字段，就能让框架把任意函数当成回调执行。说白了，框架自己把刀递到了攻击者手里。

利用链并不复杂。公开的PoC大概长这样：

POST /index.php?s=captcha HTTP/1.1 Content-Type: application/x-www-form-urlencoded _method=__construct&filter[]=system&method=get&get[]=whoami 

这段请求打过去，服务器直接返回whoami的执行结果。我第一次在测试环境复现的时候，看到回显里跳出"nt authority\system"，后背确实凉了一下。更麻烦的是，这个漏洞不需要任何认证，也不需要开启debug模式，只要路由能走到captcha这个点，基本就是通杀。

为什么影响面这么大？ThinkPHP在国内中小型项目里的装机量太恐怖了。很多外包团队、快速交付的CMS、甚至一些政企内部系统，都拿它当默认框架。5.0.x和5.1.x又是当时文档最全、社区教程最多的版本。漏洞公开后，ZoomEye和Shodan上能扫出几十万台暴露在公网的实例。有人写了个批量脚本，一晚上传遍各大安全论坛。那段时间，黑产挂马、挖矿、勒索的流量明显往上蹿了一截。

官方修复方式其实很直接：在Request::method()里加了一层判断，如果_method参数的值不是合法的HTTP方法名，就直接忽略。同时把路由调度里的动态调用做了白名单过滤。补丁出来后，升级到5.0.24或5.1.32就能堵住。但现实是，很多项目根本升不动——老代码依赖了被修改的内部行为，一升就报错。于是各种临时缓解方案冒出来：WAF加规则拦_method=__construct、在入口文件里unset($_POST['_method'])、甚至有人直接把captcha路由给删了。

我印象最深的是一个客户，他们的系统跑在Windows Server 2008上，PHP版本还是5.6。运维说升级框架要重新做回归测试，排期排到了三个月后。最后我们只能在Nginx层加了一条规则，把带filter[]参数的请求全部403。这种打补丁的方式治标不治本，但至少让他们撑过了那个春节。

这件事过去好几年了，ThinkPHP也迭代到了6和8。可每次翻漏洞库，看到5.x的RCE还是会被拿出来当案例讲。不是因为它技术含量多高，而是它太典型了——一个为了开发便利设计的特性，在安全边界上撕开的口子，最后要用无数人的加班来填。写框架的人觉得"用户不会这么干"，写漏洞的人偏偏就这么干了。