优先修复ThinkPHP 3.2.15的preg_replace /e漏洞，立即禁用php.ini中的preg_replace函数；其次验证并修复5.1.x低于5.1.30的控制器绕过RCE漏洞，升级或添加反斜杠拦截；最后统一审计危险函数调用。
ThinkPHP 3.2.15 和 5.1.x 同时存在于一个生产系统中时，必须按漏洞实际危害、可利用性与修复紧迫性排序，不能因“版本新旧”或“是否还在维护”模糊处理——3.2.15 的 preg_replace /e 漏洞仍在被黑产批量利用，5.1.x 若低于 5.1.30 则存在控制器绕过 RCE，两者都可直接 getshell，但攻击入口、防御成本和影响面不同。
先堵 3.2.15 的 preg_replace /e 执行链
第一步：确认项目是否启用 URL 兼容模式（即非 PATHINFO）且存在可控正则参数。常见于老后台的搜索框、日志筛选、导出条件拼接等位置，只要代码里出现类似 preg_replace('/(.*)/e', $user_input, $str) 或调用 ThinkPHP 自带的 Dispatcher.class.php 路由解析逻辑，就极可能触发。
第二步：立即禁用 PHP 的 preg_replace 的 /e 修饰符。在 php.ini 中加入 disable_functions = preg_replace ——注意这不是临时方案，而是当前唯一能阻断全部利用路径的硬性措施；【禁用后需人工检查所有使用 preg_replace 的业务代码，替换为 preg_replace_callback】。
第三步：删除或重命名 Runtime/ 目录下所有已生成的日志文件。因为攻击者常通过日志文件包含（如 ?s=index/index&log=../Runtime/Logs/202608/06.log）二次执行 payload，不清理就等于留后门。
立即学习“PHP免费学习笔记（深入）”；
再处理 5.1.x 的控制器绕过 RCE
方法一：快速验证是否已受控。访问 /index.php?s=index/ hinkpp/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1][]=1，若返回 phpinfo 页面，说明未修复且环境可利用。
方法二：升级到 5.1.30 是底线。执行 composer update topthink/framework:5.1.30；若 Composer 报依赖冲突，不要降级或跳过，直接修改 composer.json 中 "topthink/framework" 行为 "~5.1.30" 并运行 composer update --with-dependencies。
方法三：若因历史插件锁死无法升级，必须在 public/index.php 最顶部插入拦截逻辑：
```php
if (isset($_GET['s']) && strpos($_GET['s'], '\') !== false) {
die('Access denied');
}
```
这一步不能省——【5.1.29 及以下版本中，s 参数含反斜杠即代表高危路由解析路径，必须阻断】。
两个版本共存时的处置顺序
① 优先执行 3.2.15 的 disable_functions = preg_replace 操作，该操作可在 30 秒内完成，且对所有 PHP 进程生效，覆盖全部攻击入口。
② 紧接着验证 5.1.x 是否可被 invokefunction 利用，确认后 10 分钟内完成 composer 升级或手动加拦截代码。
③ 最后统一审计两套系统的 $_GET/$_POST 使用点，重点排查含 eval、call_user_func、system、file_put_contents 的业务代码——这些不是框架漏洞，但会复用已有 RCE 权限横向提权。
