必须盯死input()和$request->param()调用点，重点检查其参数是否未经白名单校验即参与类名/方法名调用、模板路径拼接、SQL字段或文件操作，尤其警惕action、callback、file、lang等高危参数及路由变量/:plugin等隐蔽入口。
盯死 input() 和 $request->param() 的所有调用点
ThinkPHP6.x 中绝大多数漏洞入口都源于用户输入未校验就直接参与敏感操作。不要只搜 $_GET 或 $_POST，框架封装后的入口更隐蔽、更危险。
重点检查：input('action')、input('callback')、input('file')、input('lang') 这类高危参数名是否被拼进类名、方法名、模板路径或 SQL 字段；$request->param('rules') 这类常用于低代码规则解析的参数，极易触发 eval() 或 call_user_func_array()。
- 若发现
new $className()或$obj->$method()中的变量来自上述输入，且无白名单校验，立刻标记为高危 - 若
input('file')被传给view()或file_get_contents()且未做realpath()+ 白名单比对，大概率存在文件读取或 RCE - 特别注意路由变量如
/:plugin、/:lang，它们在控制器中常以$this->request->param('plugin')形式出现，但审计时容易被忽略
查清 view() 模板路径拼接是否绕过规范化
CVE-2025-63888 在 6.1.0+ 仍活跃，不是“已修复”，而是“默认关闭但可被业务代码重新打开”。关键不在于框架版本，而在于你是否写了显式路径拼接逻辑。
搜索所有 view( 调用，尤其关注含 .、..、input()、$request->param() 的字符串拼接，例如：view('../runtime/log/' . input('file')) 或 view('admin/' . $this->request->param('tpl'))。
立即学习“PHP免费学习笔记（深入）”；
- 只要没调用
normalizePath()或realpath()做二次校验，且未限定根目录（如app()->getAppPath()），就可能被?file=../../public/index触发 PHP 解析 - 注意
view()->engine->layout(false)这类手动关闭布局的行为，它会绕过部分内置路径限制 - 上传型利用场景下，攻击者常先上传带 PHP 的图片到
public/uploads/，再用路径遍历去加载执行
扫描 __destruct() 和 __toString() 构成的反序列化链
ThinkPHP 6.0.12+ 引入的 TagCache 驱动让反序列化风险从“理论”变成“真实利用”。漏洞不依赖公开 POP 链，而是由业务缓存写入 + 未过滤的 session 反序列化共同触发。
重点关注：vendor/topthink/think-orm/src/Model.php 中的 __destruct() 是否可控 $this->lazySave；Conversion.php 中的 __toString() 是否能导向 toJson() → toArray() → 危险字段输出。
- 若项目使用了自定义缓存驱动或重写了
TagCache::set()，且未对传入值做类型白名单限制，就可能把恶意对象存进缓存 - session 反序列化点常见于登录态校验后未清理的
Session::get()或Cache::get('user_'.session_id()) - 别只盯着
unserialize($_SESSION['data'])这种明文调用——ThinkPHP 的缓存驱动默认启用序列化，Cache::remember()也可能触发
验证所有动态规则解析是否隔离执行环境
低代码平台、表单引擎、权限规则模块最爱用 eval() 或 create_function() 解析前端传来的 JSON 规则字符串，这是 2026 年 Q1 真实事件占比最高的应用层 RCE 场景。
搜索 eval(、create_function(、assert(，尤其注意形如 eval('return ' . $rule . ';') 或 call_user_func($callback, $data) 的模式。
- 若
$rule来自input('rules')或数据库配置项，且无沙箱或 AST 解析机制，就是 9.8 分 CVSS 漏洞 - WAF 几乎无效，因为参数名五花八门：可能是
validator、check、rule_set，甚至藏在 base64 编码字段里 - 修复不是加
strip_tags()，而是改用白名单函数映射（如['required' => 'isNotEmpty', 'email' => 'filter_var_email']）
最易被忽略的其实是“已升级但未清理”的历史逻辑——90% 的漏洞出现在 6.1.0+ 系统里，不是因为新版本有 bug，而是老代码还在用 new $className()、还在拼 view() 路径、还在 eval() 动态规则。升级框架不等于清除风险，得一行行核对业务代码里那些“看起来没问题”的调用。
