PHP 7.3.33 本身无反序列化漏洞，风险源于代码中不当使用 unserialize() 处理用户输入；审计需聚焦危险调用链：定位入口、检查校验缺失、追踪魔术方法、排查 Phar/Session/缓存等高危场景。
PHP 7.3.33 本身不是漏洞版本，它不自带反序列化漏洞；真正的问题出在**代码中是否不当使用了 unserialize() 处理用户输入**。这个版本已停止官方支持（2021年12月），但仍在部分老系统中运行，审计重点不是版本号，而是识别危险调用链。
第一步：快速定位所有 unserialize 入口
打开项目源码，全局搜索以下关键词，重点关注参数是否来自用户可控来源：
-
unserialize(—— 找到所有调用位置 -
$_GET、$_POST、$_COOKIE、$_REQUEST、$_SERVER—— 看是否直接或间接传入unserialize() -
base64_decode、urldecode、hex2bin—— 常见的“伪装”解码操作，可能用于绕过简单过滤后还原恶意序列化字符串
第二步：检查调用上下文是否缺乏校验
对每个 unserialize() 调用点，逐行确认：
- 参数是否经过白名单限制？例如是否用了
unserialize($data, ['allowed_classes' => ['SafeClass']]) - 是否先做了类型/格式校验？比如只允许以
a:（数组）开头，却放行了O:（对象）——这正是攻击者构造恶意对象的突破口 - 是否在反序列化前做过签名验证（如 HMAC 校验）？若无，且数据来自前端（如 cookie 中的
user_data），风险极高
第三步：追踪类定义与魔术方法
找到 unserialize() 可能实例化的类（尤其是未明确指定 allowed_classes 时）：
立即学习“PHP免费学习笔记（深入）”；
- 搜索
class关键词，列出所有已定义类 - 重点检查含以下魔术方法的类：
__wakeup()、__destruct()、__toString()、__call() - 看这些方法里是否有危险操作：如
file_put_contents、system、include、call_user_func、数据库查询拼接等 - 特别注意属性是否为
public且被直接使用（如$this->cmd在__destruct中执行），这类结构极易被利用
第四步：关注高危组合场景（7.3.33 中仍常见）
这些模式在老旧项目中高频出现，需优先排查：
-
Session 反序列化：若
session.serialize_handler配置为php_serialize，而应用又用unserialize($_SESSION['xxx'])，攻击者可通过控制 session 文件内容触发 POP 链 -
Phar 反序列化：即使没直接调用
unserialize()，只要存在文件操作函数（如file_exists、fopen、getimagesize）处理用户上传的 Phar 文件，就可能触发自动反序列化 - 缓存/队列反序列化：Redis、Memcached 中存储的序列化值被原样取出并反序列化，尤其在任务队列（如 Gearman、Beanstalkd）中常见
不复杂但容易忽略
