深度剖析 PyYAML 不安全反序列化漏洞：从原理溯源到防御实践

最新推荐文章于 2026-01-07 13:36:22 发布

原创最新推荐文章于 2026-01-07 13:36:22 发布 · 756 阅读

14 ·

CC 4.0 BY-SA版权

原创文章，禁止转载，否则保留追究法律责任的权利。

文章标签：

#PyYAML #反序列化 #rce #python #web安全

Security 专栏收录该内容

30 篇文章

订阅专栏

【精选优质专栏推荐】

《AI 技术前沿》 —— 紧跟 AI 最新趋势与应用
《网络安全新手快速入门(附漏洞挖掘案例)》 —— 零基础安全入门必看
《BurpSuite 入门教程(附实战图文)》 —— 渗透测试必备工具详解
《网安渗透工具使用教程(全)》 —— 一站式工具手册
《CTF 新手入门实战教程》 —— 从题目讲解到实战技巧
《前后端项目开发(新手必知必会)》 —— 实战驱动快速上手

每个专栏均配有案例与图文讲解，循序渐进，适合新手与进阶学习者，欢迎订阅。

文章目录

本文深入剖析了 Python 常用库 PyYAML 中存在的不安全反序列化漏洞，重点探讨了 UnsafeLoader 构造器导致远程代码执行（RCE）的技术机理。文章首先从反序列化的本质出发，解构了 PyYAML 如何通过 Constructor 机制将 YAML 标签映射为 Python 函数调用；随后通过详细的实践案例，展示了恶意构造的 !!python/object/apply 标签如何劫持执行流并触发系统命令；同时，针对 PyYAML 5.x 至 6.x 的版本变迁，分析了社区在安全策略上的应对与演进。最后，本文提出了以 SafeLoader 为核心的防御体系，并给出了静态分析、输入验证等深度防御方案，旨在引导开发者在追求配置灵活性的同时，严守系统安全边界。

一、引言

在现代软件工程中，数据序列化与反序列化（Serialization and Deserialization）是实现跨平台通信、配置文件解析以及持久化存储的核心技术。YAML（YAML Ain’t Markup Language）凭借其极佳的可读性与对复杂数据结构的广泛支持，已在 Python 生态系统中取代了部分 XML 与 JSON 的应用场景，广泛应用于 CI/CD 配置、微服务架构以及深度学习模型参数管理。然而，由于反序列化过程本质上是根据外部输入的数据构建内存对象的过程，若处理逻辑缺乏足够的安全边界限制，便会演变为严重的安全漏洞。

在 Python 环境下，PyYAML 库作为最主流的解析器，曾长期因其默认的反序列化行为而备受争议。尤其是当开发者显式使用或在旧版本中默认触发 UnsafeLoader 时，攻击者可以构造恶意 YAML 文档，通过特定的构造标记劫持程序的执行流，进而实现远程代码执行（Remote Code Execution, RCE）。本文旨在通过对 PyYAML 反序列化机制的深度解构，配合实际案例演练，探讨其背后的技术原理、历史演进及标准化的防御体系。

二、技术原理深度剖析

2.1 反序列化漏洞的本质属性

反序列化漏洞的核心逻辑在于“数据与控制权的混淆”。在正常逻辑下，反序列化器应当仅负责还原数据的属性值（如字符串、整数、列表等）。但为了支持高级特性，如对象持久化，许多序列化框架允许在数据流中携带类型信息（Type Information）。当解析器读取到这些信息时，会自动寻找对应的类并进行实例化。如果解析器对可实例化的类缺乏校验（即“白名单机制”的缺失），攻击者就可以诱导程序实例化如 os.system、subprocess.Popen 等具有危险副作用的系统类或函数。

2.2 PyYAML 的构造器机制（Constructor）

PyYAML 处理数据的过程分为四个主要阶段：扫描（Scanning）、解析（Parsing）、组合（Composing）和构造（Constructing）。漏洞触发的关键在于“构造”阶段。PyYAML 使用特定的 Constructor 类将 YAML 节点（Nodes）转换为 Python 对象。

