Alerta de segurança em n8n CVE-2026-25049 permite execução remota de comandos e escapa da sandbox

A comunidade de segurança detectou uma falha grave em n8n, a plataforma de automação de fluxos de trabalho, que permite a execução remota de comandos no servidor onde corre a aplicação se for explorada com sucesso. O problema, registrado como CVE-2026-25049 e com uma pontuação elevada no sistema CVSS (9.4), é uma evasão de controlos de saneamento na avaliação de expressões que revier parcialmente uma correção aplicada no ano passado para a vulnerabilidade CVE-2025-68613 (CVSS 9.9).

Os mantenedores de n8n publicaram um aviso no GitHub onde detalham que um usuário autenticado com permissões para criar ou editar fluxos pode injetar expressões especialmente construídas em parâmetros do fluxo que terminam escapando do mecanismo de sandbox e provocando a execução de comandos do sistema anfitrião. Pode ler-se a explicação oficial e as versões corrigidas no Aviso de segurança de n8n no GitHub.

Do ponto de vista técnico, a raiz do problema está na diferença entre as verificações que o TypeScript faz em tempo de compilação e o que ocorre em tempo de execução com JavaScript. Como explicaram várias equipes de pesquisa, entre eles Endor Labs, o TypeScript pode ajudar a identificar que uma certa propriedade deveria ser uma cadeia no código-fonte, mas essas garantias desaparecem ao executar valores que um atacante introduz dinâmicamente. Aproveitando isto, podem-se passar valores não esperados (objetos, arrays, símbolos, etc.) que burlam as funções de saneamento e permitem sair da caixa de proteção.

Pesquisadores independentes publicaram análises técnicas que ilustram como a evasão é obtida e como os passos são encadeados para alcançar a execução remota. O trabalho de divulgação inclui uma desagregação minuciosa das técnicas empregadas e exemplos práticos; uma dessas análises detalhadas pode ser consultada na pesquisa de Fatih Çelik sobre a sequência de falhas e bypasses: n8n RCEs: A Tale of 4 Acts.

O risco é agravado quando combinado com a funcionalidade do Webhooks de n8n. Se um atacante criar um fluxo com um webhook público e sem autenticação, você pode inserir a carga que provoca execução de comandos e, uma vez ativado o fluxo, qualquer pessoa que conheça o endpoint pode disparar e executar código no servidor. Equipamentos como SecureLayer7 e Pillar Security Têm detalhado cenários de impacto que incluem roubo de chaves API, acesso a segredos de nuvem, movimento lateral para contas conectadas e controle de workflows ligados a serviços de inteligência artificial.

n8n libertou correcções nos ramos afetados; as versões que contêm os adesivos são 1.123.17 para a série 1.x e 2.5.2 para a série 2.x. Atualizar uma versão alterada deve ser a prioridade número um para qualquer implantação vulnerável. Se não for possível aplicar a actualização imediata, é conveniente tomar medidas compensatórias para reduzir a exposição: limitar quem pode criar e editar fluxos para um grupo reduzido de utilizadores de confiança, desactivar ou proteger os webhooks públicos e executar n8n em ambientes com privilégios do sistema e regras de rede restritas para minimizar os danos em caso de intrusão.

Também é importante auditar os fluxos existentes e os registros de atividade para detectar mudanças suspeitos ou endpoints públicos recém-criados. Em sistemas que possam ter sido comprometidos, as credenciais e chaves disponíveis no ambiente em causa devem ser quebradas e os acessos revistos. As empresas que dependem de integrações e máquinas críticas devem priorizar esta revisão e a campanha de adesivo.

A cadeia de descoberta desta vulnerabilidade incluiu contribuições de várias equipes e analistas de segurança, entre eles Fatih Çelik, Cris Staicu de Endor Labs, Eilon Cohen de Pillar Security e Sandeep Kamble de SecureLayer7; os mantenedores de n8n os reconheceram publicamente por seus relatórios.

Este episódio destaca uma lição clássica, mas frequentemente ignorada: as verificações estáticas do tipo não substituem as validações robustas em tempo de execução quando são tratadas entradas não confiáveis. Organizações como OWASP levam anos insistando na necessidade de múltiplas camadas de defesa e na validação estrita de entradas; a documentação geral sobre riscos de validação e controle de entrada pode ser consultada em recursos como OWASP. Para compreender melhor por que o TypeScript não evita este tipo de exploits, o guia do próprio projeto TypeScript oferece contexto sobre como seu sistema de tipos atua em tempo de compilação, mas não persiste no bundle final: Documentação do TypeScript.

Em resumo, se você usar n8n em produção: primeiro, atualiza o quanto antes das versões adesivos. Depois, verifique permissões e exposição do webhooks, endurece o ambiente de execução e realiza uma auditoria de possíveis indicadores de compromisso. Se precisar de mais informações técnicas, as análises dos pesquisadores e o aviso de n8n são recursos públicos úteis para entender o alcance e os vetores de exploração: Aviso do GitHub, o deep-dive de Fatih Çelik, e os relatórios Endor Labs, SecureLayer7 e Pillar Security.