Vulnerabilidades do n8n em 02/09/2026

Os avisos de 2 de setembro de 2026 descrevem falhas que podem expor credenciais ou permitir ações fora das permissões de um projeto. Outros afetam a execução de expressões e a disponibilidade da instância. Você pode conferir em cada ficha qual recurso participa da falha e o que revisar no seu ambiente.

As faixas reproduzem os registros da API por linha de manutenção. “Corrigida” indica que o projeto publicou uma correção, portanto você ainda precisa conferir a versão em execução na sua instância. As medidas temporárias citadas nos avisos não substituem a atualização. As conferências propostas orientam a revisão e não representam testes já executados no seu ambiente.

Gravidade altaCVSS: 8,7/10Correção disponível

O cadastro OAuth permite esgotar o armazenamento sem autenticação

O cadastro dinâmico de clientes OAuth gravava client_name e grant_types sem limites adequados de tamanho. Um visitante não autenticado podia registrar valores muito grandes repetidamente, aumentando o banco até esgotar o armazenamento e comprometer a disponibilidade da instância.

Casos de uso afetados

  • Sua instância expõe o cadastro dinâmico OAuth à rede. As requisições podiam ocupar espaço persistente no banco sem exigir uma sessão autenticada.

Confira na sua instância

Confira o tamanho do banco e examine a tabela oauth_clients em busca de nomes excessivamente longos ou listas anormais de grant_types. Revise no proxy reverso o limite do corpo das requisições, que o aviso recomenda manter abaixo do padrão de 16 MiB.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção limita client_name ao tamanho da coluna e aceita somente os tipos de concessão implementados, com limite para a lista. A restrição de acesso pela rede e o limite do proxy são medidas temporárias.

Gravidade altaCVSS: 8,7/10Correção disponível

O campo __sanitize permite escapar da avaliação de expressões

O sanitizador do compilador era resolvido por um this dinâmico. Um campo de classe chamado __sanitize podia substituir essa referência e alcançar o construtor Function, permitindo executar código no processo do n8n. Na prévia do editor, a expressão também podia executar JavaScript na sessão que abrisse o workflow.

Casos de uso afetados

  • Você executa workflows com expressões criadas por outros editores ou abre esses workflows para revisão. A mesma expressão podia afetar o backend durante a avaliação e sua sessão durante a prévia.

Confira na sua instância

Revise as expressões nos parâmetros dos Nodes por exportação dos workflows e procure membros de classe chamados __sanitize. Confira as permissões de criação e edição concedidas a outros acessos e a configuração N8N_EXPRESSION_ENGINE, para a qual o aviso recomenda vm como mitigação.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção rejeita nomes reservados nos membros de classes. A configuração do motor e a restrição de editores são medidas temporárias, sem comprovar que os workflows existentes estejam livres de expressões maliciosas.

Gravidade altaCVSS: 7,7/10Correção disponível

O motor legado de expressões permite executar código pela alteração de JSON.stringify

O compilador de expressões e a camada de isolamento recorriam ao JSON.stringify global para gerar trechos de código. Uma expressão que substituísse essa função podia modificar o código produzido depois, transformando um literal ou o fuso horário em código executável.

Casos de uso afetados

  • Na sua instância, o motor legado avalia expressões criadas por editores de workflows. Nesse motor, a alteração de uma função compartilhada podia permitir a execução de código no processo do n8n.

Confira na sua instância

Confira a configuração efetiva de N8N_EXPRESSION_ENGINE no processo em execução. O aviso delimita a falha ao motor legado e informa que o motor vm não é afetado. Verifique também as permissões de edição dos workflows e as expressões que alteram funções globais.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção usa uma referência de serialização preservada no carregamento do módulo. O comunicado orienta N8N_EXPRESSION_ENGINE=vm como alternativa temporária e recomenda restringir os privilégios do processo.

Gravidade altaCVSS: 7,1/10Correção disponível

A busca de modelos OpenAI envia a credencial a domínios não autorizados

O Node OpenAI Chat Model verificava os domínios permitidos ao usar uma URL-base personalizada, mas a busca de modelos escapava dessa checagem. Um destino definido por options.baseURL nesse percurso recebia a requisição com a credencial anexada, mesmo fora dos domínios autorizados.

