要約

  • W3Cが2026年9月24日に公表したYAML-LD 1.0作業草案は、非規範的な安全性の節で、エイリアスによるデータの膨張と一部のタグによる予期しないコード実行を具体的に挙げた。
  • 2024年のRFC 9512には既に同種の危険が記されている。9月20日版から変わったのは、YAML-LD草案自身の説明の明確さであり、新しい事故の報告ではない。
  • データをJSON-LDとして正しく表せることと、実装したパーサーを安全に動かせることは、別々に確かめる必要がある。

外部から届いたYAML-LDを、組織内の検索用データに取り込む場面を考える。担当者には数行の記述にしか見えない。共通の定義をアンカーで示し、複数の箇所でエイリアスとして参照すれば、ファイルを短く保てる。しかし取り込み側は、その参照を内部表現に組み立てる。人が目で見た行数は、生成されるデータ構造の大きさを保証しない。

JSON-LD作業部会の9月24日版は、この処理段階を安全性の論点として前面に出した。9月20日版の同節はJSON-LDの安全性と+yamlへの簡潔な参照にとどまっていた。新しい文章はRFC 9512への参照を明示し、循環を含まないコンパクトなYAMLグラフでも、エイリアスによってはるかに大きなJSON-LDの木に展開され得ると述べる。さらに、一部のパーサーではタグが予期しないコード実行を引き起こし得るとし、!!python/objectを例示した。

ここでいう追加は警告の具体化であって、脆弱性の新発見でも対策の義務化でもない。IETFが2024年2月に発行したInformational RFC 9512は、YAMLのメディアタイプと構造化接尾辞を登録する際に、資源枯渇や任意コード実行を既に扱っていた。今回確認した資料から、特定の製品に問題があるとか、実際に攻撃が起きたとは言えない。W3Cの作業草案は改訂され得る文書であり、その公開はW3Cや会員による承認を意味しない。

YAML-LDが定める中心的な価値は、YAMLで記述したLinked Dataを意味を失わずJSON-LDとして表現できることだ。草案はアンカーとエイリアスの使用を許す一方、表現グラフの循環を禁止する。内部表現の構築ではエイリアス参照をノードのコピーとして扱い、アンカー名や参照の形は意味データとして残さない。この仕様上の仕組みを理解すれば、循環チェックに合格することと展開量が小さいことを同一視できない。

UTF-8の使用、YAML 1.2以降との互換性、文字列のマッピングキー、所定のテスト群への適合など、草案には規範的な条件もある。YAML 1.1に基づくライブラリではnoやonを真偽値と解釈し、相互運用性を損ねるとも説明する。だが、これらは導入組織のメモリ上限や、言語固有のタグ構築機能の許可設定を自動的に決めない。新しい危険の説明が置かれた第6節は、明示的に非規範的だ。

受け入れ審査では、フォーマットに適合するかに加え、どのパーサーと設定で外部入力を読むのかを記録すべきだろう。版、許可するタグ、エイリアス展開の限度、入力の信頼境界、試験内容を分けて残すというのはDaniel Kadeの運用提案であり、W3Cが指定した帳票ではない。正しく変換できる文書にも、変換を始める前に確かめるべき条件がある。

出典