Alerta crítico: duas falhas em n8n permitem execução remota de código e podem comprometer toda a sua infraestrutura

Pesquisadores de segurança identificaram duas falhas graves na plataforma de automação de fluxos n8n que permitem a execução remota de código em instâncias vulneráveis. As fraquezas foram detectadas pela equipe de pesquisa de JFrog e, segundo a avaliação pública, uma delas atinge uma pontuação quase máxima de severidade, pelo que qualquer implantação sem adesivo corre risco elevado de comprometimento.

Os problemas reportados são vulnerabilidades de tipo eval injection, ou seja, vetores que permitem que código dinâmico enviado por um usuário autenticado seja interpretado e executado pelo ambiente de n8n. Em um caso a injeção compromete o mecanismo que n8n emprega para avaliar expressões em JavaScript, sorteando as restrições do sandbox e permitindo executar comandos com o contexto do processo principal. No outro, a fraqueza afeta o componente encarregado de executar tarefas em Python (python-task-executor), possibilitando que instruções em Python arbitrárias sejam executadas sobre o sistema subjacente.

As duas falhas foram registradas no catálogo de vulnerabilidades do NIST com os identificadores CVE-2026-1470(com uma avaliação muito elevada) e CVE-2026-0863. JFrog publica uma análise técnica detalhada onde explicam como foi possível realizar a evasão do sandbox e alcançar execução remota; esse relatório é uma leitura recomendável para quem quiser compreender o vetor de ataque e a cadeia de exploração: Análise de JFrog.

O potencial impacto é amplo porque n8n é usado para automatizar tarefas que muitas vezes ligam serviços críticos: desde chaves e APIs de modelos de linguagem até dados comerciais e sistemas de gestão de identidades. Se um atacante conseguir executar código na instância de n8n pode, na prática, obter acesso transversal a esses recursos automatizados e a credenciais que estejam armazenadas ou que a própria plataforma possa usar, o que multiplicaria as consequências do incidente.

Um fator importante nesta história é o modo de execução de n8n. Na documentação oficial, adverte-se que operar em modo interno (internal) Para ambientes de produção não oferece o mesmo grau de isolamento que separar n8n do executor de tarefas (external mode). Quando ambos os componentes compartilham processos ou permissões, uma vulnerabilidade que consegue escapar do sandbox pode alcançar o nó principal e, daí, ao resto da infraestrutura. Você pode ver a explicação do n8n sobre a configuração de executores em sua documentação, e a descrição do sistema de expressões em as páginas dedicadas a expressões.

Esses achados também reabrem o debate sobre a dificuldade de conter linguagens dinâmicas como JavaScript e Python em ambientes restritos. Os pesquisadores apontam que, mesmo com múltiplos filtros e controles baseados na análise sintáctica ou listas de proibição, sempre existem construções da linguagem ou comportamentos do intérprete que podem ser aproveitados para contornar as defesas. Na verdade, há algumas semanas, outra vulnerabilidade de máxima gravidade em n8n —conhecida como Ni8mare e registrada sob CVE-2026-21858 — mostrou o fácil que pode ser para um atacante remoto ganhar controle total de uma instância, o que reforça a urgência de aplicar correções e boas práticas.

Diante desta situação, a recomendação imediata é aplicar as versões que corrigem as falhas. Para CVE-2026-1470 foram publicados adesivos nos ramos indicados pelos mantenedores; as versões que contêm a correção são 1.123.17, 2.4.5 e 2.5.1. Para CVE-2026-0863, as edições corrigidas são 1.123.14, 2.3.5 e 2.4.2. Atualizar estas versões deve ser a primeira ação de mitigação.

Além de atualizar, convém rever a arquitetura de implantação: migrar para execuções separadas entre o servidor de n8n e os runners de tarefas, restringir o acesso administrativo à plataforma, rotar as credenciais e chaves armazenadas por n8n e auditar os registros em busca de atividade suspeita. Se houver a suspeita de que uma instância poderia ter sido comprometida, o prudente é assumir que segredos e tokens poderiam estar expostos e proceder à sua revogação e renovação.

Em setores onde n8n orquestra cadeias que incluem serviços críticos ou dados sensíveis, a exposição de uma plataforma de automação é especialmente perigosa porque permite movimentos laterais automatizados e acessos a recursos que normalmente ficariam fora do alcance de um intruso. Por isso, além de aplicar os adesivos, é aconselhável rever políticas de segurança, práticas de segregação de tarefas e controles de mínimos privilégios nas integrações que conecta n8n.

Se você gerir instâncias de n8n, consulte as fontes oficiais para verificar as versões disponíveis e as notas de segurança. O relatório técnico do JFrog está disponível em seu blog de pesquisa ( JFrog Research) e os detalhes dos identificadores públicos podem ser encontrados na base de dados de NVD ( CVE-2026-1470, CVE-2026-0863, CVE-2026-21858). Também é útil rever a documentação oficial do n8n sobre expressões e runners para entender melhor as diferenças operacionais entre modos e como melhorar o isolamento: Expressões em n8n e Configuração do task runners.

Em suma, estas vulnerabilidades sublinham que a complexidade das linguagens interpretadas e a conveniência das plataformas de automação requerem uma gestão cuidadosa de riscos. Actualizar, isolar processos e revisar permissões não são apenas recomendações: neste contexto, são medidas imprescindíveis para evitar que uma ferramenta pensada para facilitar o trabalho se torne a porta de entrada para um ataque a toda a organização.