Os 16 avisos publicados em 16 de setembro descrevem caminhos diferentes para expor credenciais, interferir em aprovações ou alterar consultas feitas pelos Nodes. Algumas falhas exigem acesso ao editor ou ao Redis, enquanto outras dependem apenas de um webhook público ligado a um campo vulnerável. Confira a versão instalada e acompanhe, em cada ficha, o recurso utilizado pelo seu workflow e a origem das entradas que ele aceita.
Aplicativon8n
Data do compilado
Vulnerabilidades16
As pontuações reproduzem o CVSS 4.0 dos comunicados. Compare as faixas separadamente por linha de manutenção, preservando os limites informados pela API. A situação corrigida indica que o projeto disponibilizou uma correção, mas você ainda precisa conferir a atualização da sua instância. As medidas temporárias citadas nas fichas não substituem essa atualização.
Gravidade altaCVSS: 8,5/10Correção disponível
Dynamic Credentials envia o token de sessão a um resolver manipulável
Os endpoints de autorização e revogação de Dynamic Credentials encaminhavam o token de sessão original ao resolver configurado sem aplicar a conferência existente no caminho de execução. Um membro capaz de registrar um resolver e editar o workflow podia direcionar o resolver alternativo para um servidor próprio. Ao utilizar Connect your account, um colaborador ou o proprietário da instância podia ter sua sessão capturada, permitindo a leitura de credenciais acessíveis por ela.
Casos de uso afetados
Você utiliza Dynamic Credentials em um workflow compartilhado. Um colaborador com permissão para registrar resolvers altera o resolver alternativo e aguarda outro participante conectar seu acesso pelo botão Connect your account.
Confira na sua instância
Revise os resolvers registrados, seus endereços e o resolver alternativo dos workflows compartilhados. Confira os papéis globais com credentialResolver:create e restrinja essa permissão a administradores confiáveis. Remova resolvers desconhecidos e renove as sessões e credenciais dos participantes que utilizaram Connect your account em workflows com destinos suspeitos. Caso o módulo não seja necessário, desative-o até atualizar.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
A configuração do resolver alternativo exigia apenas workflow:update, mas a exploração descrita também depende da capacidade de registrar um resolver.
Gravidade altaCVSS: 8,3/10Correção disponível
Inspeção de ferramentas de agente utiliza credenciais de outros projetos
Ao registrar uma ferramenta de Node em um agente inline, o n8n resolvia o formato de entrada da ferramenta e utilizava a credencial indicada sem conferir sua vinculação ao projeto. Essa etapa ocorria durante a preparação da ferramenta, antes da consulta ao modelo. Um membro comum podia indicar uma credencial de outro projeto, inclusive do proprietário da instância, e fazer seu segredo chegar a um servidor externo.
Casos de uso afetados
Você permite que membros configurem agentes inline com ferramentas de Nodes. Um membro encontra o identificador de uma credencial em um workflow exportado ou em uma URL do editor e o utiliza na configuração de uma ferramenta com destino externo.
Confira na sua instância
Examine as ferramentas registradas nos agentes inline e compare cada referência de credencial com o projeto autorizado a utilizá-la. Confira também os destinos externos dessas ferramentas. Remova referências inesperadas e substitua as credenciais cujos identificadores ficaram acessíveis a membros não confiáveis. A revisão deve abranger a preparação das ferramentas, mesmo quando não há registro de uma chamada feita pelo modelo.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
Os identificadores de credenciais não são segredos. A conferência de propriedade existente na chamada da ferramenta não cobria sua inspeção inicial.
Gravidade altaCVSS: 8,1/10Correção disponível
Identificador no Node n8n pode redirecionar chamadas da API pública
O Node n8n utilizava o identificador do recurso para montar o caminho da requisição sem validá-lo ou codificá-lo. Uma entrada manipulada podia direcionar a chamada a outro recurso, mantendo a chave de acesso configurada. Em workflows que recebem esse identificador externamente, um visitante sem autenticação podia consultar, alterar ou excluir workflows e execuções, além de expor uma credencial ao redirecionar um workflow ativo.
Casos de uso afetados
Seu webhook recebe o identificador de um workflow ou de uma execução e o utiliza em uma expressão do Node n8n. A chave configurada possui acesso a recursos além daquele que o webhook deveria consultar.
Confira na sua instância
Localize os Nodes n8n com campos de identificador preenchidos por expressões e acompanhe sua ligação com webhooks públicos. Confira os tipos de recurso autorizados pela chave utilizada e procure alterações inesperadas nos workflows alcançáveis por ela. Enquanto não atualizar, restrinja ou desative os endpoints que recebem identificadores externos e substitua as credenciais que possam ter sido expostas.
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.80
>= 1.123.80
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
O desvio permanece limitado aos tipos de recurso que a chave já está autorizada a acessar.
Gravidade altaCVSS: 7,5/10Correção disponível
Acesso de escrita ao Redis permite instalar pacotes sem as conferências usuais
Em instalações com queue mode, o processamento interno de mensagens de instalação de pacotes comunitários ignorava as conferências aplicadas pelo caminho normal. Não verificava a permissão de instalação nem o nome, a integridade e a segurança do pacote. Um atacante com acesso de escrita ao Redis podia fazer as instâncias do cluster baixarem, instalarem e carregarem um pacote npm arbitrário, mesmo sem acesso autenticado ao n8n.
Casos de uso afetados
Você utiliza o Redis para coordenar várias instâncias do n8n em queue mode. Um serviço externo aos componentes confiáveis do n8n possui acesso de escrita a esse Redis e pode publicar mensagens internas de instalação.
Confira na sua instância
Confira a autenticação do Redis e as permissões de rede dos serviços capazes de acessá-lo. Restrinja esse acesso aos componentes confiáveis do n8n e compare os pacotes comunitários instalados em cada instância para localizar entradas inesperadas. Caso esses Nodes não sejam necessários, configure N8N_COMMUNITY_PACKAGES_ENABLED=false como medida temporária e atualize todas as instâncias do cluster.
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.80
>= 1.123.80
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
A condição de exploração é o acesso de escrita ao Redis utilizado pelo n8n. Restringir somente o editor não cobre esse caminho.
Gravidade altaCVSS: 7,1/10Correção disponível
Identificadores duplicados permitem desviar credenciais de um workflow compartilhado
Ao gravar um workflow compartilhado, o n8n revertia alterações em Nodes ligados a credenciais inacessíveis ao editor. Essa conferência utilizava o identificador do Node, enquanto a execução utilizava seu nome. Dois Nodes com o mesmo identificador permitiam que um deles mantivesse os campos alterados e a referência à credencial protegida, possibilitando o envio do segredo a um servidor controlado pelo editor.
Casos de uso afetados
Você compartilha um workflow com permissão de edição, mas mantém suas credenciais fora do acesso do colaborador. A duplicação de identificadores permite que esse colaborador altere o destino de um Node que utiliza uma dessas credenciais.
Confira na sua instância
Exporte os workflows compartilhados e confira se existem Nodes com o mesmo id. Compare as referências de credenciais e os destinos externos com a configuração esperada, especialmente nos workflows editados por colaboradores sem acesso às credenciais. Remova permissões de edição desnecessárias e substitua as credenciais que possam ter sido expostas. Para este aviso, a API informa correção somente na linha 1.123.x.
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.80
>= 1.123.80
Não extrapole a faixa deste aviso para as linhas 2.x, que não aparecem na relação de versões da API.
Gravidade altaCVSS: 7,1/10Correção disponível
Teste de credencial expõe variáveis de projetos sem conferir o acesso
O endpoint de teste de credenciais aceitava o identificador do projeto no corpo da requisição sem conferir a permissão do membro sobre esse projeto. As expressões da credencial podiam utilizar variáveis do projeto indicado e inserir seu conteúdo em uma requisição de teste enviada a um destino escolhido pelo atacante. Assim, um membro comum conseguia extrair variáveis de projetos aos quais não tinha acesso.
Casos de uso afetados
Você armazena valores sensíveis em variáveis de um projeto restrito. Outro membro da instância utiliza o teste de uma credencial para resolver essas variáveis e enviá-las a um endereço externo.
Confira na sua instância
Revise as variáveis dos projetos restritos e identifique aquelas que contêm segredos. Examine os destinos das requisições de teste de credenciais e os registros de tráfego de saída para localizar endereços desconhecidos. Caso um segredo armazenado nessas variáveis possa ter sido exposto, substitua-o. Até atualizar, restrinja o acesso à instância a membros confiáveis.
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.80
>= 1.123.80
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
A separação entre projetos não era conferida durante a resolução das variáveis por esse endpoint.
Gravidade altaCVSS: 7,1/10Correção disponível
Alteração do host nas credenciais Wekan e Baserow expõe a senha
As credenciais de usuário e senha do Wekan e do Baserow enviavam o login e a senha em texto claro para o endereço definido no próprio campo de host durante a pré-autenticação. Esse caminho não aplicava a restrição de Allowed HTTP Request Domains. Um membro autorizado a editar a credencial, mesmo sem permissão para ler seu segredo, podia alterar o host e receber a senha em um servidor próprio.
Casos de uso afetados
Você permite que um colaborador altere uma credencial Wekan ou Baserow sem visualizar a senha. A edição do host pode desviar a requisição de pré-autenticação para um endereço controlado por esse colaborador.
Confira na sua instância
Abra as credenciais Wekan e Baserow e compare seus hosts com os endereços legítimos dos serviços. Revise os papéis personalizados com credential:update e remova essa permissão dos membros que não precisam editar credenciais. Examine o tráfego de saída associado à resolução dessas credenciais e substitua as senhas potencialmente expostas.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
O comunicado informa que o vazamento não deixa registro no conteúdo das execuções. Allowed HTTP Request Domains não cobria a pré-autenticação afetada.
Gravidade altaCVSS: 7,1/10Correção disponível
Nome de tabela no Supabase permite desviar caminhos e alterar consultas
O Node Supabase inseria tableId no caminho da requisição sem validação. Quando esse campo recebia conteúdo externo por expressão, um atacante podia desviar a chamada para os serviços de autenticação e armazenamento utilizando a chave administrativa serviceRole. Também podia introduzir trechos de consulta que ampliassem as colunas retornadas ou os filtros de registros, inclusive nas ações de atualização e exclusão.
Casos de uso afetados
Seu workflow recebe o nome da tabela de um webhook e o utiliza em tableId no Node Supabase. A entrada pode alterar tanto o destino da requisição quanto a seleção de registros feita com a chave administrativa.
Confira na sua instância
Examine o campo de nome da tabela em todos os Nodes Supabase e identifique expressões ligadas a entradas externas. Substitua essas ligações por tabelas definidas no workflow e revise as chamadas inesperadas aos serviços de autenticação ou armazenamento. Caso a configuração vulnerável tenha ficado exposta, substitua a chave serviceRole. Você pode desativar o Node com n8n-nodes-base.supabase em NODES_EXCLUDE se ele não for necessário.
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.80
>= 1.123.80
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
As cinco ações sobre registros são afetadas. A chave serviceRole utilizada no desvio ignora as restrições de acesso por linha do Supabase.
Gravidade altaCVSS: 7,1/10Correção disponível
Filters (String) no Supabase permite ampliar a consulta para toda a tabela
O modo Filters (String) do Node Supabase inseria o filtro diretamente na consulta PostgREST sem o tratamento necessário do conteúdo. Uma expressão ligada a uma entrada não confiável permitia que um atacante ampliasse a seleção planejada para um registro até alcançar toda a tabela. O comunicado confirma a leitura ampliada e uma exclusão que esvaziou a tabela com uma única requisição, além de apontar a atualização de registros como afetada.
Casos de uso afetados
Você usa uma entrada de webhook para montar o filtro de leitura, atualização ou exclusão no modo Filters (String). A alteração dessa entrada pode atingir registros além daquele que o workflow deveria selecionar.
Confira na sua instância
Abra os Nodes Supabase configurados com Filters (String) e acompanhe a origem das expressões do filtro. Troque esse modo por Build Manually, que utiliza a construção parametrizada indicada pelo comunicado, e restrinja os gatilhos que recebem conteúdo externo. Para conferir o alcance da seleção, utilize uma tabela de teste com registros conhecidos e confirme que apenas o registro previsto é retornado ou alterado.
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.80
>= 1.123.80
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
O modo Build Manually não é afetado por esta falha específica. Sua adoção como medida temporária não substitui a atualização da instância.
Gravidade altaCVSS: 7,0/10Correção disponível
Campos de tabela e schema permitem injeção na exclusão pelo Oracle
Na ação Delete Table com Drop do Node Oracle Database, os campos table e schema entravam em uma instrução PL/SQL sem o tratamento necessário das aspas simples. Quando uma expressão recebia conteúdo externo nesses campos, um atacante podia acrescentar comandos capazes de modificar ou excluir objetos do banco, conforme as permissões da credencial. O comunicado registra a exclusão irrecuperável de uma tabela e não demonstra vazamento de informações.
Casos de uso afetados
Seu workflow usa Delete Table com Drop e preenche o nome da tabela ou do schema por uma expressão ligada a uma entrada externa. Essa entrada permite interferir no comando executado com a credencial Oracle configurada.
Confira na sua instância
Abra os Nodes Oracle Database que utilizam Delete Table com Drop e acompanhe a origem das expressões de table e schema. Remova a ligação desses campos com entradas não confiáveis e confira se a credencial possui permissões de exclusão além das necessárias. Caso o Node não seja utilizado, você pode desativá-lo com n8n-nodes-base.oracleDatabase em NODES_EXCLUDE enquanto prepara a atualização.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
n8n 1.123.x
< 1.123.80
>= 1.123.80
A capacidade de alteração ou exclusão fica limitada às permissões da credencial Oracle usada pelo Node.
Gravidade altaCVSS: 7,0/10Correção disponível
URL assinada permite falsificar aprovações de outro projeto
A geração da URL assinada de retomada do Send and Wait incorporava um identificador de Node controlado pelo editor. Sequências de navegação no caminho eram resolvidas durante a geração, mas a assinatura não vinculava a URL ao workflow, ao projeto ou ao proprietário de origem. Um membro capaz de gravar um workflow podia gerar um endereço válido para aprovar ou recusar uma etapa de outro projeto, inclusive em execuções futuras.
Casos de uso afetados
Você mantém aprovações com Send and Wait em projetos separados e permite que outros membros criem workflows. Um desses membros pode interferir em uma aprovação de um projeto ao qual não possui acesso de leitura.
Confira na sua instância
Confira os membros com permissão para criar workflows e examine o histórico dos workflows com Send and Wait nos projetos restritos. Investigue aprovações ou recusas sem correspondência com a autorização esperada. Enquanto a instância permanecer em uma versão afetada, limite a criação de workflows a membros confiáveis e não considere a assinatura da URL uma comprovação suficiente da origem da aprovaçã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.80
>= 1.123.80
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
O comunicado informa que a URL falsificada permanecia válida para execuções futuras da etapa atingida.
Gravidade altaCVSS: 7,0/10Correção disponível
MongoDB Chat Memory permite consultar conversas de outras sessões
O Node MongoDB Chat Memory utilizava sessionId recebido pelo Chat Trigger sem conferir se o conteúdo era uma string simples. Um visitante podia enviar um operador de consulta do MongoDB no lugar do identificador e fazer a busca alcançar conversas de outras sessões. O mesmo caminho de consulta atendia à gravação e à exclusão, expondo também essas ações ao defeito.
Casos de uso afetados
Você publica um chat com o Chat Trigger sem autenticação e utiliza MongoDB Chat Memory para guardar as conversas. Um visitante com acesso apenas à URL do chat pode consultar históricos pertencentes a outros participantes.
Confira na sua instância
Confira quais Chat Triggers sem autenticação estão ligados ao MongoDB Chat Memory. Ative a autenticação nesses chats ou substitua temporariamente o backend de memória. Em um ambiente de teste atualizado, utilize duas sessões com mensagens distintas e confira que uma consulta não retorna o histórico da outra. Verifique também que sessionId com conteúdo diferente de uma string não é aceito como operador de consulta.
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.80
>= 1.123.80
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
O cenário informado combina Chat Trigger sem autenticação e MongoDB Chat Memory. O comunicado confirma a leitura de históricos alheios e aponta a gravação e a exclusão como expostas pelo mesmo defeito.
Gravidade moderadaCVSS: 6,9/10Correção disponível
Consultas ao SendGrid, Freshservice e ServiceNow podem ignorar filtros
Os Nodes SendGrid, Freshservice e ServiceNow montavam consultas com campos inseridos diretamente nas linguagens de filtro dos serviços. Uma entrada externa podia encerrar o trecho destinado ao texto pesquisado e acrescentar condições que ampliassem a busca. Uma consulta planejada para um único registro podia retornar contatos, registros de atendimento ou outras informações acessíveis à integração no serviço conectado.
Casos de uso afetados
Você recebe uma pesquisa por webhook e utiliza seu conteúdo diretamente em uma expressão de consulta de um dos Nodes afetados. O visitante pode alterar o filtro enviado ao serviço e consultar registros além daquele previsto pelo workflow.
Confira na sua instância
Examine as expressões dos campos de consulta e filtro nos Nodes SendGrid, Freshservice e ServiceNow. Acompanhe cada expressão até sua origem e identifique as que recebem conteúdo de webhooks ou requisições externas. Até atualizar, remova essas ligações diretas ou desative os workflows públicos que as utilizam. Confira também se buscas recentes retornaram conjuntos de registros maiores que o esperado.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
A exploração depende de um campo vulnerável ligado a uma entrada não confiável. A exposição ocorre dentro do acesso disponível à integração no serviço conectado.
Gravidade moderadaCVSS: 6,9/10Correção disponível
Link de Resource Locator permite executar JavaScript no editor
O parâmetro Resource Locator armazenava uma URL oferecida como link externo no menu do Node, mas o editor abria esse endereço sem conferir seu protocolo. Um autor de workflow podia gravar uma URL de script que executava JavaScript na origem do editor quando um colaborador clicava no ícone de link externo. O conteúdo permanecia no workflow compartilhado ou importado.
Casos de uso afetados
Você abre um workflow importado ou compartilhado, expande o menu de um Resource Locator e utiliza seu ícone de link externo. Uma URL manipulada nesse campo pode executar código no navegador durante esse clique.
Confira na sua instância
Inspecione os valores de URL dos parâmetros Resource Locator nos workflows importados e compartilhados, preferencialmente lendo o JSON exportado. Procure protocolos de script e endereços diferentes dos serviços esperados, sem abrir os links suspeitos. Remova os valores desconhecidos e confira a atualização da instância antes de voltar a utilizar esses atalhos no editor.
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.80
>= 1.123.80
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
A exploração descrita exige o clique no ícone de link externo do Resource Locator.
Gravidade moderadaCVSS: 6,9/10Correção disponível
Webflow Trigger aceita eventos falsificados sem conferir a assinatura
O Node Webflow Trigger aceitava requisições POST no webhook sem validar a assinatura enviada pelo Webflow no cabeçalho x-webflow-signature. Um atacante que conhecesse a URL podia simular um evento legítimo e iniciar o workflow com conteúdo escolhido por ele. Os Nodes seguintes podiam então criar registros, enviar mensagens ou chamar serviços internos a partir desse evento falsificado.
Casos de uso afetados
Você utiliza eventos do Webflow para criar ou atualizar registros em outro serviço. A URL pública do Webflow Trigger recebe uma requisição forjada que o workflow interpreta como um evento autêntico.
Confira na sua instância
Localize os workflows com Webflow Trigger e confira a versão do próprio Node, além da versão instalada do n8n. A correção foi aplicada somente ao Webflow Trigger versão 2. Em uma cópia de teste sem ações externas, confira após a atualização que uma requisição sem assinatura válida é recusada e não inicia a execução. Até atualizar, desative os workflows dispensáveis ou restrinja o endpoint aos intervalos de IP publicados pelo Webflow.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
n8n 1.123.x
< 1.123.80
1.123.80
A atualização do n8n precisa ser acompanhada da conferência do Webflow Trigger versão 2. O valor 1.123.80 foi preservado exatamente como aparece em patched_versions, sem acrescentar um operador.
Gravidade moderadaCVSS: 6,3/10Correção disponível
Aprovação pelo chat aceita retomada sem validar o aprovador
O modo Approve Within Chat do Node Send and Wait aceitava uma chamada de retomada sem confirmar sua origem no Slack ou no Telegram e sem aplicar a lista de aprovadores permitidos. Um visitante com acesso à mensagem de aprovação podia liberar a execução pendente, mesmo sem autenticação no n8n. A exploração exige uma instância acessível publicamente por HTTPS e a visualização da mensagem referente à execução.
Casos de uso afetados
Você utiliza o modo Approve Within Chat para aguardar uma autorização no Slack ou no Telegram. A mensagem aparece em um canal acessível a participantes que não deveriam autorizar a ação seguinte do workflow.
Confira na sua instância
Localize os Nodes Send and Wait configurados com Approve Within Chat e confira os participantes dos canais de aprovação. Examine as execuções retomadas e compare cada aprovação com o registro correspondente no chat. Até atualizar, suspenda esse modo nos workflows cujas ações precisam de autorização restrita e reduza o acesso às mensagens de aprovação.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
n8n 2.40.x
< 2.40.1
>= 2.40.1
n8n 2.39.x
< 2.39.6
>= 2.39.6
Uma lista de aprovadores configurada não neutraliza esta falha nas versões afetadas.
Programador há mais de 20 anos, especialista em Mautic e automação de marketing. Fundador da Powertic e da Promovaweb. Embaixador global do n8n (Community Awards 2024/2025), Bas...
Canais oficiais
Nossos Links
Encontre a Promovaweb no canal que combina com o seu próximo passo.
