O que está acontecendo com o n8n e por que isso importa
Uma vulnerabilidade crítica foi identificada no n8n, uma das plataformas de automação de workflows mais utilizadas por equipes de tecnologia, desenvolvedores e entusiastas de inteligência artificial em todo o mundo. A falha, catalogada como CVE-2026-25049, recebeu um score CVSS de 9.4 — o que a coloca no patamar mais elevado de severidade — e permite que um usuário autenticado execute comandos arbitrários diretamente no sistema operacional do servidor onde a plataforma está hospedada. Na prática, estamos falando de uma brecha que pode dar a um atacante o controle total da máquina, comprometendo não apenas os workflows automatizados, mas também todos os dados e integrações conectadas àquela instância.
O que torna essa situação ainda mais delicada é que a CVE-2026-25049 não surgiu do nada. Ela é, na verdade, um bypass da correção que foi implementada para uma vulnerabilidade anterior, a CVE-2025-68613, que já havia sido tratada em dezembro de 2025 e carregava um CVSS ainda mais alto, de 9.9. Isso significa que a primeira tentativa de resolver o problema não foi suficiente. Pesquisadores de segurança conseguiram encontrar caminhos para contornar as proteções adicionadas, expondo novamente os servidores que rodam o n8n a riscos sérios de execução remota de código.
Se você utiliza o n8n para automatizar processos, integrar ferramentas, conectar APIs ou orquestrar workflows de inteligência artificial, esse é o tipo de alerta que merece atenção imediata 🚨. Não se trata de uma falha teórica ou difícil de explorar — o vetor de ataque exige apenas que o invasor tenha credenciais válidas na plataforma, algo que pode ser obtido por meio de phishing, credenciais vazadas ou até mesmo por um colaborador interno mal-intencionado.
Dez pesquisadores, uma falha e um sandbox que não segurou
Um dos aspectos mais reveladores dessa história é a quantidade de profissionais de segurança que chegaram à mesma conclusão de forma independente. Nada menos que 10 pesquisadores foram reconhecidos pela descoberta da CVE-2026-25049, incluindo Fatih Çelik, que já havia sido responsável por reportar a falha original CVE-2025-68613. Além dele, nomes como Cris Staicu da Endor Labs, Eilon Cohen da Pillar Security e Sandeep Kamble da SecureLayer7 contribuíram para identificar o problema. Quando tantas pessoas encontram a mesma brecha, isso geralmente sinaliza que a superfície de ataque era ampla e relativamente acessível para quem sabe onde procurar.
Em uma análise técnica detalhada publicada por Çelik, o pesquisador explicou que as duas vulnerabilidades podem ser consideradas essencialmente a mesma falha, já que a segunda é apenas um bypass do fix inicial. O mecanismo de sandbox de expressões do n8n — que deveria isolar o código executado dentro dos workflows — apresentava brechas que permitiam ao atacante escapar desse ambiente controlado e alcançar o sistema operacional subjacente.
A SecureLayer7 detalhou o cenário de ataque de uma forma bastante clara: um atacante cria um workflow com um webhook publicamente acessível, sem autenticação habilitada. Bastava adicionar uma única linha de JavaScript utilizando sintaxe de destructuring para que o workflow passasse a executar comandos no nível do sistema. Uma vez exposto, qualquer pessoa na internet poderia acionar esse webhook e rodar comandos remotamente no servidor. Simples assim — e assustadoramente eficiente.
Como a execução remota de código funciona nessa vulnerabilidade
Para entender o impacto real da CVE-2026-25049, é importante compreender o que significa execução remota de código, ou RCE na sigla em inglês. Quando uma plataforma apresenta esse tipo de falha, um atacante consegue enviar instruções que são interpretadas e executadas pelo servidor como se fossem comandos legítimos do sistema operacional. No caso do n8n, a vulnerabilidade está na forma como a plataforma avalia expressões dentro dos parâmetros de workflow. Um usuário autenticado com permissão para criar ou modificar workflows pode manipular expressões elaboradas nesses parâmetros para disparar a execução não intencional de comandos no host que roda o n8n.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
A explicação técnica oferecida por Cris Staicu, da Endor Labs, revela uma nuance fascinante. O problema decorre de um descompasso entre o sistema de tipos do TypeScript em tempo de compilação e o comportamento real do JavaScript em tempo de execução. Enquanto o TypeScript impõe que determinada propriedade deveria ser uma string durante a compilação, essa garantia é limitada aos valores presentes no código naquele momento. O TypeScript simplesmente não consegue aplicar essas verificações de tipo em valores produzidos por atacantes em runtime. Quando os invasores criam expressões maliciosas em tempo de execução, conseguem passar valores que não são strings — como objetos, arrays ou symbols — que contornam completamente a verificação de sanitização.
O problema é especialmente grave porque o n8n é frequentemente implantado com permissões elevadas no servidor, justamente por precisar acessar diferentes serviços, bancos de dados e APIs externas para realizar as automações. Isso significa que, ao explorar essa vulnerabilidade, o atacante herda essas permissões e pode ler arquivos sensíveis, instalar backdoors, exfiltrar dados de integrações conectadas como bancos de dados, plataformas de CRM, serviços de e-mail e até mesmo se mover lateralmente pela rede interna da organização.
O perigo amplificado pelos webhooks
A gravidade da CVE-2026-25049 aumenta consideravelmente quando combinada com a funcionalidade de webhooks do n8n. Tanto a SecureLayer7 quanto a Pillar Security destacaram esse ponto com ênfase. O cenário funciona assim:
- O atacante cria um workflow que utiliza um webhook público, sem nenhuma camada de autenticação
- Dentro desse workflow, um payload de execução remota de código é adicionado a um nó específico
- Quando o workflow é ativado, o webhook se torna acessível publicamente pela internet
- Qualquer pessoa que acesse a URL do webhook aciona a execução dos comandos maliciosos no servidor
Eilon Cohen, da Pillar Security, resumiu a situação de forma bastante direta: o ataque não requer nada de especial — se você pode criar um workflow, você pode ser dono do servidor. O relatório da Pillar detalhou que a exploração bem-sucedida permite roubar chaves de API, credenciais de provedores de nuvem, senhas de bancos de dados, tokens OAuth e acessar o sistema de arquivos e sistemas internos. A partir daí, o atacante pode pivotar para contas de nuvem conectadas e até mesmo sequestrar workflows de inteligência artificial.
Considerando que muitas organizações utilizam o n8n como peça central de suas automações, inclusive para orquestrar fluxos envolvendo modelos de linguagem (LLMs) e agentes de IA, o comprometimento da plataforma pode ter consequências que vão muito além do servidor em si. Estamos falando de um potencial efeito dominó que pode afetar toda a infraestrutura digital de uma empresa.
Versões afetadas e como atualizar
A equipe de desenvolvimento do n8n disponibilizou correções para a CVE-2026-25049 nas seguintes versões:
- Versões anteriores à 1.123.17 estão vulneráveis — a correção está na versão 1.123.17
- Versões anteriores à 2.5.2 estão vulneráveis — a correção está na versão 2.5.2
O passo mais urgente para qualquer pessoa ou organização que mantenha uma instância do n8n em produção é atualizar imediatamente para a versão mais recente da plataforma. Adiar essa atualização é assumir um risco desnecessário, especialmente considerando que os detalhes técnicos da vulnerabilidade já estão circulando em comunidades de segurança e é questão de tempo até que ferramentas automatizadas de exploração sejam desenvolvidas e disseminadas.
Se a atualização imediata não for viável, os mantenedores do n8n recomendam as seguintes medidas de mitigação:
- Restringir permissões de criação e edição de workflows apenas a usuários totalmente confiáveis
- Implantar o n8n em um ambiente endurecido, com privilégios restritos de sistema operacional e acesso de rede limitado
Não é só a CVE-2026-25049 — outras 11 falhas foram corrigidas
Como se a CVE-2026-25049 não fosse suficiente, o n8n também divulgou alertas de segurança para outras 11 vulnerabilidades, sendo cinco delas classificadas como críticas. A lista completa mostra que a plataforma passou por uma auditoria de segurança bastante intensa, revelando problemas em diferentes componentes:
- CVE-2026-21893 (CVSS 9.4) — Injeção de comandos que permite a usuários autenticados com permissões administrativas executar comandos arbitrários no host do n8n, sob condições específicas. Corrigida na versão 1.120.3.
- CVE-2026-25051 (CVSS 8.5) — Vulnerabilidade de cross-site scripting (XSS) no tratamento de respostas de webhook e endpoints HTTP relacionados, podendo levar a sequestro de sessão e tomada de conta. Corrigida na versão 1.123.2.
- CVE-2026-25052 (CVSS 9.4) — Vulnerabilidade de Time-of-check Time-of-use (TOCTOU) nos controles de acesso a arquivos, permitindo leitura de arquivos sensíveis do host e potencial tomada completa de conta. Corrigida nas versões 2.5.0 e 1.123.18.
- CVE-2026-25053 (CVSS 9.4) — Injeção de comando no nó Git, permitindo execução de comandos arbitrários ou leitura de arquivos no host. Corrigida nas versões 2.5.0 e 1.123.10.
- CVE-2026-25054 (CVSS 8.5) — XSS armazenado em componente de renderização de markdown, incluindo sticky notes de workflow. Corrigida nas versões 2.2.1 e 1.123.9.
- CVE-2026-25055 (CVSS 7.1) — Travessia de caminho (path traversal) que permite escrita de arquivos em locais não intencionais via nó SSH. Corrigida nas versões 2.4.0 e 1.123.12.
- CVE-2026-25056 (CVSS 9.4) — Escrita arbitrária de arquivos no sistema de arquivos do servidor n8n via modo SQL Query do nó Merge, potencialmente levando a execução remota de código. Corrigida nas versões 2.4.0 e 1.118.0.
- CVE-2026-25115 (CVSS 9.4) — Escape do sandbox Python no nó de código Python, permitindo execução de código fora do limite de segurança pretendido quando Task Runners e Python estão habilitados. Corrigida na versão 2.4.8.
- CVE-2026-25631 (CVSS 5.3) — Validação inadequada de domínio de credenciais no nó HTTP Request, permitindo envio de requisições com credenciais a domínios não intencionais. Corrigida na versão 1.121.0.
- CVE-2025-61917 (CVSS 7.7) — Alocação insegura de buffer que pode expor informações sensíveis quando Task Runners estão habilitados. Corrigida na versão 1.114.3.
- CVE-2025-62726 (CVSS 8.8) — Execução remota de código no componente Git Node quando um repositório remoto contendo um hook de pre-commit é clonado. Corrigida na versão 1.113.0.
Essa lista extensa reforça que o n8n estava com uma superfície de ataque considerável. A boa notícia é que todas essas falhas já possuem patches disponíveis, mas a mensagem é clara: manter a plataforma atualizada não é opcional.
O que fazer agora para proteger sua instância
Além da atualização em si, existem boas práticas que ajudam a reduzir a superfície de ataque e que deveriam ser adotadas independentemente dessa vulnerabilidade específica. Limitar o acesso à interface do n8n apenas a redes internas ou VPNs confiáveis, por exemplo, reduz drasticamente a possibilidade de um atacante externo explorar a falha. Implementar autenticação multifator para todos os usuários da plataforma adiciona uma camada extra de proteção que dificulta o uso de credenciais comprometidas.
Revisar periodicamente os usuários cadastrados e remover contas que não são mais necessárias também é uma medida simples que faz diferença. Para quem roda o n8n em containers Docker, garantir que o container opere com o mínimo de privilégios possível e com um sistema de arquivos somente leitura onde for viável pode limitar o impacto mesmo em caso de execução remota bem-sucedida.
Outro ponto fundamental é revisar os logs de acesso da plataforma para identificar qualquer atividade suspeita que possa indicar uma tentativa de exploração anterior à aplicação do patch. Verifique especialmente workflows que utilizam webhooks públicos sem autenticação, pois esses são os vetores mais diretos para exploração da CVE-2026-25049.
A Endor Labs encerrou sua análise com uma reflexão técnica que vale para qualquer projeto de software: essa vulnerabilidade demonstra por que múltiplas camadas de validação são cruciais. Mesmo que uma camada, como os tipos do TypeScript, pareça robusta, verificações adicionais em runtime são necessárias ao processar entradas não confiáveis. O recado é prestar atenção especial às funções de sanitização durante revisões de código, buscando suposições sobre tipos de entrada que não são reforçadas em tempo de execução.
Lições para quem trabalha com automação e IA
Esse episódio também serve como um lembrete importante sobre a responsabilidade de manter plataformas self-hosted atualizadas e monitoradas. O pesquisador Amit Genkin, da Upwind, colocou a questão em perspectiva ao afirmar que a flexibilidade e o poder do n8n são exatamente o que tornam esses problemas de alto impacto. Quando motores de automação têm permissão para influenciar diretamente a execução e o acesso a arquivos, pequenos erros rapidamente se transformam em comprometimento total do ambiente.
O n8n é uma ferramenta poderosa e extremamente versátil, mas justamente por lidar com integrações sensíveis e ter acesso a múltiplos serviços, qualquer brecha de segurança nele pode ter um efeito cascata significativo. Acompanhar os canais oficiais de comunicação do projeto, assinar alertas de segurança e participar da comunidade são formas de se manter informado sobre novas ameaças.
Para quem está construindo workflows que envolvem modelos de linguagem, agentes autônomos ou qualquer tipo de sistema de IA, esse caso é um lembrete de que a segurança da infraestrutura de orquestração é tão importante quanto a segurança dos próprios modelos. De nada adianta investir em guardrails para seus LLMs se a plataforma que os conecta e gerencia está vulnerável a uma tomada completa por um atacante.
A CVE-2026-25049 é séria, mas com as medidas corretas aplicadas rapidamente, é possível continuar aproveitando tudo o que o n8n oferece sem colocar sua infraestrutura em risco 🔐. Atualize suas instâncias, revise suas configurações de segurança e mantenha seus workflows protegidos.