Casos de uso afetados

  • Você compartilha uma credencial openAiApi apenas para uso e limita seus domínios, mas permite que outro editor consulte modelos no Node OpenAI Chat Model. Esse acesso podia expor o segredo a um servidor escolhido pelo editor.

Confira na sua instância

Confira os domínios permitidos das credenciais openAiApi e os compartilhamentos apenas para uso. Revise as URLs-base dos Nodes e a atividade do serviço OpenAI para localizar chamadas inesperadas. Na versão corrigida, a listagem de modelos deve aplicar a mesma restrição de domínio das demais chamadas.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

Revogue compartilhamentos com editores não confiáveis e substitua os segredos possivelmente expostos. A correção unifica a checagem de domínios em todas as chamadas OpenAI.

Gravidade altaCVSS: 7,1/10Correção disponível

Um caminho de clone no Node Git pode paralisar a instância

A expressão regular padrão de N8N_BLOCK_FILE_PATTERNS fazia um número excessivo de tentativas ao receber certos caminhos de destino do clone. Como a avaliação ocorria de forma síncrona no processo principal, uma única execução de workflow por um acesso autenticado podia paralisar a instância.

Casos de uso afetados

  • Você permite clones pelo Node Git e mantém o padrão original de N8N_BLOCK_FILE_PATTERNS numa versão afetada. A falha podia comprometer a disponibilidade para todos os acessos, sem exigir uma configuração incomum.

Confira na sua instância

Confira a configuração efetiva de N8N_BLOCK_FILE_PATTERNS e localize os workflows que fazem clone pelo Node Git. Compare episódios de indisponibilidade com o início dessas execuções e com o consumo de CPU do processo principal.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção substitui o padrão por uma avaliação linear no tamanho do caminho. Desativar n8n-nodes-base.git por NODES_EXCLUDE ou usar um padrão equivalente sem retrocesso excessivo são alternativas temporárias documentadas.

Gravidade moderadaCVSS: 6,3/10Correção disponível

A rota de chat permite retomar uma execução sem aprovação

O WebSocket /chat aceitava um resumeToken sem confirmar se a execução aguardava um Node de chat. Como o n8n fornece esse token durante o envio de formulários anônimos, um visitante podia usá-lo para continuar um workflow parado numa etapa de aprovação.

Casos de uso afetados

  • Seu formulário público inicia um workflow que aguarda uma aprovação humana num Node Send-and-Wait ou Wait. O token recebido no formulário podia liberar essa espera pelo chat, mesmo sem a confirmação prevista pelo workflow.

Confira na sua instância

Localize workflows que combinam Form Trigger público com etapas de aprovação fora do chat. Compare as execuções concluídas com os callbacks de aprovação e investigue continuações sem confirmação correspondente.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção limita a retomada pela rota de chat e pelo Chat Hub aos tipos de Node compatíveis com chat. Evite temporariamente combinar formulários públicos com essas esperas até atualizar.

Gravidade moderadaCVSS: 6,3/10Correção disponível

O GitHub Trigger aceita eventos sem verificar a assinatura ao reutilizar um webhook

Quando o GitHub respondia com HTTP 422 porque o webhook já existia, o GitHub Trigger reaproveitava seu identificador e seus eventos, mas descartava o segredo gerado. Sem esse segredo armazenado, a verificação de X-Hub-Signature-256 aceitava eventos enviados por qualquer origem.

Casos de uso afetados

  • Você reativa um workflow cujo webhook continua cadastrado no GitHub. A reutilização após a resposta 422 podia deixar a URL do gatilho aceitando eventos forjados.

Confira na sua instância

Examine os registros persistentes do GitHub Trigger e procure um webhookId sem webhookSecret. Confira também o webhook correspondente no GitHub. Para refazer o cadastro temporariamente, remova primeiro o webhook remoto e depois desative e reative o workflow, confirmando que o novo segredo foi armazenado.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção reaplica o segredo ao webhook existente e recusa a verificação quando falta um segredo. Reativar sem remover o webhook remoto pode repetir o percurso vulnerável.

Gravidade moderadaCVSS: 6,3/10Correção disponível

Identificadores alteram o destino das chamadas aos Nodes Elasticsearch