在 PyYAML 的设计中，它支持通过特殊的标签（Tags）来映射 Python 的内置类型、自定义类甚至是函数。例如，!!python/object 标签可以用于还原一个复杂的对象状态，而 !!python/object/apply 标签则允许解析器在还原对象时直接调用指定的函数。当开发者使用 UnsafeLoader 时，这些强大的标签处理能力被完全释放。UnsafeLoader 继承自 BaseConstructor 和其他处理类，其内置的映射表包含了对 Python 任意可调用对象的处理逻辑。这意味着，只要攻击者能够在输入的 YAML 中植入这些特有的标签，解析器就会按照标签指示，自动执行对应的 Python 代码，从而实现从数据解析到指令执行的跨越。

2.3 核心触发载荷：!!python/object/apply 的深层运作

在众多的 Python 专用标签中，!!python/object/apply 是最具威胁的一个。其技术原理类似于 Python 中的内置函数 apply()（或直接调用）。当解析器识别到该标签时，它会执行以下逻辑：

解析标签后的标识符，确定目标函数（如 os.system）。
解析后续的参数序列。
利用 Python 的反射机制（如 getattr 或直接从模块导入），动态加载目标模块，并将参数传入执行。

这种机制的设计初衷是为了让 YAML 能够记录程序运行时的复杂状态，但在不可信的输入源环境下，它直接将系统的控制权交给了外部输入。由于 os.system 会在宿主操作系统的 Shell 中执行命令，攻击者只需构造一个简单的命令字符串，即可获取服务器的系统权限。

2.4 PyYAML 版本变迁与安全策略演进

PyYAML 社区对该漏洞的修复经历了一个漫长的过程。在 PyYAML 5.1 之前的版本中，yaml.load() 默认使用 Loader，其实际指向即为具有全量权限的构造器。随着 CVE-2017-18342 等漏洞的披露，社区意识到默认开启此类特性是极度危险的。

在 5.1 及后续版本中，社区引入了 FullLoader（虽然限制了部分极度危险的构造，但仍非绝对安全）和 SafeLoader（仅允许基础数据类型）。到了 PyYAML 6.0 版本，安全性得到了进一步加强：直接调用 yaml.load() 会强制要求开发者指定 Loader 参数，否则将抛出异常。这种“显式声明”的约束，迫使开发者在便利性与安全性之间做出审慎的选择。本文实践案例中所展示的，正是开发者在明知风险或误操作的情况下显式指定 UnsafeLoader 所产生的安全后果。

三、实践案例分析：从 Payload 注入到 RCE 触发

为了更直观地展示此漏洞的影响力，我们将通过一个具体的实验场景进行演示。该场景模拟了一个典型的 Python 应用，该应用读取外部配置文件并使用 UnsafeLoader 进行解析。

3.1 实验环境准备

在复现该漏洞前，需确保 Python 环境中已安装 PyYAML。

pip install pyyaml

3.2 构造恶意 Payload

攻击者的目标是利用 os.system 执行系统命令。以下是一个典型的恶意 YAML 文档：

# test.yaml
# 利用 !!python/object/apply 标签调用 os.system 函数
# 执行的指令为 'cmd /c whoami'，旨在展示当前执行权限
!!python/object/apply:os.system
- cmd /c whoami

在这里插入图片描述

代码深入剖析：

!!python/object/apply: 这是 PyYAML 特有的标签，指令解析器去调用一个 Python 可调用对象。
os.system: 目标函数。由于 os 模块是 Python 的内置标准库，解析器可以轻易定位。
- cmd /c whoami: 传递给函数的参数列表。在 Windows 环境下，cmd /c 会启动命令提示符执行后续指令。

3.3 漏洞触发代码

以下是存在漏洞的服务端代码，展示了不安全地加载配置文件的典型场景。

# test.py
import yaml

