Escape da sandbox do agente da Skyvern recebeu um CVE 53 dias depois da correção

Uma fuga da sandbox na Skyvern, o agente autohospedado que controla um navegador a partir de etapas geradas por LLM, recebeu o CVE-2026-82447 e foi publicado no GitHub Advisory Database em 29 de agosto de 2026 às 15:30:19 UTC. A correção de código que ele descreve entrou no repositório em 6 de julho às 21:44:03 UTC — 53 dias antes.

O que a falha realmente era

O TextPromptBlock da Skyvern renderizava cada prompt duas vezes. A primeira passagem usava o SandboxedEnvironment do Jinja, como previsto. A segunda passava a mesma string influenciada por um atacante por um renderizador sem sandbox, o suficiente para executar código como processo do servidor. A correção, commit d723de6, é uma exclusão: três linhas adicionadas e onze removidas em block.py, eliminando a segunda renderização e o argumento parameter_values que a alimentava. O restante do commit é testes.

Onde a narrativa erra

Há duas coisas que se dizem sobre avisos como este que não são verdade aqui. A primeira é que teria sido um patch silencioso. Não foi: as notas de lançamento da versão v1.0.45, publicadas em 7 de julho às 22:19:18 UTC, de fato contêm a palavra "SSTI". Mas isso aparece em um único tópico num corpo de release com cerca de 190 linhas, sem aviso de segurança do fornecedor, sem CVE à época e sem nada que o distinguisse do tráfego rotineiro de changelog. A segunda é a implicação de que o ano de um CVE diz quando você esteve exposto. Não diz — o CVE foi atribuído pela VulnCheck como autoridade de numeração de terceiros, e não pelo projeto.

A parte que quebra as ferramentas

O registro do aviso traz uma pontuação CVSS 3.1 de 8.8 e uma pontuação CVSS 4.0 de 8.7, e está classificado como CWE-1336. Mas seu array estruturado vulnerabilities está vazio. O intervalo afetado — 0.2.1 até, mas sem incluir, 1.0.45 — existe apenas como texto na página da VulnCheck. Qualquer scanner que leia os dados estruturados do aviso do GitHub e verifique uma dependência fixada de skyvern contra eles não apontará absolutamente nada.

Por que esse formato se repete

O caminho de exploração não é exótico. Um parâmetro de workflow, ou a saída de um bloco upstream, é texto que o próprio agente produziu ou ingeriu; ele chega a um renderizador de templates; torna-se código no host do agente. Essa é a ponte da injeção de prompt para execução em sua forma mais direta, e ela é estrutural em ferramentas que permitem que a saída de um modelo conduza uma camada de templates.