Os Nodes Elasticsearch e ElasticSecurity inseriam identificadores diretamente no caminho da requisição. Separadores de caminho ou segmentos com pontos podiam desviar uma chamada destinada a um documento para outro índice ou para uma rota administrativa do cluster, usando a credencial armazenada.

Casos de uso afetados

  • Seu workflow preenche o índice ou o identificador de documento com conteúdo recebido de um serviço externo. Esse conteúdo podia alterar a rota acessada pelos Nodes Elasticsearch ou ElasticSecurity.

Confira na sua instância

Examine a origem dos campos de índice e documento nesses Nodes, incluindo expressões alimentadas por entradas externas. Compare as rotas registradas no Elasticsearch com as ações previstas no workflow e verifique os privilégios da credencial utilizada.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção codifica cada identificador como um único segmento de URL e rejeita valores que desaparecem na normalização. Sem atualização imediata, evite entradas externas nesses campos ou exclua n8n-nodes-base.elasticsearch e n8n-nodes-base.elasticSecurity por NODES_EXCLUDE.

Gravidade moderadaCVSS: 6,0/10Correção disponível

O resumo do Instance AI permite alterar o protótipo de objetos do processo

O Instance AI usava nomes de Nodes e chaves de conexão do workflow para montar seu resumo. Uma chave reservada, como __proto__, podia alcançar Object.prototype e alterar objetos usados pelas requisições seguintes no processo principal, causando indisponibilidade. A restrição exibida no editor podia ser contornada pelo envio do workflow diretamente à API.

Casos de uso afetados

  • Você habilita o Instance AI e permite a criação de workflows pela API. Um workflow com nomes reservados podia afetar requisições de toda a instância quando seu resumo era produzido.

Confira na sua instância

Confira se existem variáveis N8N_INSTANCE_AI_MODEL* configuradas e examine os nomes de Nodes e as chaves de conexão dos workflows armazenados. Procure nomes reservados, como __proto__, inclusive em workflows enviados pela API, pois a validação visual do editor não confirmava sua ausência.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção usa acumuladores sem protótipo e valida as chaves aceitas. Remover a configuração N8N_INSTANCE_AI_MODEL* evita temporariamente esse percurso. Reiniciar limpa alterações em memória, mas mantém a falha numa versão vulnerável.

Gravidade moderadaCVSS: 6,0/10Correção disponível

O login OIDC continua emitindo sessões após a desativação

As rotas públicas de login e callback OIDC executavam a autenticação mesmo quando esse método já não estava ativo nas configurações. Desativar o provedor no painel podia deixar uma rota funcional emitindo sessões válidas.

Casos de uso afetados

  • Você administra uma instância n8n Enterprise que já teve o OIDC configurado e depois desativou esse método. O provedor anteriormente configurado podia continuar permitindo acesso pela rota pública.

Confira na sua instância

Compare o estado do OIDC no painel com a aplicação correspondente no provedor de identidade. Em laboratório atualizado, com uma sessão nova, confira se o login e o callback recusam a autenticação quando o OIDC está desativado.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção exige que o OIDC seja o método de autenticação habilitado e ativo. Até atualizar, desative ou revogue também a aplicação correspondente no provedor de identidade.

Gravidade moderadaCVSS: 5,9/10Correção disponível

O push do Source Control permite excluir arquivos de outros projetos

O endpoint de push do Source Control aceitava os caminhos dos arquivos e seus estados diretamente do corpo da requisição. Um acesso limitado a um projeto podia indicar workflows e credenciais de outro projeto e enviar a exclusão desses arquivos ao repositório.

Casos de uso afetados

  • Você usa o recurso Enterprise Source Control (Environments), com licença ativa, configuração habilitada e conexão a um repositório remoto. Um administrador de projeto podia incluir no push exclusões de arquivos pertencentes a projetos inacessíveis.

Confira na sua instância

Confira se o Source Control está habilitado e conectado, depois revise os administradores de projeto. Compare os arquivos excluídos nos pushes recentes com os projetos que o acesso de origem podia administrar, procurando remoções de workflows e credenciais de outros projetos.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção usa o estado calculado pelo servidor para definir os arquivos disponíveis ao acesso que faz o push. Desconectar temporariamente o Source Control reduz a exposição desse percurso até atualizar.

