Alerta de segurança: CVE-2026-25049 em n8n permite escapar do sandbox e tomar controle do servidor

Se você gerir as máquinas com n8n — a plataforma de código aberto que permite encadear aplicações e processos através do workflows — convém que preste atenção: várias pesquisas recentes descobriram falhas graves no isolado que executa o código do lado do servidor, o que permitiu a atacantes autenticados escapar do sandbox e executar comandos arbitrários no host.

A fraqueza, registrada coletivamente como CVE‐2026‐25049, afeta a forma como n8n sanitiza e avalia fragmentos de JavaScript que podem incluir os usuários dentro dos workflows. Equipamentos de investigação independentes — entre eles Pillar Security, Endor Labs e SecureLayer7 — mostraram como, com permissões para criar ou modificar workflows, um atacante pode aproveitar essas falhas para tomar controle total do servidor onde corre n8n.

Para entender por que isso é sério basta pensar no que n8n armazena e com que costuma se conectar: credenciais de API, tokens OAuth, chaves e fluxos que interagem com serviços em nuvem ou modelos de IA. De acordo com as descrições técnicas, o exploit permite a partir de executar instruções na máquina vítima até ler arquivos sensíveis, extrair credenciais e pivotar para contas e recursos conectados, inclusive seqüestrar fluxos de IA interceptando ou alterando prompts e respostas.

No coração do problema está a estratégia de "sandboxing" baseada na análise da sintaxe do código (AST). Os investigadores explicam que as verificações seriam determinadas restrições tipadas (reflexas nos tipos de TypeScript), mas essas garantias não se aplicavam em tempo de execução, o que derivou numa condição de confusão de tipos que permite contornar a limpeza do código. Em termos práticos, isto abre a porta para construir expressões que, ao se avaliar no servidor, recuperam objetos globais de Node.js ou usam o construtor Function para executar código arbitrário.

A falha não apareceu do nada: a equipe de pesquisa de Pillar Security relatou uma cadeia de evasão em 21 de dezembro de 2025 e n8n implementou uma correção inicial pouco depois, mas os pesquisadores demonstraram que aquela solução não fechou todos os vetores. Após análise adicional, foram encontrados bypasses alternativos e os desenvolvedores de n8n confirmaram novas evasões antes de publicar adesivos posteriores. As análises e testes de conceito completos estão acessíveis nos relatórios técnicos de Pillar Security, Endor Labs e SecureLayer7.

n8n foi publicando adesivos e mitigações; é fundamental rever a advisoria anterior relacionada e a Nota de segurança com atenuação temporária para confirmar quais versões contêm as correções definitivas. Além disso, os equipamentos que não possam atualizar imediatamente devem aplicar as medidas provisórias que sugerem o projeto e restringir quem pode criar ou editar workflows dentro da instalação.

A ameaça é maior em implantaçãos multi-tenant: se um atacante conseguir acessar serviços internos do cluster, pode potencialmente escalar e acessar dados de outros inquilinos. Além disso, a atenção que despertou n8n na comunidade maliciosa já se reflete em varreduras massivas e sondagens direcionadas a instâncias expostas; por exemplo, GreyNoise tem documentado atividade de sondagem contra endpoints vulneráveis em campanhas recentes, o que mostra interesse por pontos de entrada que facilitem um controle posterior dos sistemas comprometidos ( relatório de GreyNoise).

Se você administra n8n, a prioridade imediata é verificar se a sua instalação está em uma versão alterada e, se não for assim, atualizar quanto antes. As equipes de segurança e operações devem também rodar a chave de cifra de n8n e todas as credenciais armazenadas na plataforma, revisar workflows em busca de expressões suspeitas e limitar a capacidade de criação/edição de workflows a usuários plenamente de confiança. No repositório de segurança de n8n você encontrará instruções sobre as mitigações temporárias para aqueles que não possam aplicar o adesivo imediatamente: mitigação temporária no GitHub.

Do ponto de vista técnico, a lição é clara: permitir que usuários definam fragmentos de código executável no servidor sempre exige um sandbox rígido e verificações em tempo de execução, não apenas nos tipos ou na superfície do código. Os erros sutis na lógica de sanitização, especialmente em ambientes que usam tipado estático como ajuda para o desenvolvedor, podem ser aproveitados se a implementação do runtime não impõe as mesmas garantias.

Por agora, não há relatos públicos confirmados de ataques em produção explorando essa vulnerabilidade concreta, mas a visibilidade do problema e os testes de conceito publicados por pesquisadores aumentam o risco. Manter as plataformas atualizadas, endurecer permissões e rotar segredos são medidas que reduzem exposição e tempo de resposta a possíveis incidentes.

Se você precisa consultar as pesquisas originais, os relatórios técnicos e testes de conceito estão disponíveis nas publicações de Pillar Security, Endor Labs e SecureLayer7, e as informações oficiais e mitigações são publicadas no seu repositório do GitHub ( advisories de n8n).

Conclusão: Se a sua organização depende de n8n, age agora: confirma a versão, aplica adesivos, rota chaves e reduza quem pode editar workflows. A combinação de execução de código no servidor e uma sanitização deficiente converte uma licença aparentemente benigno —criar ou editar um workflow — numa porta direta ao sistema.