为什么Python中不能随意使用pickle反序列化数据？-Python教程-PHP中文网

pickle反序列化会执行任意代码，因其本质是执行构造指令流而非解析数据，__reduce__作为默认开启的执行入口，返回(callable, args)后直接调用，且所有协议版本均依赖该机制，无法禁用。

为什么python中不能随意使用pickle反序列化数据？

因为 pickle.loads() 和 pickle.load() 不是“解析数据”，而是“执行构造指令”——只要数据来自不可信源，就等于把 Python 解释器的控制权交给了攻击者。

每个可被 pickle 的对象在反序列化时，只要定义了 __reduce__ 方法，就会被无条件调用。它返回的元组形如 (callable, args)，而 pickle 会直接执行 callable(*args)。这不是可选行为，是协议核心逻辑。

哪怕你只序列化一个空字典，攻击者也能伪造字节流，让 __reduce__ 返回 (os.system, ("id",))
REDUCE 操作码无法禁用，所有协议版本（0–5）都依赖它重建对象
你无法通过“不定义 __reduce__”来规避——内置类型（如 builtins.eval）和第三方类（如 subprocess.Popen）本身就能被直接引用并调用

重写 find_class() 并限制模块/类名，看似可控，实则漏洞百出：

python-code-analyz

专业Python代码分析与优化，支持语法检查、安全扫描、性能评估、复杂度分析及重构后优化代码生成。

下载

攻击者可用 builtins.getattr + 字符串拼接绕过：比如白名单放行 os，但没禁 getattr，就能动态调用 getattr(os, "system")
__setstate__、__new__、__init__ 等钩子函数同样会在还原过程中被触发，且不经过 find_class
白名单只校验“类名是否允许”，不校验“该类实例化后会做什么”——例如 numpy.ndarray 安全，但它的 __setstate__ 可被篡改为执行任意代码
所有白名单逻辑都假设“字节流未被篡改”，但 pickle 本身不带完整性校验；没加 hmac 或签名，白名单形同虚设

很多人误以为 joblib.load() 或 torch.load(..., map_location="cpu") 更“模型专用”所以更安全，其实它们底层仍调用 pickle.load() 或 pickle.loads()：

torch.load() 在加载 .pkl 或 .pth 时，若文件含恶意 payload，map_location 只影响张量设备，不影响反序列化逻辑
joblib.load() 默认使用 pickle 协议 4，且不启用任何沙箱；它甚至会自动解压并递归反序列化嵌套对象
第三方模型平台（如 Hugging Face）上传的 .pkl 文件，一旦被部署服务直接 load，就等同于运行未知作者的 Python 脚本

不是因为“它们更简单”，而是设计契约完全不同：它们只处理纯数据，不恢复行为。

json.loads() 永远不会调用 os.system、不会导入模块、不会执行任何函数——它只生成 dict、list、str、int 等内置类型
配合 dataclasses.asdict() 或 pydantic.BaseModel.model_dump()，你能把对象转成 JSON 友好结构，再用 json.dumps() 序列化；反向时用 MyClass(**data) 构造，控制权始终在你自己手里
这种分离（数据 vs 行为）才是根本解法：把可序列化的状态和不可序列化的逻辑拆开，而不是试图给 pickle 加锁