内容摘要：2018年底，ThinkPHP 5.0.x 和 5.1.x 被爆出一个远程文件上传漏洞，编号 CVE-2018-1002015。攻击者构造一个特殊的 multipart/form-data 请求，就能

2018年底，文件ThinkPHP 5.0.x 和 5.1.x 被爆出一个远程文件上传漏洞，上传编号 CVE-2018-1002015。漏洞攻击者构造一个特殊的文件 multipart/form-data 请求，就能把 PHP 文件塞到服务器上，上传然后直接访问执行。漏洞那会儿大量中小站点中招，文件因为国内用 ThinkPHP 的上传项目实在太多了。

问题出在 think\facade\Request 的漏洞 file() 方法上。框架在处理上传文件时，文件没有严格校验文件名的上传后缀，而是漏洞依赖 $_FILES['file']['name'] 里客户端传来的值。更关键的文件是，getUploadFile() 方法里用了 pathinfo() 取扩展名，上传但没做白名单过滤，漏洞只简单检查了是否在允许列表里——而这个列表在某些配置下是空的，或者被绕过。

具体利用方式很直接。构造一个 POST 请求，Content-Type 设为 multipart/form-data，文件字段名填 file，文件名写成 shell.php。如果目标控制器里有类似 $file = request()->file('file'); $file->move('./uploads/'); 的代码，文件就会落到 uploads 目录下。攻击者再访问 /uploads/shell.php，服务器就归他了。

我见过一个真实案例。某企业官网用 ThinkPHP 5.1 搭的，后台有个“上传资质文件”的功能。代码里写了 $file->validate(['ext'=>'jpg,png,pdf'])->move($path)，看起来挺安全。但那个 validate 规则写错了——它只检查了 MIME 类型，而 MIME 是客户端可以伪造的。攻击者把 Content-Type: image/jpeg 塞进去，文件名却还是 shell.php，结果照样上传成功。这个细节说明，光靠 validate 不够，必须同时锁死后缀名和 MIME。

ThinkPHP 官方在 5.0.24 和 5.1.31 版本里修了这个问题。补丁的核心是强制用 strtolower(pathinfo($name, PATHINFO_EXTENSION)) 取后缀，并且把 move() 方法里的文件名生成逻辑改成随机字符串加安全后缀。但很多老项目没升级，或者开发者自己重写了上传逻辑，漏洞依然存在。

有个现象挺有意思。这个漏洞爆发后，网上出现大量“ThinkPHP 上传漏洞利用工具”，输入 URL 就能自动扫描并上传 webshell。工具作者甚至把 payload 打包成 Python 脚本，连菜鸟都能用。这导致漏洞利用门槛极低，一时间国内被挂马的站点数量飙升。我查过一些公开的威胁情报，当时每天新增的恶意 PHP 文件里，超过三成跟这个漏洞有关。

防御其实不复杂。第一，升级到修复版本，别偷懒。第二，自己写上传逻辑时，后缀名白名单必须硬编码，比如 ['jpg','jpeg','png','gif']，其他一律拒绝。第三，上传目录禁止执行 PHP，在 Nginx 里加 location ~* /uploads/.*\.php$ { deny all; }，Apache 用 .htaccess 写 php_flag engine off。第四，文件名重命名，别用用户传的原始名，用 md5(uniqid()) 加后缀。这几条做到位，基本就堵死了。

说句实在话，ThinkPHP 这个漏洞不是框架独有的问题，而是 PHP 文件上传处理里常见的坑。很多开发者觉得“我用了框架就安全了”，结果连最基本的后缀检查都交给客户端。这种心态比漏洞本身更危险。我见过一个项目，上传功能用的是 move_uploaded_file($_FILES['file']['tmp_name'], $path . $_FILES['file']['name'])，连框架都没用，文件名直接拼路径。攻击者传个 ../../shell.php 就能穿越目录。这种代码在 2023 年还能见到，你说意不意外？

最后提一句，CVE-2018-1002015 只是 ThinkPHP 众多漏洞里的一个。后来还有 5.0.23 的 SQL 注入、5.1.41 的远程代码执行。用这个框架的人，最好把版本锁在最新稳定版，并且养成看官方安全公告的习惯。别等服务器被挖矿了才想起来打补丁，那时候损失已经造成了。