Os avisos publicados em 22 de abril descrevem duas falhas críticas, quatro de gravidade alta e seis moderadas. Algumas exigem permissão para editar workflows, outras dependem de campos alimentados por entradas externas ou de endpoints acessíveis sem autenticação. Na sua instância, compare a versão instalada com a linha correspondente de cada ficha e confira a configuração do recurso afetado.
Aplicativon8n
Data do compilado
Vulnerabilidades12
As pontuações seguem o CVSS 4.0 dos avisos oficiais. As faixas de versões preservam os campos da API, inclusive quando a descrição do comunicado cita versões diferentes. A indicação de correção informa sua disponibilidade no projeto. Você precisa confirmar a atualização da instância. As medidas temporárias descritas nas fichas não substituem essa atualização.
Gravidade críticaCVSS: 9,4/10Correção disponível
Node XML permite alterar protótipos e encadear execução de código
Um atacante autenticado com permissão para criar ou editar workflows pode usar o Node XML para alterar propriedades do protótipo global dos objetos JavaScript. Outros Nodes que utilizem essas propriedades podem completar um encadeamento capaz de executar código remotamente. O efeito ultrapassa o resultado da conversão XML, porque a alteração atinge propriedades compartilhadas no processo.
Casos de uso afetados
Você permite que outros integrantes construam workflows com o Node XML. Um editor mal-intencionado pode combinar esse componente com outros Nodes para explorar a alteração global de protótipos.
Confira na sua instância
Localize os workflows que contêm o Node XML e confira suas permissões de criação e edição. Compare a versão em execução com a correção da sua linha. Caso você exclua o componente temporariamente, verifique se NODES_EXCLUDE inclui n8n-nodes-base.xml e se o Node ficou indisponível após aplicar a configuração. Revise também os workflows existentes que dependem dele.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 2.18.x
< 2.18.1
>= 2.18.1
n8n 2.17.x
< 2.17.4
>= 2.17.4
n8n 1.123.x
< 1.123.32
>= 1.123.32
A execução remota depende da combinação com outros Nodes que aproveitem a alteração de protótipos. O comunicado não identifica esses componentes. A exclusão do Node XML e a restrição das permissões de edição são medidas temporárias indicadas.
Gravidade críticaCVSS: 9,4/10Correção disponível
XML recebido pelo webhook permite execução de código com o Node Git
O processamento de corpos XML nos webhooks usa a biblioteca xml2js, cuja falha permite alterar o protótipo dos objetos JavaScript por um conteúdo preparado para esse fim. Um atacante autenticado com permissão para criar ou modificar workflows pode combinar essa alteração com operações SSH do Node Git e executar código no servidor do n8n. A entrada vulnerável está no processamento do webhook, independentemente do uso do Node XML.
Casos de uso afetados
Você mantém workflows que recebem corpos XML por webhook e permite que outros integrantes editem automações com o Node Git. Um editor mal-intencionado pode montar o encadeamento entre o processamento XML e as operações SSH desse Node.
Confira na sua instância
Confira quais webhooks recebem XML e localize os workflows que usam operações SSH no Node Git. Revise as permissões de edição desses workflows e a versão do n8n que processa as requisições. Você precisa examinar o tratamento do corpo pelo webhook, pois procurar apenas pelo Node XML não identifica este mecanismo.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 1.123.x
< 1.123.32
>= 1.123.32
n8n 2.18.x
< 2.18.1
>= 2.18.1
n8n 2.17.x
< 2.17.4
>= 2.17.4
O comunicado exige autenticação e permissão para criar ou alterar workflows na exploração descrita. A medida temporária indicada é limitar essas permissões a integrantes de confiança. Excluir o Node XML não corresponde à mitigação documentada para o parser XML do webhook.
Gravidade altaCVSS: 8,8/10Correção disponível
Nome de cliente MCP permite executar JavaScript pela notificação de revogação
Um atacante sem autenticação pode cadastrar um cliente OAuth do MCP com conteúdo malicioso em client_name. A exploração depende de uma sequência de interações: você autoriza o cliente, outro integrante revoga o acesso e a interface exibe uma notificação com o conteúdo injetado. Ao clicar no link dessa notificação, você pode executar JavaScript na sessão autenticada do n8n, permitindo roubo de credenciais ou tokens e alteração de workflows.
Casos de uso afetados
Você autoriza integrações MCP e outro integrante pode revogar essas autorizações. Um cliente cadastrado por um atacante pode levar conteúdo malicioso até a notificação exibida durante essa revogação.
Confira na sua instância
Revise os clientes MCP autorizados e confira seus nomes, especialmente os que apresentam marcação ou links inesperados. Em homologação, acompanhe a autorização e a revogação de um cliente de teste com nome inofensivo e observe como a notificação apresenta esse nome e seu link. Use a versão instalada e as faixas da ficha para conferir a atualização, pois um nome comum não demonstra a ausência da falha.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 1.123.x
< 1.123.32
>= 1.123.32
n8n 2.18.x
< 2.18.1
>= 2.18.1
n8n 2.17.x
< 2.17.4
>= 2.17.4
A descrição do comunicado cita a versão 2.14.2, mas os campos da API registram as três faixas reproduzidas nesta ficha. Para comparar versões, use essas faixas. As medidas temporárias indicadas são restringir o acesso à instância e ao cadastro OAuth ou desabilitar o servidor MCP quando ele não for necessário.
Gravidade altaCVSS: 8,7/10Correção disponível
Cadastro de clientes MCP pode esgotar a memória do servidor
O endpoint de cadastro de clientes OAuth do MCP aceita requisições sem autenticação e armazena os registros sem limitar adequadamente o consumo de recursos. Um atacante remoto pode enviar cadastros volumosos até esgotar a memória e deixar o n8n indisponível. Nas versões afetadas, desligar o acesso MCP na interface mantém esse cadastro acessível. A correção limita o número de clientes e recusa novos cadastros quando o MCP está desabilitado.
Casos de uso afetados
Sua instância permite acesso externo aos endpoints OAuth do MCP. O cadastro pode receber requisições anônimas mesmo que você tenha desabilitado o MCP, deixando o servidor exposto ao consumo excessivo de memória.
Confira na sua instância
Revise as permissões de acesso pela rede ao endpoint /mcp-oauth/register e confira o valor efetivo de N8N_PAYLOAD_SIZE_MAX. Em um ambiente de teste atualizado, desabilite o MCP e envie um único cadastro pequeno, sem credenciais reais, para confirmar que a aplicação recusa sua criação. Você pode fazer essa conferência sem enviar cargas grandes nem tentar esgotar a memória.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 1.123.x
< 1.123.32
>= 1.123.32
n8n 2.18.x
< 2.18.1
>= 2.18.1
n8n 2.17.x
< 2.17.4
>= 2.17.4
Enquanto a atualização não estiver aplicada, você pode restringir o acesso pela rede e reduzir N8N_PAYLOAD_SIZE_MAX. O limite de tamanho reduz o volume aceito por requisição, mas não aplica o limite de clientes introduzido pela correção.
Gravidade altaCVSS: 7,1/10Correção disponível
Código Python pode escapar do isolamento do Task Runner
O isolamento do Python Task Runner permite que código de um workflow ultrapasse a sandbox e execute instruções arbitrárias no container do runner. Um atacante precisa estar autenticado e ter permissão para criar ou alterar workflows com um Code Node configurado para Python. O aviso delimita a falha ao runner, sem afirmar acesso automático ao servidor que hospeda o container.
Casos de uso afetados
Você mantém o Python Task Runner habilitado e permite que outros integrantes editem workflows com código Python. Um editor mal-intencionado pode usar essa permissão para executar código fora do isolamento previsto para o workflow.
Confira na sua instância
Confira na configuração do ambiente se o Python Task Runner está habilitado. Nos workflows com o Code Node, identifique os que usam Python e revise suas permissões de edição. Compare a versão instalada com a faixa corrigida da sua linha. Caso você desative o runner como medida temporária, confira nos logs de inicialização se ele realmente deixou de iniciar.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 1.123.x
< 1.123.32
>= 1.123.32
n8n 2.18.x
< 2.18.1
>= 2.18.1
n8n 2.17.x
< 2.17.4
>= 2.17.4
O comunicado orienta restringir a edição de workflows a integrantes de confiança ou desativar o Python Task Runner. Outra medida indicada é incluir n8n-nodes-base.code em NODES_EXCLUDE. Essa exclusão desativa o Code Node, portanto também afeta workflows que utilizam esse componente para outras linguagens.
Gravidade altaCVSS: 7,1/10Correção disponível
Parâmetros dinâmicos permitem enviar uma credencial alheia a outro servidor
Os endpoints dynamic-node-parameters usam o identificador de credencial recebido sem conferir se o solicitante está autorizado a utilizá-la. Um atacante autenticado com acesso a um workflow compartilhado pode indicar uma credencial de outro integrante e controlar o endereço usado na execução auxiliar. O backend então autentica a chamada com essa credencial no servidor do atacante, expondo uma chave de API reutilizável.
Casos de uso afetados
Você compartilha um workflow que referencia credenciais com um integrante que não deveria utilizá-las. Os endpoints de resolução dinâmica permitem acionar essas credenciais fora da autorização prevista.
Seu workflow usa Nodes que resolvem credenciais por dynamic-node-parameters. A falha pode afetar diferentes tipos de Node que utilizam esses endpoints.
Confira na sua instância
Revise os workflows compartilhados e compare seus participantes com as permissões das credenciais referenciadas. Na inspeção de rede do navegador, identifique as chamadas legítimas a dynamic-node-parameters durante a configuração dos Nodes e confira quais referências de credencial e destinos elas utilizam. Você deve verificar a versão instalada sem enviar credenciais reais para servidores externos durante o teste.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 2.18.x
< 2.18.0
>= 2.18.0
n8n 2.17.x
< 2.17.5
>= 2.17.5
n8n 1.123.x
< 1.123.33
>= 1.123.33
A descrição cita a correção 2.18.0. A API também registra correções nas linhas 2.17.x e 1.123.x, preservadas na tabela. Durante a atualização, restrinja o acesso à instância e evite compartilhar workflows com integrantes que não devem utilizar as credenciais referenciadas.
Gravidade moderadaCVSS: 6,3/10Correção disponível
Chat público permite assumir uma execução que aguarda resposta
O endpoint WebSocket /chat, usado pelo Hosted Chat do Chat Trigger, aceita conexões sem verificar a autorização para a execução escolhida. Com o identificador de uma execução que aguarda resposta, um atacante remoto pode receber a pergunta destinada ao participante legítimo e enviar uma resposta para retomar ou influenciar o workflow. A exploração exige um Hosted Chat público com autenticação None e uma execução em espera.
Casos de uso afetados
Você publica um Hosted Chat sem autenticação e o workflow fica aguardando uma resposta. Um atacante que obtenha ou descubra o identificador dessa execução pode interagir com ela no lugar do participante legítimo.
Confira na sua instância
Abra os Nodes Chat Trigger dos workflows públicos e confira o campo Authentication. Nos que usam None, examine o histórico para identificar execuções que aguardam interação. Caso você aplique a medida temporária n8n User Auth, abra o chat em uma janela sem sessão e confirme a exigência de autenticação. Essa conferência verifica a configuração de acesso, sem assumir uma execução de outro participante.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 1.123.x
< 1.123.32
>= 1.123.32
n8n 2.18.x
< 2.18.1
>= 2.18.1
n8n 2.17.x
< 2.17.4
>= 2.17.4
As três condições precisam coexistir: chat público com Authentication definido como None, execução em espera e identificador acessível ao atacante. O aviso recomenda n8n User Auth como medida temporária para todos os Nodes Chat Trigger.
Gravidade moderadaCVSS: 6,0/10Correção disponível
API pública permite consultar variáveis de outro projeto
A consulta de variáveis pela API pública usa o projectId recebido sem conferir se o titular da chave participa daquele projeto. Um atacante autenticado com uma chave válida e escopo variable:list pode consultar variáveis de projetos aos quais não pertence. O acesso indevido expõe os valores armazenados, inclusive credenciais ou tokens caso você tenha usado variáveis para guardar esses segredos.
Casos de uso afetados
Você administra uma instalação licenciada Enterprise ou Team, com vários projetos e o recurso de variáveis habilitado. Integrantes com chaves autorizadas a listar variáveis podem alcançar valores de outros projetos pela API pública.
Confira na sua instância
Confira se sua licença, seus projetos e o recurso de variáveis correspondem ao cenário descrito. Revise as chaves com escopo variable:list e compare seus titulares com os membros de cada projeto. Abra as variáveis dos projetos para identificar credenciais ou tokens armazenados indevidamente. Você deve substituir imediatamente os segredos que possam ter sido expostos.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 1.123.x
< 1.123.32
>= 1.123.32
n8n 2.18.x
< 2.18.1
>= 2.18.1
n8n 2.17.x
< 2.17.4
>= 2.17.4
O aviso restringe a falha a instalações licenciadas Enterprise ou Team com múltiplos projetos e variáveis habilitadas. Limitar a emissão de chaves a integrantes de confiança reduz o acesso à consulta vulnerável. Atualizar o n8n não invalida segredos que já tenham sido obtidos.
Gravidade moderadaCVSS: 5,3/10Correção disponível
Snowflake e MySQL v1 permitem injeção por identificadores SQL
Os Nodes Snowflake e MySQL v1 inserem diretamente na consulta SQL os nomes de tabelas e colunas e as chaves de atualização recebidas por expressões, sem o escape adequado dos identificadores. Quando esses campos recebem entradas controladas por um atacante, ele pode alterar a consulta executada no banco conectado. A consequência pode ser leitura indevida, modificação ou exclusão de registros. Uma correção anterior não abrangia esses dois Nodes.
Casos de uso afetados
Seu workflow usa um formulário ou webhook para escolher a tabela ou a coluna de uma consulta no Snowflake. A expressão leva essa entrada externa até um identificador SQL vulnerável.
Você mantém um workflow com o MySQL v1 e permite que a entrada externa determine a chave de atualização. Essa configuração permite interferir na consulta enviada ao banco.
Confira na sua instância
Nos workflows exportados ou no editor, localize os Nodes Snowflake e MySQL e confira a versão de cada Node MySQL. Examine as expressões dos campos de tabela, coluna e chave de atualização para identificar referências a formulários ou webhooks. Você deve revisar esses identificadores mesmo que os valores usados na consulta já estejam parametrizados, pois são partes diferentes da instrução SQL.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 1.123.x
< 1.123.32
>= 1.123.32
n8n 2.18.x
< 2.18.1
>= 2.18.1
n8n 2.17.x
< 2.17.4
>= 2.17.4
O MySQL v2 já aplica escape de identificadores, segundo o comunicado. Migrar do MySQL v1 para o v2 é uma medida indicada para esses workflows. Para o Snowflake, o aviso sugere incluir n8n-nodes-base.snowflake em NODES_EXCLUDE e evitar entradas externas não validadas nos campos afetados.
Gravidade moderadaCVSS: 5,3/10Correção disponível
Busca no SeaTable pode retornar linhas além do filtro do workflow
As operações row:search e row:get do Node SeaTable concatenam entradas na consulta SQL sem escape ou parametrização. Um atacante que controle searchTerm ou rowId por uma entrada externa pode modificar a consulta e recuperar linhas que o workflow deveria filtrar. A falha permite contornar a seleção de registros feita pela automação na base SeaTable conectada.
Casos de uso afetados
Você usa um formulário para buscar registros no SeaTable e envia o texto informado diretamente para searchTerm por uma expressão.
Seu webhook recebe o identificador de uma linha e o encaminha para rowId no Node SeaTable. A entrada controlada externamente interfere na consulta usada para recuperar o registro.
Confira na sua instância
Abra os Nodes SeaTable que usam row:search ou row:get e siga a origem das expressões de searchTerm e rowId. Confira se o texto vem diretamente de um formulário ou webhook e qual validação ocorre no percurso. Em homologação, use registros de teste para conferir quais linhas uma busca comum retorna. Você deve combinar essa revisão com a confirmação da versão corrigida, pois uma busca normal não reproduz a injeção.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 1.123.x
< 1.123.32
>= 1.123.32
n8n 2.18.x
< 2.18.1
>= 2.18.1
n8n 2.17.x
< 2.17.4
>= 2.17.4
Você pode evitar entradas externas não validadas nos campos afetados ou desativar o Node com n8n-nodes-base.seaTable em NODES_EXCLUDE. O aviso descreve recuperação indevida de linhas, sem afirmar modificação ou exclusão de registros por essa falha.
Gravidade moderadaCVSS: 5,3/10Correção disponível
Campo Limit do Oracle Database permite injetar SQL
Na operação de seleção do Node Oracle Database, o conteúdo recebido por expressão no campo Limit é inserido diretamente na consulta SQL, sem sanitização ou parametrização. Uma entrada externa controlada por um atacante pode alterar a instrução e permitir a extração de registros do banco Oracle conectado. A necessidade de autenticação acompanha a configuração do workflow. Um webhook público sem autenticação pode permitir a exploração anônima.
Casos de uso afetados
Você recebe pelo webhook o limite de resultados desejado e o envia por expressão para Limit no Node Oracle Database. O campo aparentemente numérico pode levar conteúdo externo até a consulta SQL.
Seu workflow de consulta ao Oracle começa em um webhook sem autenticação e usa a entrada recebida para definir Limit. Nessa configuração, o atacante não precisa autenticar-se no n8n.
Confira na sua instância
Abra os Nodes Oracle Database com operação de seleção e examine o campo Limit. Siga cada expressão até sua origem para conferir se o limite vem de uma entrada externa e se há validação numérica. Revise também a autenticação do webhook que inicia a consulta. Em homologação, você pode conferir a recusa de um texto comum no lugar do número, sem inserir comandos SQL.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 1.123.x
< 1.123.32
>= 1.123.32
n8n 2.18.x
< 2.18.1
>= 2.18.1
n8n 2.17.x
< 2.17.4
>= 2.17.4
As medidas indicadas incluem evitar entradas externas não validadas em Limit, restringir a edição de workflows e desativar o Node com n8n-nodes-base.oracleDatabase em NODES_EXCLUDE. Definir autenticação no webhook altera as condições de acesso, mas a correção do campo exige atualizar o n8n.
Gravidade moderadaCVSS: 5,1/10Correção disponível
Recusa de autorização MCP redireciona para endereço não validado
O cadastro em /mcp-oauth/register aceita clientes sem autenticação e permite registrar um redirect_uri arbitrário. Ao recusar uma autorização MCP, o handler handleDeny encaminha seu navegador para esse endereço sem validá-lo. Um atacante pode usar um link de consentimento como parte de uma tentativa de phishing, levando você a um site externo justamente após clicar em Deny.
Casos de uso afetados
Você abre um link de autorização MCP recebido de uma origem não confiável. Na versão afetada, recusar o consentimento pode encaminhar seu navegador para o endereço cadastrado pelo atacante.
Confira na sua instância
Confira os endereços de retorno dos clientes MCP conhecidos e revise o acesso externo ao cadastro OAuth. Em homologação, use um cliente de teste com endereço de retorno controlado por você, recuse o consentimento e acompanhe o destino no navegador. Compare o comportamento com a versão instalada e evite usar links suspeitos recebidos de terceiros nessa conferência.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 1.123.x
< 1.123.32
>= 1.123.32
n8n 2.18.x
< 2.18.1
>= 2.18.1
n8n 2.17.x
< 2.17.4
>= 2.17.4
A interação necessária é a recusa do consentimento. O comunicado orienta restringir o acesso pela rede aos endpoints OAuth do MCP e permitir acesso à instância apenas a integrantes de confiança durante a preparação da atualização.
Programador há mais de 20 anos, fundador da Powertic e da Promovaweb. Embaixador do n8n no Brasil e da Baserow, Chatwoot, Miro e Kestra. Membro do Product Team do Mautic.
Canais oficiais
Nossos Links
Encontre a Promovaweb no canal que combina com o seu próximo passo.
