摘要

  • W3C 于 2026 年 9 月 24 日发布的 YAML-LD 1.0 工作草案，在非规范性的安全章节中明确写入两类风险：别名可放大内部数据树，某些 YAML 标签可让解析器意外执行代码。
  • 这些不是本周才出现的风险。IETF 于 2024 年发布的 RFC 9512 已有相关讨论；9 月 20 日版 YAML-LD 草案尚未在自身安全章节如此具体地列出。
  • YAML-LD 的语义转换和符合性测试，不能代替某个实际解析器的资源上限、标签处理方式与不可信输入控制。

一家机构收到合作方提交的 YAML-LD 文件，用来更新可供机器读取的目录。文件只有几行，审核者能读懂其中的关联数据，也能确认它可转为 JSON-LD。真正进入系统前，还有一道较少被看见的关口：谁来展开文件中的别名，展开后占用多少内存，解析库会不会把特定标签交给具有执行能力的构造器？这不是文字长短能够回答的问题。

9 月 24 日版本相对于 9 月 20 日版本的可核实变化，正落在这道关口。新版的第 6 节明确链接 RFC 9512，并说明即使 YAML 图没有循环，紧凑的别名结构仍可能变成大得多的 JSON-LD 树；另有些标签会在部分解析器中触发意外的代码执行，文中以 !!python/object 为例。此前版本只概括地指向 JSON-LD 安全考虑和 +yaml 后缀。新段落让既有风险进入该格式的正文视野，并没有发布漏洞公告，也没有制定一套新的强制防护措施。

RFC 9512 是 IETF 在 2024 年 2 月发布的 Informational 文件，登记了 application/yaml 媒体类型和 +yaml 结构化后缀，早已讨论资源耗尽与任意代码执行。因此，不能把 W3C 新文字写成安全问题的首次发现。W3C 文件本身仍是可能修订的工作草案，发布也不代表 W3C 及其成员认可具体实现。公开材料没有提供特定产品的事故、攻击率或安全认证结果。

YAML-LD 要解决的是另一件重要的事：使以 YAML 表达的关联数据能够在不损失语义的情况下表示为 JSON-LD。草案允许在序列化中使用锚点和别名，但禁止表示图出现循环；构造 JSON-LD 内部表示时，每次别名引用都视为所指节点的一份拷贝，锚点名称和别名结构不会保留为语义数据。复用同一定义让文件更易写，却也可能使“输入大小”与“构造成本”脱钩。禁止循环不等于禁止无循环的放大。

规范还有明确的符合性条件，包括 UTF-8、兼容 YAML 1.2 或后续版本的处理方式、字符串形式的映射键以及指定测试套件。它也指出旧 YAML 1.1 库会把 no、on 等词误作布尔值，造成互操作问题。这些要求说明怎样取得符合格式的数据；它们不会自动给部署中的解析器设定内存预算，或关闭某种语言构造器。第 6 节明确标为非规范性内容。

因此，真正需要签字的不是一个笼统的“支持 YAML-LD”。接收文件的机构应能说明使用哪一版解析库、允许什么标签、怎样限制别名展开、哪些输入不可信，以及测试覆盖了什么。这是 Daniel Kade 提出的操作记录，并非 W3C 要求的表格。语义符合性证明数据能被正确表示；解析行为是否安全，必须由负责运行它的人另行证明。

来源