GHSA-9x83: quando editar um workflow do n8n vira execução de código no host

Em uma plataforma de automação, dar a alguém permissão para editar workflows não deveria equivaler a entregar um shell no servidor. O advisory GHSA-9x83-43r8-5hwc mostrou exatamente essa quebra de fronteira no n8n: uma expressão criada por um usuário com privilégio de montar workflows podia escapar do ambiente de avaliação e compilar código dentro do processo principal. O resultado potencial é comprometimento completo da instância que concentra credenciais, webhooks e conexões com outros sistemas.

O que o advisory confirma

O mantenedor publicou o GHSA em 19 de agosto de 2026 com severidade alta e CVSS 4.0 de 8,7. O vetor oficial é CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N: ataque pela rede, baixa complexidade, nenhuma condição adicional, baixo privilégio e nenhuma interação de outra pessoa. Na data deste texto, o advisory não associa uma CVE à falha, por isso usamos o identificador GHSA em vez de criar uma referência inexistente.

• Linha 1.x corrigida em 1.123.73.
• Linha 2.35 estável corrigida em 2.35.4.
• Linha 2.36 beta corrigida em 2.36.2.
• Instâncias n8n Cloud foram atualizadas automaticamente, segundo o boletim do fornecedor.
• Instâncias self-hosted abaixo da correção de sua linha precisam ser atualizadas pelo operador.

Como uma propriedade herdada atravessou o sandbox

A raiz está em uma distinção pequena do JavaScript que tem efeito enorme em fronteiras de segurança. Ao resolver um nome de placeholder fornecido pelo chamador, `$fromAI` não exigia que a chave fosse uma propriedade própria do objeto e também aceitava chaves reservadas. Em JavaScript, consultar uma chave sem essa verificação pode continuar pela cadeia de protótipos. Contra um valor primitivo, essa resolução devolvia uma referência viva a um protótipo do ambiente hospedeiro.

A partir dessa referência, uma expressão podia caminhar até o construtor `Function`. Esse construtor compila código JavaScript, e o código deixava de rodar dentro do modelo restrito esperado para a expressão. O ponto decisivo não é apenas obter um objeto inesperado. É obter um objeto que ainda pertence ao processo hospedeiro e conserva um caminho até uma capacidade de execução.

• Aceitar nomes de propriedade controlados pelo usuário amplia a entrada muito além dos campos previstos.
• Bloquear alguns nomes perigosos é insuficiente se a resolução ainda percorre propriedades herdadas.
• Copiar dados para estruturas sem protótipo e exigir propriedades próprias reduz essa classe de confusão.
• Objetos que cruzam a fronteira do sandbox não podem manter referências vivas a construtores ou protótipos do host.
• Testes de segurança precisam incluir chaves reservadas, valores primitivos e caminhos de protótipo, não apenas expressões comuns.

Por que baixo privilégio ainda significa alto impacto

O pré-requisito é uma conta autenticada capaz de construir ou editar workflows. Isso reduz o conjunto de atacantes, mas não reduz o que acontece depois do escape. O código é executado no processo principal do n8n e herda as permissões do usuário de sistema, o acesso de rede e os arquivos disponíveis ao serviço. Em muitas instalações, esse processo precisa alcançar bancos, filas, APIs internas e serviços externos para que as automações funcionem.

É por isso que a permissão de editar workflow deve ser tratada como privilégio de desenvolvimento sobre um sistema sensível, e não como acesso comum de negócio. A documentação do n8n observa que editores conseguem executar workflows e usar credenciais já vinculadas a eles, mesmo quando a credencial não foi compartilhada diretamente. A falha adicionava uma rota para sair dessa delegação controlada e atingir o ambiente que guarda as integrações.

Atualize e confirme o runtime

A correção é atualizar para 1.123.73, 2.35.4, 2.36.2 ou versão posterior dentro da linha adotada. Em uma implantação self-hosted, não basta alterar a tag no repositório ou concluir o pipeline. Confirme a versão do contêiner em execução, alinhe componentes como workers e runners e verifique se réplicas antigas não continuam atendendo tráfego.

# Exemplo para uma implantacao Docker Compose cujo servico se chama n8n
docker compose pull n8n
docker compose up -d n8n
docker compose exec n8n n8n --version

# Auditoria defensiva documentada pelo n8n
docker compose exec n8n n8n audit

O comando `n8n audit` não prova que a falha foi explorada nem substitui investigação. Ele ajuda a localizar riscos que aumentam o impacto, como nós com acesso ao sistema de arquivos, nós oficiais de alto risco, community nodes, webhooks sem proteção, configurações de segurança ausentes e instância desatualizada. Use o resultado para revisar o raio de alcance depois do patch.

Se o patch não puder entrar agora

O advisory deixa claro que os controles temporários não corrigem a vulnerabilidade. Até a atualização, restrinja a instância a usuários totalmente confiáveis, desabilite recursos e nós relacionados a IA quando não forem necessários e execute o processo sob uma conta de sistema dedicada e com baixo privilégio. Também vale remover acesso direto à internet, limitar saída de rede e revisar quais projetos realmente precisam de editores.

• Retire temporariamente a capacidade de editar workflows de contas que não precisam dela.
• Desabilite recursos de IA não utilizados e registre a exceção com prazo para remoção.
• Separe credenciais por projeto e reduza escopos no serviço de destino, não apenas no n8n.
• Execute o n8n como usuário sem privilégio, com sistema de arquivos e rede limitados ao necessário.
• Revise logs de autenticação, alterações de workflow, execuções incomuns e conexões de saída no período anterior ao patch.
• Rotacione segredos se houver indício de execução não autorizada ou se a telemetria não permitir excluir essa hipótese.

O que um pentest deve validar além da versão

Um scanner identifica a versão vulnerável. Um pentest contextual precisa testar o modelo de confiança que tornou o impacto tão alto: quem recebe papel de editor, quais credenciais ficam disponíveis por projeto, quais nós permitem código ou acesso a arquivo, que destinos o processo alcança e se uma execução anômala aparece na telemetria. A pergunta útil não é só se o GHSA foi corrigido, mas se outra falha no editor encontraria o mesmo caminho livre até produção.

• Mapear papéis globais, projetos, compartilhamentos e contas sem uso recente.
• Validar isolamento entre projetos e o uso indireto de credenciais em workflows compartilhados.
• Inventariar nós de código, sistema de arquivos, Git, shell, community nodes e ferramentas de IA.
• Testar controles de saída para bancos, APIs internas, endpoints de metadados e serviços em nuvem.
• Confirmar que mudanças sensíveis, execuções e acessos a segredos geram logs úteis e alertas acionáveis.
• Retestar em uma conta de baixo privilégio, com autorização, sem executar payload destrutivo no ambiente produtivo.

A lição do GHSA-9x83-43r8-5hwc é maior que um bug em `$fromAI`. Plataformas de automação reúnem código configurável, identidade, segredos e conectividade no mesmo plano. Quando um sandbox falha, todas essas capacidades passam a definir o impacto. Corrigir a versão fecha esta rota. Reduzir privilégios e alcance limita a próxima.