Resumo

  • A versão de 24 de setembro de 2026 do Working Draft YAML-LD 1.0 do W3C passa a descrever explicitamente dois riscos: aliases que ampliam a árvore interna e tags que podem acionar execução inesperada em certos parsers.
  • A seção de segurança não é normativa. O RFC 9512 já abordava os riscos em 2024; o texto do dia 20 de setembro ainda fazia apenas uma referência geral.
  • Conformidade com a representação JSON-LD e controle do software que a constrói exigem comprovações diferentes.

Uma equipe recebe um pequeno arquivo YAML-LD para alimentar um catálogo compartilhado. A repetição foi retirada do texto com o uso de um anchor e de vários aliases. Isso melhora a leitura, mas desloca trabalho para o programa que monta a estrutura em memória. O documento do W3C determina que, na representação interna JSON-LD, cada referência ao nó seja tratada como uma cópia. O tamanho visível do arquivo não mede, portanto, o tamanho do resultado.

O Grupo de Trabalho JSON-LD publicou em 24 de setembro uma versão que torna essa diferença mais explícita. Comparada à edição do dia 20, sua seção de segurança agora cita o RFC 9512 nominalmente, observa que um grafo YAML compacto pode gerar uma árvore muito maior mesmo sem ciclos e menciona a possibilidade de execução inesperada de código por tags em alguns parsers. O exemplo dado é !!python/object. Antes, a seção apenas remetia às considerações de JSON-LD e ao sufixo +yaml.

O risco não nasceu com a revisão. O RFC 9512, texto Informational do IETF de fevereiro de 2024, registrou application/yaml e +yaml e já discutia exaustão de recursos e execução arbitrária de código. A novidade editorial do W3C foi aproximar esses perigos das regras de YAML-LD. Nenhum dos documentos mede a incidência de ataques ou aponta uma instalação específica comprometida. Um Working Draft pode mudar e sua publicação não constitui endosso do W3C ou de seus membros.

O projeto de YAML-LD tem um propósito legítimo e delimitado: permitir que dados vinculados em YAML sejam representados em JSON-LD sem perda semântica. Ele admite anchors e aliases na serialização, mas proíbe ciclos no grafo de representação. Os nomes dos anchors e a estrutura de referências não são preservados como informação semântica. Justamente por isso, uma verificação de ausência de ciclos não basta para demonstrar que a expansão de cópias ficará dentro de um orçamento de memória aceitável.

Há requisitos firmes para a conformidade: UTF-8, processamento compatível com YAML 1.2 ou versão posterior, chaves de mapa como strings e aprovação nas suítes de testes especificadas. O rascunho também alerta que bibliotecas presas às regras de YAML 1.1 podem interpretar palavras como no e on como booleanos. Esses testes ajudam a estabelecer a forma correta dos dados; não selecionam automaticamente a configuração segura de um construtor de tags nem o limite de recursos de uma aplicação real. A seção 6, que traz a advertência nova, declara-se não normativa.

A decisão operacional cabe a quem aceita o arquivo. Uma ficha de aceite poderia registrar versão e modo do parser, tags autorizadas, limites para expansão de aliases, tratamento de entradas externas e casos de teste. Trata-se de uma proposta de Daniel Kade, não de um formulário exigido pelo W3C. A distinção importa em compras e integrações: validar o significado produzido não é a mesma coisa que autorizar qualquer mecanismo para produzi-lo.

Fontes