O n8n se consolidou como uma das ferramentas de automação de fluxos de trabalho mais populares entre desenvolvedores, administradores de sistemas e entusiastas de self-hosting. Sua flexibilidade, aliada ao modelo open source e à facilidade de integração com centenas de serviços, fez com que milhares de instâncias auto-hospedadas fossem implantadas em servidores Linux ao redor do mundo. No entanto, essa mesma flexibilidade agora está no centro de um alerta crítico de segurança.
Pesquisadores da JFrog divulgaram duas novas falhas graves no n8n, identificadas como CVE-2026-1470 e CVE-2026-0863, que permitem RCE por meio de escape de sandbox, mesmo em cenários onde o acesso autenticado é exigido. Ambas receberam pontuação de gravidade 9.9, o que as coloca entre as vulnerabilidades mais severas já registradas na plataforma. O impacto é direto para quem mantém instâncias auto-hospedadas desatualizadas, tornando urgente a aplicação das correções.
Entendendo as vulnerabilidades CVE-2026-1470 e CVE-2026-0863
As duas falhas exploram um ponto sensível da arquitetura do n8n, a capacidade de executar código dinâmico dentro de ambientes que deveriam estar isolados. Embora o objetivo seja oferecer flexibilidade aos fluxos de automação, erros no isolamento dessas execuções criaram uma superfície de ataque perigosa.
Escape de sandbox em JavaScript usando a instrução with
A CVE-2026-1470 afeta o mecanismo de execução de JavaScript no n8n. O problema está relacionado ao uso inadequado da instrução with, que pode ser explorada para manipular o escopo de execução. Em vez de permanecer restrito ao contexto controlado do fluxo de trabalho, um atacante autenticado consegue acessar objetos globais do Node.js.
Na prática, isso permite quebrar o sandbox e executar comandos arbitrários no sistema operacional subjacente. Uma vez obtido esse nível de acesso, o atacante pode instalar backdoors, extrair segredos armazenados em variáveis de ambiente e pivotar para outros serviços na mesma infraestrutura. Esse tipo de n8n RCE é especialmente crítico em servidores que também hospedam bancos de dados ou outros serviços internos.
Falha no Python baseada em introspecção de objetos
Já a CVE-2026-0863 explora o ambiente de execução Python integrado ao n8n. A vulnerabilidade se baseia em técnicas de introspecção de objetos, permitindo que um código aparentemente inofensivo navegue pela hierarquia interna do interpretador Python.
Ao abusar dessa introspecção, o atacante consegue acessar funções sensíveis e escapar das restrições impostas pelo sandbox. O resultado final é semelhante ao da falha em JavaScript, execução remota de código com os privilégios do processo do n8n. Mesmo exigindo autenticação, o risco é elevado, pois credenciais podem ser obtidas por phishing, reutilização de senhas ou comprometimento de contas menos privilegiadas.
O perigo das instâncias auto-hospedadas
Um dos pontos mais preocupantes do relatório da JFrog é a constatação de que a adoção de atualizações de segurança no ecossistema do n8n é lenta. Estimativas indicam que quase 40 mil instâncias auto-hospedadas permaneciam vulneráveis dias após a divulgação das falhas.
Esse cenário é comum em ambientes de self-hosting, onde atualizações nem sempre fazem parte de um processo automatizado. Diferentemente da nuvem oficial do n8n, que já recebeu as correções e não é afetada por essas falhas, servidores mantidos pelos próprios usuários dependem de ação manual. Isso cria uma janela de oportunidade perigosa para ataques oportunistas, especialmente após a publicação de provas de conceito.
Para administradores de sistemas, a falsa sensação de segurança por exigir login é um erro crítico. Essas vulnerabilidades mostram que autenticação não é uma barreira suficiente quando falhas de segurança n8n permitem que usuários autenticados escapem do isolamento e alcancem o sistema host.
Como se proteger e versões corrigidas
A equipe do n8n já disponibilizou versões corrigidas que eliminam os vetores de ataque associados às duas falhas. Usuários devem atualizar imediatamente para versões seguras, como 1.123.17, 2.5.1 ou posteriores, dependendo da linha utilizada. Manter versões antigas expõe diretamente a infraestrutura a comprometimento total.
Para quem utiliza Docker, a atualização é simples e deve fazer parte da rotina de manutenção. Basta substituir a imagem antiga pela versão corrigida e recriar o container, garantindo que não haja volumes ou caches presos a builds vulneráveis. Após a atualização, é recomendável revisar logs, rotacionar credenciais e validar se não houve execução suspeita anterior.
Além disso, boas práticas como restringir o acesso administrativo, segmentar redes e monitorar atividades anômalas ajudam a mitigar impactos caso novas falhas sejam descobertas. Atualizar n8n não deve ser visto como uma ação pontual, mas como parte de uma estratégia contínua de segurança proativa.
Conclusão e o estado da segurança no n8n
As falhas CVE-2026-1470 e CVE-2026-0863 reforçam um desafio recorrente na segurança de aplicações modernas, isolar corretamente linguagens dinâmicas como JavaScript e Python é extremamente complexo. Pequenos detalhes de implementação, como escopos mal definidos ou permissões excessivas, podem resultar em RCE com impacto severo.
Para o ecossistema do n8n, o episódio serve como um alerta claro sobre a importância de atualizações rápidas e da conscientização dos usuários de self-hosting. A vulnerabilidade n8n exposta não é apenas um problema pontual, mas um lembrete de que automação poderosa exige controles de segurança igualmente robustos. Administradores e desenvolvedores que agirem agora, aplicando correções e revisando suas práticas, reduzem drasticamente o risco de incidentes graves no futuro.