Falhas de isolamento em JavaScript e Python expõem n8n a ataques RCE por usuários autenticados
Duas vulnerabilidades graves recentemente descobertas na plataforma de automação de workflows n8n expõem organizações a risco de execução remota de código (RCE), mesmo quando o acesso é restrito a usuários autenticados. As falhas estão diretamente relacionadas a problemas nos mecanismos de sandbox usados para rodar código em JavaScript e Python dentro da ferramenta.
As brechas foram identificadas pela equipe de pesquisa em segurança da JFrog e afetam cenários em que usuários com conta válida na instância do n8n conseguem abusar da forma como o ambiente “isolado” (sandbox) foi implementado. Embora, em tese, esse isolamento devesse impedir a execução de código perigoso no sistema subjacente, os pesquisadores mostraram que é possível contornar essas proteções.
As vulnerabilidades foram catalogadas como CVE-2026-1470 e CVE-2026-0863. A primeira recebeu pontuação CVSS 9.9, sendo classificada como crítica, enquanto a segunda foi avaliada com pontuação 8.5, também considerada de alta gravidade. Ambas abrem caminhos diferentes para chegar ao mesmo objetivo: executar código arbitrário no servidor que hospeda o n8n.
No caso da CVE-2026-1470, o problema está no mecanismo de sandbox de expressões do n8n. Um usuário autenticado pode injetar código JavaScript especialmente construído em determinados pontos da aplicação, explorando particularidades da linguagem e da implementação da sandbox. Com isso, torna-se possível escapar do ambiente supostamente controlado e executar comandos diretamente no nó principal da aplicação, caracterizando um ataque de execução remota de código.
Já a CVE-2026-0863 envolve o executor de tarefas em Python. A falha permite que o atacante burle as restrições da sandbox que deveria limitar o que o código Python pode fazer. Explorando esse comportamento, um invasor autenticado consegue rodar código Python arbitrário no sistema operacional, abrindo a porta para acesso ao arquivo de configuração, credenciais, variáveis de ambiente e outros recursos sensíveis da máquina.
A combinação dessas vulnerabilidades é particularmente perigosa porque, uma vez exploradas, elas podem levar ao comprometimento completo da instância do n8n. Isso vale inclusive para ambientes configurados no modo de execução “internal”, em que o próprio n8n gerencia diretamente a execução das tarefas. A documentação oficial já alertava que esse modo não é recomendado para produção, justamente por oferecer menos isolamento entre a aplicação e o ambiente onde o código das automações roda.
Em contrapartida, o modo “external” foi projetado para separar melhor o processo principal do n8n dos componentes responsáveis pela execução de workflows e scripts. Nesse modelo, a superfície de ataque é reduzida, pois eventuais falhas em tarefas ou scripts tendem a ficar contidas em processos externos, que podem ser mais facilmente monitorados, limitados e reiniciados. Mesmo assim, as novas vulnerabilidades mostram que confiar apenas na arquitetura padrão não é suficiente: é essencial manter a plataforma atualizada e reforçar controles adicionais.
O impacto prático dessas falhas é ampliado pelo papel que o n8n costuma desempenhar em ambientes corporativos. A plataforma é amplamente usada para orquestrar fluxos de trabalho envolvendo inteligência artificial, integrações internas e automações de negócios. Na prática, isso significa que uma única instância do n8n muitas vezes tem acesso concentrado a:
– APIs de modelos de linguagem e outras soluções de IA;
– dados de vendas e CRM;
– sistemas de identidade e acesso (IAM);
– bancos de dados internos e serviços críticos da organização;
– chaves, tokens e credenciais armazenadas em variáveis de ambiente ou cofres integrados.
Nesse contexto, explorar uma falha como a CVE-2026-1470 ou CVE-2026-0863 pode funcionar como obter uma “chave mestra” da infraestrutura. Em vez de atacar diretamente cada sistema corporativo, o invasor compromete o n8n e, a partir dele, se movimenta lateralmente para outros serviços, acessando fluxos de automação que já possuem permissões privilegiadas.
Para reduzir o risco imediato, a principal medida é atualizar o n8n para versões que contenham as correções oficiais. De acordo com a JFrog, a vulnerabilidade CVE-2026-1470 foi corrigida nas versões 1.123.17, 2.4.5 e 2.5.1. Já a CVE-2026-0863 foi tratada nas versões 1.123.14, 2.3.5 e 2.4.2. Ambientes executando releases anteriores a essas versões permanecem vulneráveis e devem ser priorizados em qualquer plano de resposta.
Além da atualização, é recomendável revisar o modo de execução em uso. Sempre que possível, o modo “external” deve ser adotado em ambientes de produção, em conjunto com restrições adicionais no nível do sistema operacional, como uso de containers, perfis de segurança, usuários de sistema com privilégios mínimos e segmentação de rede. Quanto mais limitada for a superfície de ataque ao redor do n8n, menor será o impacto caso alguma nova vulnerabilidade venha a ser descoberta.
Os especialistas também sugerem reforçar os controles de acesso. Como as falhas atuais dependem de um usuário autenticado, vale a pena:
– restringir o número de contas com permissão para criar ou editar workflows;
– revisar permissões de usuários internos e integrações de terceiros;
– adotar autenticação multifator para contas administrativas;
– segmentar instâncias de teste e produção, evitando compartilhamento de credenciais.
Monitoramento também se torna um componente fundamental da defesa. Administradores devem configurar logs detalhados de execução de workflows, registrar alterações de configurações e acompanhar criação ou modificação de nós que permitam execução de código. Alertas automatizados para comportamentos atípicos – como execuções em massa, acionamento de nós inesperados ou tentativas de acessar recursos sensíveis – podem indicar uma exploração em andamento.
O alerta sobre essas novas falhas surge pouco tempo depois de outra vulnerabilidade de gravidade máxima no n8n, identificada como CVE-2026-21858 e apelidada de Ni8mare. Diferentemente das brechas atuais, o Ni8mare permitia que um invasor não autenticado assumisse o controle completo de instâncias expostas. A sucessão de descobertas evidencia que plataformas de automação, por sua natureza flexível e integrada, tornaram-se alvos prioritários de pesquisadores – e também de atacantes.
Do ponto de vista técnico, os casos reforçam o desafio histórico de implementar sandboxes realmente seguras em linguagens dinâmicas como JavaScript e Python. Esses ecossistemas contam com recursos pouco documentados, APIs internas, comportamentos específicos de exceção e detalhes do interpretador que, quando combinados de forma criativa, permitem escapar de restrições pensadas apenas para cenários comuns. Cada atualização da linguagem ou da engine de execução pode introduzir novos caminhos para contornar o isolamento.
Para equipes de desenvolvimento que dependem do n8n, as falhas também trazem lições práticas de governança de automação. Em muitas organizações, workflows são criados rapidamente para “quebrar galhos”, acumulando permissões amplas, chaves de acesso e lógicas complexas sem a devida revisão de segurança. Uma boa prática é tratar automações críticas com o mesmo rigor de uma aplicação tradicional: revisão de código, testes de segurança, documentação, controle de versão e aprovação formal.
Outra medida importante é separar fluxos por nível de criticidade. Workflows que lidam com dados sensíveis, chaves de produção ou ações destrutivas (como apagar registros, alterar permissões ou disparar pagamentos) devem ser isolados em instâncias próprias, com acesso mais restrito e monitoramento reforçado. Isso limita os danos caso uma brecha seja explorada em uma área menos crítica da automação.
Organizações que utilizam n8n em conjunto com soluções de IA generativa também precisam ficar atentas ao risco de “encadeamento de impacto”. Um atacante que consiga controlar o n8n pode manipular prompts, interceptar dados enviados a modelos de linguagem ou mesmo usar a infraestrutura de IA para automatizar parte de suas próprias ações maliciosas. Em ambientes onde decisões de negócio são cada vez mais automatizadas, esse tipo de comprometimento pode levar a fraudes, vazamento de dados ou ações irreversíveis.
Por fim, a descoberta dessas vulnerabilidades reforça a necessidade de uma postura de segurança contínua em relação a ferramentas de automação. Não basta apenas instalar o n8n e configurá-lo uma única vez: é essencial acompanhar notas de versão, aplicar patches com rapidez, revisar periodicamente quem tem acesso à plataforma e como as integrações estão estruturadas. A combinação de atualização constante, princípio do menor privilégio, isolamento de ambientes e monitoramento proativo é, hoje, a melhor estratégia para reduzir o impacto de falhas em plataformas tão centrais quanto o n8n.