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></module> 看似只是找不到类,实则可能是恶意 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 风险,而应拆解逻辑:把可序列化的数据和不可序列化的逻辑分离,用注册表+参数白名单代替裸字节流。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!











