最有效修复方式是直接禁用setup.php反序列化入口：生产环境应删除或重命名该文件，或在文件开头强制exit拦截；同时移除__wakeup中eval调用，升级PHP并启用unserialize($data, ['allowed_classes' => false])，禁用allow_url_fopen及危险流封装器。
直接禁用 setup.php 是最有效手段
只要生产环境还留着 /scripts/setup.php，就等于开着一个不认证、不校验、无条件调用 unserialize() 的后门。这个文件在 phpmyadmin 2.10–4.8.x 中是漏洞核心入口，$_post['configuration'] 一来就反序列化，连 $action 都不判断是否为 clear。
别信“加固过滤”这种说法——修复不是给漏洞打补丁，而是拔掉插头：
- 删除或重命名
/scripts/setup.php（官方从 4.9.0 起已废弃该脚本） - 若必须保留旧版，直接在文件开头加
if (isset($_POST['configuration'])) { http_response_code(403); die(); } - Nginx 层加拦截：
location ~ ^/scripts/setup\.php$ { return 403; } - 检查宝塔等面板是否硬链接了完整实例（如
/www/server/phpmyadmin/PMA/setup/），一并屏蔽或删软链
所有 unserialize() 调用点必须启用 allowed_classes
grep -r "unserialize(" --include="*.php" . 会发现不止 setup.php，还有 import.php、session 处理、压缩包元数据解析等地方也用了它。PHP 7.0+ 必须统一加上白名单控制，否则任何一处失控都可能被利用。
错误写法：unserialize($data) —— 参数若来自用户输入（比如 POST、ZIP 内容、cookie），就是 RCE 温床。
正确写法（PHP 7.4+ 推荐）：unserialize($data, ['allowed_classes' => false])，彻底禁用对象反序列化；若必须反序列化特定类，明确列出：['allowed_classes' => ['PMA_SomeSafeClass']]。
注意：allowed_classes = [] 在 PHP 7.0–7.3 中等价于 false，但 PHP 7.4+ 才真正强制执行，升级 PHP 版本是前提。
删掉 __wakeup() 和 load() 里的 eval()
反序列化链能打穿，关键在于 PMA_Config::__wakeup() 触发 load()，而后者用 eval('?>'. file_get_contents(...)) 加载配置——这等于把任意文件内容当 PHP 代码执行。
定位到 libraries/classes/Config.php（老版本是 libraries/config.class.php），找到 load() 方法，做三件事：
- 删掉所有
eval()分支 - 只允许读取固定路径的
config.inc.php，且必须是绝对路径、无协议（禁止php://、ftp://等） - 改用
json_decode(file_get_contents($path), true)+ 严格 schema 校验，彻底规避代码执行
别试图“过滤 source 字段”，攻击者能绕过所有字符串匹配——删 eval 才是断链最干净的方式。
底层 PHP 配置不能松懈
代码层修得再严，如果 PHP 配置开着危险开关，攻击者仍可能绕过：
- 确认
allow_url_fopen = Off，否则file_get_contents('php://filter/...')或远程 URL 仍可被加载 - 禁用危险流封装器：
stream_wrapper_unregister('phar')（尤其 PHP 7.4+ 默认启用 phar 流） -
session.serialize_handler不要用php_serialize（易受反序列化影响），改用php或igbinary - 检查
error_log和display_errors是否关闭，避免反序列化失败时泄露类名和路径
最容易被忽略的是：你以为只改了 setup.php 就万事大吉，但 import.php 解析 ZIP 元数据时也曾有类似问题，而这类调用点往往藏在第三方依赖或老模块里，必须逐个 grep 并验证参数来源是否可信。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
