Pickle反序列化必然执行任意代码，因__reduce__方法返回(callable, args)元组并在还原时直接调用，结合REDUCE指令不可禁用、无完整性校验等设计，使不可信数据反序列化等于交出解释器控制权。
pickle.load() 和 pickle.loads() 会执行任意代码，不是“可能”，是设计如此——你只要反序列化不可信数据，就等于把解释器的控制权交给了攻击者。
为什么 __reduce__ 是最大突破口
__reduce__ 方法本用于自定义对象如何被序列化，但它返回的元组形如 (callable, args)，会在反序列化时被直接调用。攻击者无需伪造类定义，只需构造字节流触发该机制：
- os.system、subprocess.run、exec、importlib.import_module 都可作为 callable
- 即使类名/模块名被过滤，也能通过 builtins.eval 或动态拼接字符串绕过
- REDUCE 指令在 pickle 协议中无法禁用，它是反序列化逻辑的核心环节
常见错误现象：AttributeError: Can't get attribute 'XXX' on <module '__main__'> 看似只是找不到类，实则可能是恶意 payload 替换了模块路径，或诱导解释器去加载远程恶意模块。
真实场景中哪些操作等于“主动开后门”
- 从 HTTP 请求体、用户上传的
.pkl文件、数据库字段中直接调用pickle.load() - 用
redis.get()取出的值未经校验就传给pickle.loads() - 在 Celery / Dask / Spark worker 中反序列化任务参数，却未验证提交者身份
- 模型服务接收用户上传的 PyTorch
.pth或自定义.pkl权重文件并直接torch.load(..., map_location='cpu')（底层仍走 pickle）
所谓“限制类名白名单”为什么常失效
仅靠重写find_class() 并设置白名单（如只允许 numpy.ndarray）远远不够：
- 攻击者可用 builtins.exec + 字符串拼接绕过模块名检查
- __setstate__、__new__、__init__ 等钩子函数同样可被触发并执行代码
- 白名单若未严格限定模块路径（例如允许 os 但禁止 os.system），仍可通过 getattr(os, 'system') 动态调用
- 所有防御都建立在“反序列化前数据未被篡改”前提上；而 pickle 本身不带完整性校验，必须额外加 hmac 或签名
替代方案选型不能只看“能不能用”
JSON 不支持函数和自定义类，但正因如此它安全；safetensors 专为张量设计，无代码执行面；msgpack 虽快，但默认不拒绝 NaN 或 inf，解析失败可能掩盖更深层问题。真正难处理的是那些“必须传闭包、lambda 或当前模块内定义类”的场景——这时不该硬扛 pickle 风险，而应拆解逻辑：把可序列化的数据和不可序列化的逻辑分离，用注册表+参数白名单代替裸字节流。
