PHP 7.1.20 不支持 allowed_classes 参数，无法启用白名单防护，且默认允许 phar:// 等危险协议，__wakeup() 绕过漏洞（CVE-2016-7124）有效，无安全回调机制，加固措施基本失效。
PHP 7.1.20 的反序列化保护配置失效，核心原因是该版本**不支持 allowed_classes 白名单参数**，且缺乏现代防护机制的底层支持。
不支持 allowed_classes 参数
PHP 7.4 才正式引入 unserialize() 的第二个参数 ['allowed_classes' => [...]]。7.1.20 中调用：
-
unserialize($data, ['allowed_classes' => false])会直接报错或静默忽略——参数被完全丢弃 -
unserialize($data, false)是旧版写法，等价于不传第二参数，毫无防护作用 - 即使写了白名单，7.1.20 仍会无条件还原所有类，包括
think\Model、Monolog\Handler\StreamHandler等高危 POP 链起点
无法禁用危险协议与流封装器
7.1.20 默认允许 phar://、filter:// 等协议，而：
-
phar.readonly = Off在 php.ini 中虽可设为On，但很多旧环境未启用，且框架代码可能绕过（如通过file_exists('phar://a.jpg')触发） -
allow_url_include若为On，配合php://filter可直接造成远程代码执行 - Web 服务器层（如 Nginx）未拦截
phar://请求时，防护链条已断裂
魔术方法执行不可控且无缓解路径
7.1.20 对 __wakeup()、__destruct() 等魔术方法的触发完全开放：
立即学习“PHP免费学习笔记（深入）”；
- CVE-2016-7124（
__wakeup绕过）在该版本中默认生效，攻击者只需将属性个数设小即可跳过校验 - 没有
unserialize_callback_func安全回调机制，也无法限制类加载行为 - Session、缓存、日志等模块若使用
php_serialize或php_binary处理器，且数据来源不可信，极易被注入
替代方案几乎不可行
在 7.1.20 环境下强行“加固”效果极差：
- 改用
json_decode()需全面重构序列化逻辑（如 Session、Cache 驱动），ThinkPHP 5.x 原生不兼容 - 签名校验（如 HMAC）必须在反序列化前完成，但很多旧代码是先
unserialize()再验证，顺序错误 - 手动过滤输入（如正则删
O:、C:）易被字符逃逸绕过（如"x"→"yy"导致长度欺骗）
