Pesquisadores da GitGuardian encontraram 321 instâncias do n8n que aceitavam tokens de API expostos em commits públicos do GitHub e demonstraram quatro formas como invasores poderiam utilizá-los para acessar dados sensíveis e credenciais de sistemas integrados, sem explorar nenhuma vulnerabilidade no software.
Os pesquisadores analisaram commits públicos no GitHub em busca de tokens de API do n8n expostos e identificaram 4.576 credenciais únicas associadas a 1.255 nomes de host. Das 896 instâncias acessíveis no momento dos testes, 321 aceitaram pelo menos um token vazado.
Isso significa que as credenciais vazadas forneceram acesso autenticado a 36% das instâncias acessíveis testadas, ou cerca de 26% de todos os nomes de host identificados nos commits.
As implicações vão muito além do n8n. Organizações utilizam a plataforma de automação para conectar bancos de dados, repositórios de código-fonte, ambientes de nuvem, serviços de inteligência artificial, plataformas de atendimento ao cliente e outros sistemas internos. Um token do n8n com privilégios suficientes pode expor definições de fluxos de trabalho e dados de execução, permitir que invasores utilizem credenciais armazenadas e, em algumas configurações, possibilitar a extração dos valores dessas credenciais.
Para medir o raio de alcance potencial do problema, os pesquisadores reproduziram quatro técnicas práticas de ataque em um ambiente controlado do n8n. Cada uma exigiu apenas funcionalidades documentadas da API REST (Interface de Programação de Aplicações Representacional) e requisições HTTP padrão. Nenhuma exploração de CVE (Vulnerabilidades e Exposições Comuns) ou ferramenta especializada foi necessária.
Por que o n8n é um alvo de alto valor
O n8n é uma plataforma de automação de fluxos de trabalho de baixo código, de código aberto, com suporte a agentes de inteligência artificial e centenas de integrações nativas. Organizações a utilizam para conectar ferramentas internas, automatizar pipelines, implementar lógica de negócios e orquestrar integrações de API em suas pilhas de tecnologia.
A plataforma pode ser auto-hospedada ou implantada por meio do n8n.cloud, e seu repositório de código aberto acumulou quase 200.000 estrelas no GitHub.
Uma instância do n8n executa fluxos de trabalho compostos por nós. Alguns nós disparam fluxos de acordo com uma agenda ou por meio de webhooks, enquanto outros transformam dados, executam código ou se conectam a serviços externos utilizando credenciais armazenadas, como chaves de API, tokens e senhas de banco de dados.
Essas credenciais são criptografadas em repouso, utilizando um segredo mestre chamado N8N_ENCRYPTION_KEY. No entanto, o n8n ainda precisa descriptografá-las e utilizá-las sempre que um fluxo de trabalho é executado. Um invasor com privilégios suficientes de API pode, portanto, referenciar essas credenciais em novos fluxos de trabalho e fazer com que a instância as utilize em seu nome.
Com mais de 100.000 instâncias visíveis por meio do Shodan e mais de 50 avisos de segurança publicados desde janeiro de 2026, o n8n tem atraído a mesma atenção de outros ambientes de integração de alto valor.
Em 31 de março de 2026, 58% das instâncias analisadas executavam uma versão afetada por pelo menos um aviso de segurança conhecido. Vários CVEs recentes permitiam que invasores escapassem de sandboxes de execução e obtivessem acesso arbitrário de leitura ou gravação ao sistema de arquivos do host.
O CVE-2025-68613, uma vulnerabilidade de injeção de expressão com pontuação CVSS (Sistema Comum de Pontuação de Vulnerabilidades) de 9,9, foi adicionado ao catálogo de Vulnerabilidades Exploradas Conhecidas da Agência de Cibersegurança e Infraestrutura dos Estados Unidos (CISA) em 11 de março de 2026, confirmando a exploração em ambiente real.
Tokens de API vazados criam um risco à parte. Um invasor não precisa necessariamente explorar uma vulnerabilidade do n8n se uma credencial válida já fornece acesso autenticado à instância.
321 instâncias aceitaram tokens vazados
O GitGuardian Public Monitoring verifica fontes públicas em busca de credenciais expostas. Para esta pesquisa, a equipe coletou todos os tokens de API do n8n identificados em commits públicos do GitHub desde abril de 2025.
O pipeline extraiu o nome de host do n8n enviado junto com cada token, enviou uma requisição de validação somente leitura para a instância associada e registrou a resposta.
A varredura produziu:
As 321 instâncias confirmadas representam aproximadamente 36% das 896 instâncias acessíveis e 26% de todos os 1.255 nomes de host identificados nos commits.
O mesmo processo foi executado contra chaves de API do Model Context Protocol (MCP) do n8n encontradas no mesmo conjunto de commits. Os tokens MCP permitem que assistentes de inteligência artificial acionem fluxos de trabalho do n8n por meio do Protocolo de Contexto de Modelo, representando uma superfície de exposição mais recente do que a API REST.
Dos 372 tokens MCP identificados, sete ainda eram válidos no momento dos testes, o equivalente a cerca de 2%.
Por que tokens do n8n vazados podem continuar válidos
Uma chave de API do n8n é um JSON Web Token (JWT) assinado, com a reivindicação de público "aud": "public-api". Um token decodificado tem o seguinte aspecto:
O token registra seu horário de emissão na reivindicação iat. Chaves de API mais antigas do n8n frequentemente não contêm a reivindicação exp, que define quando expiram.
O n8n introduziu uma expiração padrão de 30 dias na versão 1.78.0, em fevereiro de 2025, mas muitos dos tokens encontrados durante a pesquisa tinham sido gerados sem data de expiração. Uma chave enviada ao GitHub meses antes poderia, portanto, permanecer utilizável até que alguém a excluísse ou revogasse explicitamente.
Na prática, as chaves de API do n8n se comportam de maneira diferente dos JWTs autocontidos, que podem ser validados apenas por suas assinaturas. A chave também precisa continuar existindo no banco de dados do n8n. Um token exposto no GitHub permanece perigoso enquanto a instância continuar reconhecendo-o.
Testar um token candidato requer uma única requisição somente leitura, com a chave enviada por meio do cabeçalho X-N8N-API-KEY:
GET /api/v1/workflows retorna as definições de fluxos de trabalho disponíveis para o usuário autenticado.
Uma resposta 200 confirma que o token foi aceito. Um 401 indica que o token é inválido, foi removido do banco de dados ou falhou na verificação de assinatura. Um 404 pode indicar que a API pública está desativada na instância.
A requisição não realiza nenhuma alteração na instância de destino.
A URL da instância geralmente é enviada junto com o token
Uma chave de API do n8n só é útil quando um invasor consegue identificar a instância que a aceita. Em commits públicos do GitHub, no entanto, nome de host e token frequentemente aparecem juntos.
Um arquivo .env é um exemplo comum:
Os pesquisadores também encontraram um padrão mais recente associado a arquivos de permissão do Claude Code.
O Claude Code pode armazenar comandos de shell permitidos em .claude/settings.json ou .claude/settings.local.json. Quando os usuários configuram o Claude Code para interagir com o n8n, podem inserir tanto a URL da instância quanto a chave de API diretamente em um comando curl aprovado.
Esses arquivos de configuração podem, então, ser enviados a um repositório sem as mesmas proteções de .gitignore que os desenvolvedores geralmente aplicam a arquivos .env.
O mesmo pareamento de nome de host e token apareceu sob vários outros nomes de variáveis, incluindo:
Como o nome de host geralmente estava disponível no mesmo commit do token, o pipeline não exigiu uma etapa separada de descoberta de infraestrutura.
O que um token do n8n autenticado expõe
Um token de API do n8n fornece acesso de acordo com as permissões do usuário que o criou. Na prática, muitos dos tokens expostos pareciam pertencer a proprietários ou administradores das instâncias, provavelmente porque eram esses usuários que configuravam as integrações e enviavam as chaves.
Dependendo do papel da conta, a API REST pública pode expor:
- GET /api/v1/users: nomes de usuários, endereços de e-mail, datas de criação de contas e convites pendentes. Algumas informações são restritas aos proprietários da instância.
- GET /api/v1/workflows: definições completas de fluxos de trabalho, incluindo configuração de nós, código em JavaScript ou Python em nós de Código, consultas SQL e segredos hard-coded nos parâmetros dos fluxos.
- GET /api/v1/credentials: nomes, tipos e informações de compartilhamento das credenciais, mas não os valores subjacentes. Esse endpoint é restrito a proprietários e administradores.
- GET /api/v1/executions: histórico de execução dos fluxos de trabalho. Adicionar ?includeData=true pode retornar o conteúdo completo de entrada e saída de cada execução.
- GET /api/v1/data-tables: linhas de tabelas visíveis ao usuário autenticado.
- GET /api/v1/variables: nomes de variáveis e seus conteúdos. Esse endpoint é restrito a proprietários e administradores.
As definições dos fluxos de trabalho criam a exposição mais imediata, porque a API retorna configurações completas dos nós. Se um desenvolvedor inseriu uma chave de API ou token diretamente em um parâmetro de nó, em vez de usar o repositório de credenciais do n8n, o valor pode aparecer em texto claro.
O endpoint de credenciais em si não retorna os valores secretos armazenados. No entanto, como os testes controlados demonstram, um invasor com permissão para criar e executar fluxos de trabalho pode conseguir referenciar uma credencial armazenada e fazer com que o n8n a utilize ou transmita.
O endpoint de auditoria fornece um mapa de ataque
O endpoint de auditoria do n8n pode fornecer a um usuário autenticado um relatório de segurança da instância:
A resposta pode identificar:
- Possíveis exposições de injeção de SQL em fluxos de trabalho
- Nós com acesso ao sistema de arquivos
- Webhooks desprotegidos
- A versão do n8n em execução, que pode ser confrontada com CVEs conhecidos
- Credenciais não utilizadas
- Nos de alto risco ou instalados pela comunidade
- Recursos de segurança habilitados
- Listas de permissão e bloqueio de nós
- Configurações de telemetria
Para um administrador legítimo, essas informações apoiam revisões de segurança. Para um invasor com um token privilegiado vazado, podem oferecer um mapa priorizado dos caminhos de ataque mais promissores da instância.
Quatro técnicas de ataque contra uma instância totalmente atualizada
A GitGuardian não executou as técnicas de exploração a seguir contra sistemas de terceiros expostos. A equipe as reproduziu em uma implantação controlada do n8n, criada especificamente para a pesquisa.
O fluxo de trabalho de teste continha três fragilidades deliberadas:
- Um formulário web que armazenava submissões em uma tabela de dados acessível por meio de fluxos autenticados.
- Um nó do OpenAI que processava cada submissão utilizando um objeto de credencial armazenado.
- Um nó de Requisição HTTP que publicava o resultado no GitHub utilizando um token hard-coded em seus parâmetros.
Utilizando esse ambiente, foram demonstradas quatro técnicas, progredindo da enumeração passiva à exfiltração ativa de credenciais.
Técnica 1: enumerar a instância
O GET /api/v1/users retornou quatro contas: o proprietário da instância, dois usuários ativos e um registro pendente.
O GET /api/v1/workflows retornou nove definições completas de fluxos de trabalho. No fluxo de trabalho alvo, os parâmetros de um nó de Requisição HTTP continham um token do GitHub em texto claro.
Essa primeira técnica não exigiu nenhuma modificação no fluxo de trabalho. As informações expostas já estavam disponíveis por meio de operações de leitura permitidas para a conta autenticada.
Técnica 2: usar uma credencial armazenada do OpenAI
O GET /api/v1/credentials listou todos os objetos de credenciais armazenadas, incluindo um chamado "Conta OpenAI". O endpoint revelou seu nome, tipo e identificador, mas não a chave de API em si.
Foi criado um fluxo de trabalho com um gatilho de agendamento e um nó do OpenAI referenciando a credencial pelo seu ID e, em seguida, ativado.
Dois truques tornam isso possível. O gatilho de agendamento é acionado automaticamente após cerca de 10 segundos, dando tempo para o fluxo de trabalho ser concluído. O GET /api/v1/executions?includeData=true então recupera o registro completo de execução. Como o n8n persiste a saída completa de cada nó, a resposta do OpenAI aparece em texto claro.
Os pesquisadores executaram prompts arbitrários do OpenAI utilizando a credencial armazenada da instância, sem nunca visualizar seu valor.
Técnica 3: ler a tabela de dados
Os mesmos dois truques se aplicam.
Foi criado um fluxo de trabalho com um gatilho de agendamento e um nó de Tabela de Dados configurado para recuperar todas as linhas e, em seguida, ativado. O GET /api/v1/executions?includeData=true retornou o registro de execução segundos depois, com cada linha em texto claro.
Quatro linhas foram exfiltradas, incluindo nomes, endereços de e-mail, respostas do formulário e status de processamento.
O fluxo de trabalho foi então excluído.
Técnica 4: exfiltrar a credencial bruta do OpenAI
A quarta técnica foi além de usar uma credencial armazenada e extraiu seu valor subjacente.
Os pesquisadores iniciaram um listener HTTP e, em seguida, criaram um fluxo de trabalho com um gatilho de agendamento e um nó de Requisição HTTP.
O truque principal é que o nó de Requisição HTTP pode usar uma credencial armazenada do n8n como método de autenticação ao enviar requisições para qualquer URL. Os pesquisadores configuraram o nó para usar a credencial armazenada do OpenAI e o apontaram para o listener.
Quando o fluxo de trabalho foi acionado, o n8n anexou o valor da credencial como um Bearer token no cabeçalho Authorization da requisição de saída. O listener capturou a chave de API bruta segundos após a ativação.
O fluxo de trabalho foi então excluído.
Em conjunto, essas técnicas mostram como um invasor pode passar de um token do n8n vazado a uma exposição mais ampla de credenciais e dados, utilizando funcionalidades legítimas da plataforma:
- Enumerar usuários, fluxos de trabalho e configuração de segurança.
- Identificar objetos de credenciais armazenadas e segredos hard-coded.
- Usar credenciais armazenadas sem visualizar seus valores.
- Ler dados disponíveis para os fluxos de trabalho.
- Fazer com que o n8n transmita uma credencial armazenada para uma infraestrutura controlada pelo invasor.
A exclusão do fluxo malicioso também removeu os registros de execução associados da interface, potencialmente deixando aos defensores evidências limitadas para investigar.
Fluxos de trabalho reais apresentaram fragilidades semelhantes
A demonstração controlada não se baseou em uma configuração puramente teórica. Durante a pesquisa, foram encontradas instâncias reais do n8n com padrões expostos de forma semelhante.
Um fluxo de trabalho realizava backup automático de suas próprias definições em um repositório público do GitHub. Uma chave SSH de implantação havia sido inserida diretamente em um de seus nós.
O histórico Git do repositório continha versões anteriores de cada fluxo de trabalho, e a chave SSH permanecia válida.
O fluxo de trabalho estava, na prática, publicando sua própria configuração sensível e credenciais a cada execução.
O caso ilustra por que plataformas de automação de fluxos de trabalho podem criar raios de impacto unusually grandes. Elas ficam entre múltiplos sistemas, processam dados sensíveis e realizam autenticações rotineiras em serviços externos. Uma fragilidade em um único fluxo de trabalho pode expor acessos que vão muito além da própria plataforma de automação.
Divulgação responsável gerou respostas limitadas
Encontrar uma credencial exposta válida é apenas o primeiro passo. O risco permanece até que a organização afetada a revogue e trate qualquer exposição em sistemas conectados.
Foi tentada a divulgação responsável com sete organizações:
- Três provedores de hospedagem associados, no total, a aproximadamente 100 instâncias afetadas
- Quatro empresas individuais
Um provedor de hospedagem não respondeu. Três das quatro empresas individuais também não responderam.
Uma empresa operava um programa de recompensas por bugs, reconheceu o relatório, pagou uma recompensa de US$ 1.200 e revogou a credencial imediatamente. Essa combinação de reconhecimento e correção rápida foi a exceção.
A GitGuardian também fez várias divulgações diretamente ao n8n durante a pesquisa. O n8n reconheceu os relatos, afirmou estar ciente dos problemas e planejar tratá-los e, subsequentemente, encerrou os relatórios. No momento da publicação, a GitGuardian não havia confirmado de forma independente que as correções relacionadas tivessem sido lançadas.
Cerca de 30% das 321 instâncias afetadas estavam hospedadas no n8n.cloud ou em serviços gerenciados semelhantes.
O GitGuardian Public Monitoring já identifica tokens de API do n8n expostos e notifica os desenvolvedores afetados por meio do programa de divulgação Good Samaritan da empresa. As descobertas também levaram a GitGuardian a atualizar seu detector de chaves de API do n8n e suas verificações de validade para melhorar a precisão da detecção.
Conclusões
Um token do n8n vazado não é uma exposição isolada de credencial. Um token com privilégios suficientes pode expor definições de fluxos de trabalho, segredos hard-coded, dados de execução e tabelas internas. Também pode permitir que um invasor utilize credenciais armazenadas ou, ao criar um fluxo de trabalho que as envie para um endpoint externo, extrair seus valores subjacentes.
Nenhum CVE ou ferramenta especializada foi necessário nos testes controlados. Bastaram algumas requisições HTTP padrão para passar de um token exposto ao acesso a dados sensíveis e a credenciais de sistemas integrados. Um invasor poderia, então, excluir o fluxo de trabalho e seus registros de execução associados, deixando aos defensores evidências limitadas dentro do próprio n8n.
Revogar o token do n8n exposto é o primeiro passo, mas pode não ser o último. As organizações devem determinar quais fluxos de trabalho, dados e credenciais conectadas a conta poderia acessar, revisar a instância em busca de alterações não autorizadas e rotacionar as credenciais conectadas nos casos em que a exposição não puder ser descartada.
Plataformas de automação criam um raio de impacto particularmente grande porque ficam no centro das integrações de uma organização. Um único token pode abrir caminho para controle de código-fonte, bancos de dados, serviços de nuvem, APIs de inteligência artificial, plataformas de suporte e dados de clientes. O risco é definido não apenas pela instância do n8n, mas por cada sistema conectado a ela.
Sobre o autor: Guillaume Valadon é Pesquisador Staff de Cibersegurança na GitGuardian, a plataforma de visibilidade e inteligência de segredos dedicada a proteger as credenciais que permitem que código, máquinas e agentes de inteligência artificial acessem sistemas e atuem como identidades confiáveis. Como invasores não precisam arrombar quando conseguem entrar com uma credencial válida, a GitGuardian encontra os segredos relevantes em toda a superfície de segredos, dentro e fora do perímetro, estejam eles em cofres, armazenados ou vazados. A plataforma revela seu contexto e raio de impacto e impulsiona a correção em escala antes que uma credencial se torne um caminho para uma violação. A solução é confiável para mais de 600.000 desenvolvedores e empresas, incluindo Snowflake, ING, BASF, Datadog, Qlik, Euronext e Orange.
