PHP反序列化漏洞需结合上下文判断可控unserialize调用、用户输入及POP链，自动化扫描应追踪数据流路径而非仅匹配函数，辅以污点分析和POP链检查，并提供分层修复建议。
PHP反序列化漏洞无法靠简单正则或关键字扫描发现，必须结合代码上下文判断是否存在可控的 unserialize() 调用、是否传入用户输入、是否有可用的 POP 链。自动化扫描的核心不是“找函数”，而是“建路径”——从入口点（如 GET/POST 参数、文件内容、缓存读取）出发，追踪数据流是否能到达危险函数。
识别真实反序列化入口点
很多工具误报源于把无害的 unserialize() 当成漏洞点。真正需关注的是参数可控、未经过滤的调用位置：
- 检查是否直接对 $_GET、$_POST、$_COOKIE、$_REQUEST 的某个键做 unserialize，例如
unserialize($_GET['data']) - 注意 base64_decode + unserialize 组合，常见于 Cookie 或隐藏字段：
unserialize(base64_decode($_COOKIE['session'])) - 排查文件读取后反序列化：
unserialize(file_get_contents($_GET['file']))，此时需确认 $_GET['file'] 是否可被控制为攻击者可控路径（如 php://filter、data://） - 忽略类名硬编码、空字符串、常量或配置值等不可控场景，例如
unserialize('O:8:"UserInfo":0:{}')不构成风险
静态分析关键数据流路径
仅匹配函数调用远远不够。需模拟变量传播，判断用户输入能否“抵达” unserialize。推荐用 PHP-Parser（Python）或 PHAN 配合自定义插件实现轻量级污点分析：
- 定义 source：$_GET、$_POST、$_COOKIE、$_SERVER 等超全局数组的任意下标访问
- 定义 sink：
unserialize(…)的第一个参数 - 跟踪赋值、函数参数传递、数组访问、字符串拼接等操作，但不进入用户自定义函数内部（除非已知其行为）
- 对疑似路径生成“污染路径报告”，例如：
$_POST['raw'] → $input → base64_decode($input) → unserialize(...)
快速验证 POP 链可用性（非完全利用）
扫描器不必执行完整 RCE，但应辅助判断是否存在已知可利用的链。可集成以下轻量检查：
立即学习“PHP免费学习笔记（深入）”；
- 提取项目中所有定义了
__wakeup()、__destruct()、__call()、__get()、__set()的类，按命名/功能分类（如日志类、缓存类、数据库类） - 检查是否引入了 ThinkPHP、Laravel、Monolog、SwiftMailer 等常见框架/组件，并比对已公开 POP 链（如 CVE-2016-7124、CVE-2020-15148）所需类是否存在
- 对目标类构造最小可行 gadget 链示意（不实际序列化），例如：“Class A::__destruct() 调用 $this->log->write()，而 Class Log 中 $this->handler 是可写的，若 handler=system 则可能触发命令执行”
输出可操作的修复建议
报告不能只写“存在反序列化漏洞”，要给出明确、分层的修复指引：
- 首选方案：改用
json_decode()或igbinary_unserialize()等安全替代，前提是业务允许格式变更 - 次选方案：使用
unserialize($data, ['allowed_classes' => false])（PHP 7.4+）禁止所有类实例化 - 兼容方案：校验输入签名（如 HMAC-SHA256）+ 白名单类名过滤，示例：
if (!hash_equals($expected_sig, $_GET['sig'])) die(); $allowed = ['User', 'Config']; $obj = unserialize($_GET['data'], ['allowed_classes' => $allowed]); - 禁用方案：删除无用的反序列化逻辑，尤其临时调试代码（如
// TODO: remove this test后未清理）
不复杂但容易忽略：真正的风险不在有没有 unserialize，而在有没有“人把不该信的数据喂给了它”。脚本的价值是帮人看清这条链，而不是代替人做决定。
