CVE-2026-25049 afeta a avaliação de expressões do n8n e permite que usuários autenticados com permissão sobre fluxos escapem da sandbox e acionem comandos no host, com risco ampliado quando webhooks públicos são usados.
| Componente | Plataforma de automação n8n, especialmente a avaliação de expressões em parâmetros de workflows, webhooks públicos e nós capazes de interagir com sistema de arquivos, Git, SQL, Python e requisições HTTP. |
| Vetor | Usuário autenticado com permissão para criar ou modificar workflows pode inserir expressões manipuladas em parâmetros do fluxo; quando combinado com webhook público sem autenticação, o acionamento do fluxo pode ficar exposto a qualquer origem na internet. |
| Impacto | Execução de comandos de sistema no host do n8n, leitura ou escrita indevida de arquivos, acesso a credenciais e tokens configurados na instância, XSS de mesma origem em fluxos manipulados e, em condições específicas, execução de código fora de limites de sandbox. |
| Prioridade | Atualizar instâncias do n8n para versões corrigidas, restringir criação e edição de workflows a usuários totalmente confiáveis, endurecer privilégios do processo do n8n e limitar exposição de webhooks. |
| CVE principal | CVE-2026-25049, CVSS 9.4, descrita como bypass de correção anterior relacionada à CVE-2025-68613, CVSS 9.9. |
| Vulnerabilidades correlatas | Alertas adicionais incluem CVE-2026-21893, CVE-2026-25051, CVE-2026-25052, CVE-2026-25053, CVE-2026-25054, CVE-2026-25055, CVE-2026-25056, CVE-2026-25115, CVE-2026-25631, CVE-2025-61917 e CVE-2025-62726. |
Uma falha crítica no n8n, identificada como CVE-2026-25049, permite execução de comandos de sistema por meio de workflows maliciosos criados ou modificados por usuários autenticados. O problema está na avaliação de expressões da plataforma e decorre de sanitização insuficiente, capaz de contornar salvaguardas introduzidas após a correção da CVE-2025-68613. A condição central não é acesso anônimo direto ao painel administrativo, mas a presença de uma conta com permissão para criar ou alterar workflows, o que torna o controle de permissões dentro da instância um fator decisivo de exposição.
O risco cresce quando a funcionalidade de webhook é combinada com um workflow manipulado. Nesse cenário, um operador com acesso à criação do fluxo pode configurar um webhook público sem autenticação e inserir uma expressão especialmente criada em um nó do workflow. Depois que o fluxo é ativado, o endpoint público passa a acionar a lógica vulnerável. O resultado técnico descrito é a possibilidade de escapar do mecanismo de sandbox de expressões do n8n e alcançar execução de comandos no sistema operacional do host que executa a plataforma.
A falha tem gravidade elevada porque o n8n normalmente concentra integrações com APIs, bancos de dados, contas de nuvem, ferramentas internas e automações operacionais. Em uma instância com credenciais armazenadas e conectores sensíveis, execução no host não é apenas um problema de disponibilidade: ela pode permitir acesso a arquivos locais, leitura de segredos, uso indevido de tokens OAuth, chaves de provedores de nuvem, senhas de banco de dados e credenciais de serviços conectados. Esses impactos dependem da configuração real da instância, dos privilégios do processo do n8n e do escopo das credenciais disponíveis ao workflow.
A causa técnica descrita envolve uma incompatibilidade entre garantias de tipo em TypeScript durante compilação e o comportamento real do JavaScript em tempo de execução. A validação assumia que determinados valores usados por funções de sanitização seriam strings, mas entradas produzidas em tempo de execução por um usuário malicioso podem assumir formas diferentes, como objetos, arrays ou símbolos. Quando a checagem de segurança depende de uma premissa de tipo que não é reforçada no runtime, a expressão manipulada consegue atravessar a validação e atingir caminhos de execução que deveriam permanecer bloqueados.
A CVE-2026-25049 foi caracterizada como um bypass da correção anterior para CVE-2025-68613. Isso é relevante para engenharia defensiva porque indica que a primeira mitigação não eliminou toda a classe de bug, mas fechou um caminho específico de abuso. A nova falha explora brechas remanescentes no mesmo limite lógico: a fronteira entre expressões configuráveis pelo usuário e execução segura dentro do ambiente controlado do n8n. Para revisão de código, o ponto central é tratar parâmetros de workflow como entrada não confiável, mesmo quando o usuário está autenticado.
O abuso não exige publicação de um exploit público no ambiente da vítima. A precondição descrita é permissão para criação ou edição de workflows. A partir daí, o invasor interno, uma conta comprometida ou um usuário excessivamente privilegiado pode criar um fluxo com webhook exposto e inserir uma expressão maliciosa em parâmetros do workflow. O webhook funciona como ponto de disparo remoto. Se o endpoint estiver acessível pela internet e sem autenticação, terceiros podem acionar a cadeia, embora a criação inicial do workflow continue dependendo da permissão autenticada dentro do n8n.
Além da falha principal, o conjunto de alertas de segurança do n8n cobre outras superfícies críticas. CVE-2026-21893 trata de injeção de comando para usuários administrativos em condições específicas. CVE-2026-25053 envolve o nó Git e permite execução de comandos ou leitura de arquivos no host para usuários com permissão de workflow. CVE-2026-25056 afeta o modo SQL Query do nó Merge e pode permitir escrita arbitrária no sistema de arquivos do servidor. CVE-2026-25115 envolve escape da sandbox Python quando Task Runners, Python e Code Node estão habilitados. Essas falhas mostram que a superfície de risco não está restrita a um único nó, mas ao modelo de automação que combina código, credenciais e conectores com alto grau de flexibilidade.
A superfície mais sensível é formada por instâncias nas quais usuários não totalmente confiáveis conseguem criar, importar, editar ou ativar workflows. Ambientes multiusuário, times que concedem permissões amplas para automação, instâncias conectadas a contas de nuvem e servidores que expõem webhooks diretamente à internet devem ser avaliados com prioridade. A exploração descrita exige acesso autenticado para preparar o workflow, mas a etapa de acionamento pode atravessar a fronteira externa quando o fluxo fica vinculado a um webhook público sem autenticação.
O impacto também varia conforme a forma de execução do n8n. Se o processo roda com permissões amplas no sistema operacional, a execução de comandos ou a leitura e escrita de arquivos podem alcançar diretórios sensíveis, variáveis de ambiente, arquivos de configuração e credenciais persistidas. Se a instância possui acesso de rede a bancos internos, APIs administrativas ou metadados de nuvem, a execução no host pode se transformar em abuso de integrações. Por isso, a contenção precisa considerar privilégios locais, segmentação de rede, escopo de credenciais e inventário de workflows ativos, não apenas a versão do aplicativo.
Os alertas adicionais ampliam a lista de componentes que devem entrar na revisão. XSS armazenado foi descrito em respostas de webhook, endpoints HTTP relacionados e renderização de markdown usada na interface, incluindo notas adesivas de workflow. Há também path traversal no uso de arquivos enviados transferidos via nó SSH, validação indevida de domínio de credenciais no nó HTTP Request e alocação insegura de buffer em condições com Task Runners e Code Node habilitados. Cada caso possui versões corrigidas próprias, então a atualização deve mirar ramos suportados e não uma correção pontual isolada.
- Instâncias de n8n com usuários autorizados a criar ou modificar workflows sem revisão operacional rígida.
- Webhooks públicos sem autenticação associados a workflows ativados e capazes de disparar nós com expressões manipuladas.
- Ambientes em que o processo do n8n possui privilégios amplos no sistema operacional ou acesso de rede a serviços internos.
- Configurações com Task Runners, Code Node e Python habilitados, especialmente quando combinadas com automações que manipulam dados sensíveis.
- Nós Git, Merge em modo SQL Query, HTTP Request, SSH, Python Code e componentes de markdown citados nos alertas correlatos.
A investigação deve começar pelo inventário de workflows criados ou alterados recentemente por contas com permissão elevada. O foco é identificar fluxos com webhooks públicos, ausência de autenticação no endpoint e parâmetros que contenham expressões incomuns, especialmente em nós capazes de interagir com sistema operacional, arquivos, Git, SQL, Python, HTTP ou transferências remotas. Como o abuso parte de uma ação autenticada, logs de auditoria de criação, edição, ativação e importação de workflows são tão importantes quanto logs de rede.
No host do n8n, a defesa deve procurar processos filhos inesperados originados do serviço da aplicação, leituras anormais de arquivos sensíveis, criação de arquivos fora de diretórios esperados, acesso a repositórios remotos por nós Git e conexões de saída que não correspondam ao comportamento normal dos workflows conhecidos. Em ambientes conteinerizados, a telemetria deve incluir chamadas de processo dentro do contêiner, montagens de volume acessíveis, variáveis de ambiente expostas ao runtime e tentativas de alcançar serviços internos a partir do namespace de rede do n8n.
Na camada de identidade e aplicação, sinais importantes incluem edição de workflows por contas raramente usadas, ativação de webhooks logo após alteração de parâmetros, mudanças em nós que usam credenciais privilegiadas, falhas de execução com mensagens de tipo ou sandbox, além de acessos ao endpoint de webhook a partir de origens externas inesperadas. Quando houver suspeita de exploração, a revisão de credenciais deve abranger tokens OAuth, chaves de API, senhas de banco de dados, chaves de provedores de nuvem e segredos usados por workflows afetados.
- Criação, importação, edição ou ativação recente de workflows por contas que não costumam administrar automações sensíveis.
- Webhooks públicos sem autenticação associados a fluxos alterados recentemente ou expostos antes de revisão.
- Processos filhos incomuns iniciados pelo serviço do n8n, principalmente quando não correspondem ao comportamento documentado do workflow.
- Leitura de arquivos de configuração, credenciais locais, diretórios de trabalho, volumes montados ou arquivos fora do caminho esperado.
- Uso inesperado de credenciais em nós HTTP Request, Git, SSH, banco de dados, provedores de nuvem ou automações de IA.
- Conexões de saída para destinos não previstos após acionamento de webhook ou execução de workflow.
A resposta principal é atualizar o n8n para versões que contenham as correções publicadas para a falha principal e para os alertas correlatos. Como a lista envolve vários CVEs e diferentes componentes, a organização deve validar o ramo em uso, aplicar a versão corrigida correspondente e confirmar que instâncias secundárias, ambientes de teste, workers e imagens de contêiner foram atualizados. Atualizar apenas a instância principal enquanto runners ou implantações paralelas permanecem antigos mantém parte da superfície explorável.
Quando a atualização imediata não for possível, a redução de risco precisa focar nas precondições descritas. A criação e edição de workflows deve ficar restrita a usuários totalmente confiáveis. Webhooks públicos devem ser revisados, desativados quando desnecessários e protegidos por autenticação ou controles equivalentes quando o desenho do fluxo permitir. O processo do n8n deve rodar com privilégios mínimos no sistema operacional, sem acesso amplo a diretórios sensíveis, sem credenciais além do necessário e com conectividade de rede limitada aos serviços estritamente usados pelos workflows.
A validação pós-correção deve incluir revisão de workflows existentes, rotação de segredos potencialmente expostos e busca por alterações não autorizadas. Em instâncias nas quais contas com permissão de workflow eram compartilhadas, pouco auditadas ou integradas a SSO sem revisão de grupos, a correção do binário não resolve o risco operacional de abuso por permissões excessivas. O modelo seguro para n8n exige separação entre quem cria automações, quem aprova credenciais sensíveis e quem pública webhooks acessíveis externamente.
Os alertas adicionais exigem tratamento específico. CVE-2026-25052 foi corrigida nas versões 2.5.0 e 1.123.18. CVE-2026-25053 foi corrigida nas versões 2.5.0 e 1.123.10. CVE-2026-25056 foi corrigida nas versões 2.4.0 e 1.118.0. CVE-2026-25115 foi corrigida na versão 2.4.8. CVE-2026-25051 foi corrigida na versão 1.123.2, CVE-2026-25054 nas versões 2.2.1 e 1.123.9, CVE-2026-25055 nas versões 2.4.0 e 1.123.12, CVE-2026-25631 na versão 1.121.0, CVE-2025-61917 na versão 1.114.3 e CVE-2025-62726 na versão 1.113.0. Essas referências devem orientar a checagem de conformidade por versão, mas a postura recomendada é atualizar para a versão mais recente disponível no ramo suportado pela operação.
- Atualizar todas as instâncias, workers, ambientes de teste e imagens de contêiner do n8n para versões corrigidas.
- Remover permissões de criação e edição de workflow de usuários que não sejam totalmente confiáveis e revisar grupos integrados ao provedor de identidade.
- Inventariar webhooks públicos, exigir autenticação quando possível e desativar endpoints que não tenham dono operacional claro.
- Executar o n8n com privilégio mínimo, sistema de arquivos restrito, segredos segregados e acesso de rede limitado aos destinos necessários.
- Revisar workflows criados ou modificados antes da atualização e investigar mudanças em nós Git, HTTP Request, SSH, Merge, Python Code e Code Node.
- Rotacionar credenciais usadas por workflows suspeitos ou expostos, incluindo tokens OAuth, chaves de API, credenciais de banco de dados e chaves de nuvem.
- Monitorar processos filhos, acessos a arquivos sensíveis, conexões de saída inesperadas e acionamentos de webhooks após alterações de workflow.
0 Comentários