CLTPHP 的任意任意文件删除漏洞，藏在一个看起来人畜无害的文件参数里。去年秋天我帮朋友排查一个建站项目，删除后台登录后随手点了几个功能，任意发现删除缓存的文件操作居然能直接指定路径。当时没太在意，删除后来翻源码才确认——这玩意儿根本没做路径过滤。任意
问题出在 app/admin/controller/Common.php 这类公共控制器里。文件开发者写了个删除文件的删除方法，大概长这样：
public function delFile() { $path = input('path'); if (file_exists($path)) { unlink($path); return json(['code' => 1,任意 'msg' => '删除成功']); } }路径直接从请求参数拿，拼都不拼一下，文件unlink() 就上去了。删除攻击者抓包改个 path=../../config/database.php，任意服务器上对应的文件配置文件就没了。删配置文件还算轻的删除，要是能删 .htaccess 或者入口文件 index.php，站点直接瘫痪。更狠一点，删掉 install.lock，系统会重新走安装流程，数据库配置被覆盖，整个站就成别人的了。
这个漏洞的触发门槛低得离谱。只要拿到后台权限——弱口令、爆破、或者别的漏洞组合——就能利用。有些版本连后台都不需要，接口直接暴露在前台。我见过一个案例，攻击者用脚本批量扫 /admin/common/delFile?path= 这个路径，一晚上删了几百个站点的 runtime 目录，服务器日志里全是 unlink 失败的错误。
为什么会出现这种低级问题？翻了下 CLTPHP 的更新记录，2018 年到 2020 年间的版本迭代很快，代码质量参差不齐。开发者可能觉得“后台功能，管理员才能用，没必要防”。这种思路在早期 CMS 里很常见——权限校验做了，但输入校验漏了。问题是，后台权限和文件系统权限是两码事。管理员能删缓存，不代表能删系统文件。
修复方式倒不复杂。把 $path 做白名单限制，或者用 realpath() 转成绝对路径后判断是否在允许的目录内。再狠一点，直接写死要删的文件名，不让传参。可惜很多站点用的是旧版，源码里改起来麻烦，干脆打个补丁在入口处过滤 .. 和 /。我见过一个运维直接上 open_basedir，把 PHP 能访问的目录锁死在 web 根目录，虽然粗暴但有效。
说个细节。这个漏洞的 PoC 在网上流传的版本里，有人用 path=../../../../etc/passwd 去读文件，发现读不了——因为 unlink 不是 file_get_contents，删和读是两回事。但有人不死心，试了 path=../../../../tmp/sess_xxx，把 session 文件删了，导致自己掉线。这种“自杀式”利用看起来好笑，但换成删别人的 session，就是另一回事了。
如果你正在用 CLTPHP，赶紧去看看 Common 控制器里有没有类似的方法。搜 unlink 关键字，看看参数从哪里来。有过滤就加固，没过滤就赶紧补。别等站点被删空了才想起来查日志——那时候日志可能也被删了。