def load_yaml_vuln(path: str):
    """
    显式使用 UnsafeLoader，因此存在 RCE 漏洞

    在 PyYAML ≤ 5.x 中，yaml.load() 默认使用不安全 Loader，可直接触发反序列化 RCE
    
    在 PyYAML ≥ 6.x 中，需显式指定 UnsafeLoader 才能复现

    """
    with open(path, 'r', encoding='utf-8') as f:
        data = yaml.load(f, Loader=yaml.UnsafeLoader)
    return data


if __name__ == "__main__":
    print("[*] 开始加载 test.yaml")
    result = load_yaml_vuln("test.yaml")
    print("[*] yaml.load 返回值：", result)

3.4 执行结果与现象解释

当执行 python test.py 时，控制台将输出类似以下内容：

[*] 开始加载 test.yaml
laptop-XXXX\YourUserName
[*] yaml.load 返回值： 0

在这里插入图片描述

现象深度分析：

在 yaml.load(f, Loader=yaml.UnsafeLoader) 执行的瞬间，PyYAML 的构造器递归处理 test.yaml 中的节点。当它识别到 !!python/object/apply:os.system 时，它会暂停当前的数据还原流，转而动态调用 os.system('cmd /c whoami')。此时，子进程被创建并执行命令，输出当前的系统用户名。随后，os.system 的退出码（0）被返回给 Python 解释器，并赋值给 result 变量。

这一过程完整地演示了攻击者如何通过一个“纯文本”文件，劫持 Python 程序的执行逻辑，从而在受害者服务器上执行任意系统指令。

四、防御策略与最佳实践

针对 PyYAML 反序列化漏洞，防御的核心原则是“最小权限原则”，即仅授予反序列化器解析必要数据类型的权限。

4.1 核心防御方案：SafeLoader

最直接且有效的防御措施是完全禁用 Python 对象构造功能。PyYAML 提供的 SafeLoader（对应快捷方法 safe_load）仅解析标准的 YAML 标签（如 !!str, !!int, !!map 等），任何尝试使用 !!python/ 前缀标签的行为都会触发 ConstructorError。

# 安全的加载方式推荐
def load_yaml_safe(path: str):
    with open(path, 'r', encoding='utf-8') as f:
        # 方法一：直接使用快捷函数
        data = yaml.safe_load(f)
        
        # 方法二：显式指定 SafeLoader
        # data = yaml.load(f, Loader=yaml.SafeLoader)
    return data

如图所示，使用 yaml.safe_load() 后，恶意 YAML 中的 python/object/apply 标签无法被解析，程序抛出 ConstructorError，未发生命令执行，漏洞修复有效：

在这里插入图片描述

4.2 深度防御策略

使用 bandit 或 Semgrep 等静态扫描工具检查代码库中所有 yaml.load 的调用，强制要求使用 SafeLoader 或其等价物。
确保 PyYAML 版本不低于 6.0。在高版本中，默认的安全限制能有效防止开发者因疏忽而引入的隐式不安全调用。
对于来自不可信来源（如 Web 请求、用户上传）的 YAML 文件，即便使用了 SafeLoader，也应配合严格的 Schema 校验。同时，建议在低权限的容器（如 Docker）中运行解析逻辑，并限制其出站网络连接，以减轻 RCE 发生后的损失。
如果配置文件仅涉及键值对和列表，可以考虑使用更安全、语法更严苛的序列化格式，如 JSON。JSON 本身不支持对象实例化标签，在根源上规避了此类反序列化风险。

五、总结

PyYAML 的 UnsafeLoader 漏洞是典型的逻辑设计余留风险。虽然它为 Python 对象在 YAML 中的深度集成提供了便利，但在缺乏信任边界的互联网环境下，这种特性无异于为攻击者敞开了系统的大门。通过本文的剖析可以发现，漏洞的预防并不复杂，关键在于开发者对“数据解析”与“指令执行”界限的清醒认知。在实际开发中，应始终坚持默认不信任外部输入的原则，强制使用 SafeLoader，从而构建起坚实的软件供应链安全防线。