Gravidade moderadaCVSS: 5,9/10Correção disponível

O Log Streaming pode enviar segredos de credenciais de outro projeto

Um destino de Log Streaming podia referenciar uma credencial HTTP genérica e descriptografá-la sem verificar o acesso de sua sessão de criação ou teste. Um acesso com função global personalizada para esse recurso podia selecionar uma credencial de outro projeto e enviar o segredo a um endpoint sob seu controle.

Casos de uso afetados

  • Você concede permissões globais para configurar destinos de Log Streaming, mas mantém credenciais separadas por projeto. A função personalizada podia permitir o envio de uma credencial que esse acesso não estava autorizado a usar.

Confira na sua instância

Revise as funções com eventBusDestination:create ou eventBusDestination:test. Confira as URLs dos destinos de Log Streaming e as credenciais associadas, comparando o projeto de cada credencial com o acesso que configurou o destino. Remova destinos desconhecidos e substitua os segredos possivelmente utilizados.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção aplica a checagem padrão de acesso quando o destino resolve a credencial. Restrinja temporariamente as permissões de Log Streaming a acessos plenamente confiáveis.

Gravidade moderadaCVSS: 5,9/10Correção disponível

O Instance AI pode testar uma credencial num destino externo ao Node

A configuração de credenciais pelo Instance AI aceitava uma URL de teste sem conferir sua origem em relação à URL do Node. A exposição do segredo exigia a inserção ativa de uma URL controlada pelo atacante nesse fluxo, que podia receber a requisição autenticada.

Casos de uso afetados

  • Você configura uma credencial pelo Instance AI e insere no fluxo uma URL de verificação indicada por conteúdo manipulado. Se o endereço aponta para outra origem, a credencial podia ser enviada a esse destino.

Confira na sua instância

Confira se instance-ai aparece em N8N_ENABLED_MODULES e identifique as credenciais criadas por esse fluxo nas versões afetadas. Compare a origem das URLs de teste com a URL do Node, incluindo redirecionamentos. Substitua as credenciais de serviços externos configuradas pelo percurso afetado, conforme orienta o aviso.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção deriva o destino da URL do próprio Node e limita as requisições autenticadas, os redirecionamentos e os testes à mesma origem. Remover instance-ai de N8N_ENABLED_MODULES é uma alternativa temporária quando o módulo não for necessário.

Gravidade moderadaCVSS: 5,3/10Correção disponível

Identificadores e eventos de workflows ficam visíveis entre projetos

A rota /rest/active-workflows devolvia a qualquer membro os identificadores de todos os workflows ativos. Os eventos enviados aos clientes conectados também revelavam ativações e publicações de workflows não compartilhados, incluindo identificadores de versões e detalhes de erros de ativação.

Casos de uso afetados

  • Você mantém automações em projetos com acessos separados. Um membro de outro projeto podia descobrir identificadores e acompanhar mudanças de estado dos seus workflows pelo navegador.

Confira na sua instância

Compare a lista de /rest/active-workflows recebida por um membro com os workflows compartilhados com ele. Num ambiente de teste atualizado, observe os eventos recebidos por esse membro durante a ativação de um workflow de outro projeto: os identificadores e os detalhes dessa automação devem permanecer fora da sessão.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção filtra a listagem e os eventos pelo acesso aos workflows. Até atualizar, restrinja a criação de acessos global:member para participantes não confiáveis.

Gravidade moderadaCVSS: 5,3/10Correção disponível

Uma ferramenta de Agent ignora a restrição de chamada do subworkflow

A configuração “This workflow can be called by” era respeitada pelo Node Execute Workflow, mas não quando o workflow era conectado a um Agent como ferramenta. Um editor capaz de criar o Agent podia executar o workflow restrito e receber seu resultado.

Casos de uso afetados

  • Você limita quais workflows podem chamar uma automação e depois a conecta como ferramenta de um Agent. Esse percurso podia permitir chamadas que a configuração de acesso pretendia recusar.

Confira na sua instância

Abra os workflows conectados como ferramentas de Agents e compare a configuração “This workflow can be called by” com os workflows chamadores. Após atualizar, confira em laboratório, usando um subworkflow sem conteúdo sensível, se uma chamada não autorizada pelo Agent é recusada.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção aplica a permissão de chamada também às ferramentas de Agents. Retire temporariamente workflows sensíveis dessas configurações até atualizar.

Gravidade moderadaCVSS: 5,3/10Correção disponível

O Node Git resolve caminhos relativos fora da pasta permitida

O Node Git verificava a URL remota relativa usando repositoryPath como base, mas o Git localizava a raiz do repositório e resolvia a mesma URL a partir dela. A diferença permitia que fetch ou pull lesse um repositório fora de N8N_RESTRICT_FILE_ACCESS_TO e incorporasse seus objetos ao repositório acessível ao membro.

Casos de uso afetados

  • Você permite o Node Git dentro de uma pasta restrita, mas o caminho configurado aponta para uma subpasta de um repositório. Uma URL relativa podia parecer permitida durante a validação e alcançar outra pasta quando o Git a resolvia.

Confira na sua instância

Compare repositoryPath com a localização real da raiz de cada repositório usado pelo Node Git. Revise as URLs remotas relativas a partir dessa raiz e confira se os destinos permanecem dentro de N8N_RESTRICT_FILE_ACCESS_TO.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção calcula o destino a partir da pasta realmente usada pelo Git. Até atualizar, o aviso orienta desativar o Node com n8n-nodes-base.git em NODES_EXCLUDE.

Gravidade moderadaCVSS: 5,3/10Correção disponível

O setUpstream do Node Git permite ler repositórios fora da pasta autorizada

O setUpstream gravava branch.<name>.remote na configuração do repositório sem validar seu destino. Um fetch ou pull posterior usava essa configuração, em vez do parâmetro já verificado, permitindo ler outro repositório local acessível ao processo do n8n.

Casos de uso afetados

  • Você permite que editores configurem branches pelo Node Git num ambiente com repositórios locais. Uma alteração do remoto da branch podia direcionar a leitura para uma pasta fora da restrição configurada.

Confira na sua instância

Revise os workflows que usam setUpstream e examine os valores branch.<name>.remote nos arquivos de configuração dos repositórios utilizados. Confira os destinos locais indicados e as pastas que o usuário do sistema operacional responsável pelo processo do n8n consegue ler.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 1.123.x< 1.123.76>= 1.123.76
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção valida o remoto da branch com as mesmas restrições do parâmetro de repositório. Até atualizar, desative o Node Git por NODES_EXCLUDE e limite as permissões de leitura do processo.

Gravidade moderadaCVSS: 5,1/10Correção disponível

A gestão de funções expõe nomes e emails de membros de outros projetos

As rotas /rest/roles/:slug/assignments e /rest/roles/:slug/assignments/:projectId/members verificavam a permissão de gerenciar o tipo de função, mas não o acesso ao projeto consultado. Uma sessão com essa permissão podia obter nomes e emails de membros de projetos não autorizados.

Casos de uso afetados

  • Você distribui a gestão de funções por permissões personalizadas e separa os membros em projetos. Um acesso com role:manageProject podia consultar participantes de projetos fora de seu alcance.

Confira na sua instância

Revise as funções globais personalizadas com role:manageProject e os projetos acessíveis a cada sessão. Na instância corrigida, confira com uma sessão restrita se a listagem omite projetos não autorizados e se a consulta aos membros de um desses projetos retorna não encontrado.

Versões afetadas e correções

Faixas declaradas no comunicado oficial, por linha de manutenção
LinhaAfetadasCorrigidas
n8n 2.38.x< 2.38.2>= 2.38.2
n8n 2.37.x< 2.37.7>= 2.37.7

A correção acrescenta a checagem de acesso ao projeto nas duas rotas. Até atualizar, remova role:manageProject dos acessos que não devem consultar esses participantes.

Voltar aos compilados de vulnerabilidades
Luiz Eduardo Oliveira Fonseca

Luiz Eduardo Oliveira Fonseca

Fundador e Mentor

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...

Área pública disponível

Participe da comunidade no Discord

Entre pelo convite oficial, apresente-se à comunidade e acompanhe os avisos e projetos compartilhados entre os encontros.