Pesquisadores da GitGuardian encontraram 321 instâncias do n8n que aceitavam API tokens expostos em commits públicos do GitHub e demonstraram quatro formas de invasores usarem essas credenciais para acessar dados sensíveis e segredos downstream sem explorar uma vulnerabilidade de software.
A varredura em commits públicos do GitHub identificou 4.576 credenciais únicas associadas a 1.255 hostnames.
Das 896 instâncias alcançáveis no momento dos testes, 321 aceitaram ao menos um token vazado.
Isso significa que credenciais vazadas deram acesso autenticado a 36% das instâncias alcançáveis testadas, ou cerca de 26% de todos os hostnames identificados nos commits.
O impacto vai muito além do n8n.
Organizações usam a plataforma de automação para conectar bancos de dados, repositórios de código-fonte, ambientes em cloud, serviços de IA, plataformas de suporte ao cliente e outros sistemas internos.
Um token do n8n com privilégios suficientes pode expor definições de workflows e dados de execução, permitir que invasores usem credenciais armazenadas e, em algumas configurações, até extrair os valores originais dessas credenciais.
Para medir o possível raio de impacto, os pesquisadores reproduziram quatro técnicas práticas de ataque em um ambiente controlado do n8n.
Cada uma exigiu apenas funcionalidades documentadas da REST API e requisições HTTP padrão.
Não foi necessário explorar nenhum CVE nem usar ferramentas especializadas.
Por que o n8n é um alvo valioso
O n8n é uma plataforma de automação de workflows de código aberto e low-code, com suporte a agentes de IA e centenas de integrações nativas.
Empresas a utilizam para conectar ferramentas internas, automatizar pipelines, implementar lógica de negócios e orquestrar integrações de API em seus ambientes tecnológicos.
A plataforma pode ser hospedada pela própria organização ou implantada por meio do n8n.cloud, e seu repositório open source já soma quase 200.000 estrelas no GitHub.
Uma instância do n8n executa workflows compostos por nodes.
Alguns nodes disparam workflows em horários definidos ou por meio de webhooks, enquanto outros transformam dados, executam código ou se conectam a serviços externos usando credenciais armazenadas, como chaves de API, tokens e senhas de banco de dados.
Essas credenciais são criptografadas em repouso com um segredo mestre chamado N8N_ENCRYPTION_KEY.
Mas o n8n ainda precisa descriptografá-las e usá-las sempre que um workflow é executado.
Assim, um invasor com privilégios de API suficientes pode referenciar essas credenciais em novos workflows e fazer com que a instância as use em seu nome.
Com mais de 100.000 instâncias visíveis no Shodan e mais de 50 advisories de segurança publicados desde janeiro de 2026, o n8n passou a receber o mesmo nível de atenção de outras plataformas de integração de alto valor.
Em 31 de março de 2026, 58% das instâncias escaneadas executavam uma versão afetada por pelo menos um advisory de segurança conhecido.
Vários CVEs recentes permitiam escapar de sandbox de execução e obter 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ões com pontuação CVSS de 9,9, foi incluído no catálogo Known Exploited Vulnerabilities da CISA em 11 de março de 2026, confirmando exploração em ambiente real.
Tokens de API vazados criam um risco separado.
Um invasor não precisa necessariamente explorar uma vulnerabilidade do n8n se uma credencial válida já fornecer acesso autenticado à instância.
Encontramos 321 instâncias aceitando tokens vazados
A GitGuardian Public Monitoring varre fontes públicas em busca de credenciais expostas.
Para esta pesquisa, foram coletados todos os API tokens do n8n que ela havia identificado em commits públicos do GitHub desde abril de 2025.
O pipeline extraiu o hostname do n8n registrado ao lado de cada token, enviou uma requisição de validação somente leitura à instância associada e registrou a resposta.
A varredura resultou em:
| Etapa | Quantidade |
| --- | ---: |
| API tokens únicos | 4.576 |
| Commits no GitHub contendo tokens | 5.469 |
| Hostnames únicos extraídos | 1.255 |
| Instâncias publicamente alcançáveis | 896 |
| Instâncias aceitando um token vazado | 321 |
As 321 instâncias confirmadas representam aproximadamente 36% das 896 instâncias alcançáveis e 26% dos 1.255 hostnames identificados nos commits.
Aplicou-se o mesmo processo às chaves da Model Context Protocol API do n8n encontradas no mesmo conjunto de commits.
Os tokens MCP permitem que assistentes de IA acionem workflows do n8n por meio do Model Context Protocol, o que os torna uma superfície de exposição mais recente que a REST API.
Das 372 chaves MCP identificadas, sete ainda eram válidas no momento dos testes, ou cerca de 2%.
Por que tokens vazados do n8n podem continuar válidos
Uma chave de API do n8n é um JSON Web Token assinado com a declaração de audiência "aud": "public-api".
Um token decodificado se parece com isto:
```json
{
"sub": "efdf9cca-049a-46aa-afdc-172f0824f6cb",
"iss": "n8n",
"aud": "public-api",
"jti": "aac8a7a8-c8c4-4855-8e8b-2806e90b16e1",
"iat": 1781551662
}
```
O token registra seu momento de emissão na declaração iat.
Chaves de API antigas do n8n frequentemente não incluem a declaração exp, que define quando expiram.
O n8n passou a adotar uma expiração padrão de 30 dias na versão 1.78.0, em fevereiro de 2025, mas muitos dos tokens encontrados na pesquisa haviam sido gerados sem data de expiração.
Uma chave comitada no GitHub meses antes poderia, portanto, continuar utilizável até que alguém a apagasse ou revogasse explicitamente.
Na prática, as chaves de API do n8n se comportam de forma diferente de JWTs autossuficientes, que podem ser validados apenas por assinatura.
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 exige apenas uma requisição somente leitura com a chave enviada no cabeçalho X-N8N-API-KEY:
```bash
curl -s -o /dev/null -w "%{http_code}" \
-H "X-N8N-API-KEY: <token>" \
https://n8n.example.com/api/v1/workflows
```
GET /api/v1/workflows retorna as definições de workflows 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 faz alterações na instância alvo.
A URL da instância costuma ser cometida ao lado do token
Uma chave de API do n8n só é útil se o invasor conseguir identificar a instância que a aceita.
Em commits públicos do GitHub, porém, o hostname e o token frequentemente aparecem juntos.
Um arquivo .env é um exemplo comum:
```env
N8N_URL="https://n8n.redacted.cloud:5678"
N8N_API_KEY="eyJhREDACTEDPWw4"
```
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 shell permitidos em .claude/settings.json ou .claude/settings.local.json. Quando usuários configuram o Claude Code para interagir com o n8n, podem colocar tanto a URL da instância quanto a chave de API diretamente em um comando curl aprovado.
```bash
curl -s "https://automation.redacted.fr/api/v1/workflows" \
-H "X-N8N-API-KEY: eyJhREDACTEDegE"
```
Esses arquivos de configuração podem então ser comitados em um repositório sem as mesmas proteções de .gitignore normalmente aplicadas a arquivos .env.
A mesma combinação de hostname e token apareceu com vários outros nomes de variáveis, incluindo:
N8N_MCP_URL
N8N_WEBHOOK_BASE_URL
process.env.N8N_URL
os.getenv("N8N_HOST", "...")
Como o hostname geralmente estava disponível no mesmo commit que o token, o pipeline não precisou de uma etapa separada de descoberta de infraestrutura.
O que um token autenticado do n8n expõe
Um token de API do n8n concede 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 da instância ou administradores, provavelmente porque eram esses os usuários configurando as integrações e comitando as chaves.
Dependendo da função da conta, a REST API pública pode expor:
- GET /api/v1/users: nomes de usuário, endereços de e-mail, datas de criação da conta e convites pendentes.
Algumas informações são restritas ao proprietário da instância.
- GET /api/v1/workflows: definições completas de workflows, incluindo configuração de nodes, código JavaScript ou Python em nodes de código, consultas SQL e segredos hardcoded nos parâmetros do workflow.
- GET /api/v1/credentials: nomes das credenciais, tipos e informações de compartilhamento, mas não os valores subjacentes.
Esse endpoint é restrito a proprietários e administradores.
- GET /api/v1/executions: histórico de execução dos workflows.
A inclusão de ?includeData=true pode retornar a carga útil completa de entrada e saída de cada execução.
- GET /api/v1/data-tables: linhas de tabelas visíveis para o usuário autenticado.
- GET /api/v1/variables: nomes das variáveis e seus conteúdos.
Esse endpoint é restrito a proprietários e administradores.
As definições de workflow criam a exposição mais imediata porque a API retorna a configuração completa dos nodes.
Se um desenvolvedor colocou uma chave de API ou token diretamente em um parâmetro de node, 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 demonstram os testes controlados, um invasor com permissão para criar e executar workflows pode referenciar uma credencial armazenada e fazer o n8n usá-la ou transmiti-la.
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:
```bash
curl -H "X-N8N-API-KEY: $JWT" \
-d "{}" \
-H "Content-Type: application/json" \
https://$N8N_INSTANCE/api/v1/audit
```
A resposta pode identificar:
- Possíveis exposições a SQLi em workflows
- Nodes com acesso ao sistema de arquivos
- Webhooks sem proteção
- A versão em execução do n8n, que pode ser comparada com CVEs conhecidos
- Credenciais não usadas
- Nodes de alto risco ou instalados pela comunidade
- Recursos de segurança ativados
- Listas de permissão e de bloqueio de nodes
- 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, elas podem fornecer um mapa priorizado dos caminhos de ataque mais promissores na instância.
Quatro técnicas de ataque contra uma instância totalmente atualizada
A GitGuardian não aplicou as técnicas de exploração abaixo contra sistemas de terceiros expostos.
Elas foram reproduzidas em uma implantação controlada do n8n construída especificamente para a pesquisa.
O workflow de teste continha três fraquezas deliberadas:
- Um formulário web armazenava envios em uma tabela de dados acessível por workflows autenticados.
- Um node OpenAI processava cada envio usando um objeto de credencial armazenado.
- Um node HTTP Request publicava a saída no GitHub usando um token hardcoded nos parâmetros do node.
Usando esse ambiente, os pesquisadores demonstraram quatro técnicas, indo de enumeração passiva à exfiltração ativa de credenciais.
Exemplo de workflow do n8n
Técnica 1: Enumerar a instância
GET /api/v1/users retornou quatro contas: o proprietário da instância, dois usuários ativos e um registro pendente.
GET /api/v1/workflows retornou nove definições completas de workflow.
No workflow alvo, os parâmetros de um node HTTP Request continham um token do GitHub em texto claro.
Essa primeira técnica não exigiu modificação de workflow.
As informações expostas já estavam disponíveis por meio das operações de leitura permitidas à conta autenticada.
Técnica 2: Usar uma credencial armazenada do OpenAI
GET /api/v1/credentials listou todos os objetos de credencial armazenados, incluindo um chamado "OpenAI account".
O endpoint revelou nome, tipo e identificador, mas não a própria chave de API.
Os pesquisadores criaram um workflow com um gatilho de Schedule e um node OpenAI referenciando a credencial pelo ID e então o ativaram.
Dois truques tornam isso possível.
O gatilho de Schedule dispara automaticamente após cerca de 10 segundos, dando tempo para o workflow ser concluído.
Em seguida, GET /api/v1/executions?includeData=true recupera o registro completo da execução.
Como o n8n persiste a saída completa de cada node, a resposta do OpenAI aparece em texto claro.
Os pesquisadores conseguiram executar prompts arbitrários no OpenAI usando a credencial armazenada na instância sem nunca ver seu valor.
Técnica 3: Ler a tabela de dados
Os mesmos dois truques se aplicam.
Eles criaram um workflow com um gatilho de Schedule e um node Data Table configurado para recuperar todas as linhas, e então o ativaram.
GET /api/v1/executions?includeData=true retornou o registro da execução segundos depois, com todas as linhas em texto claro.
Quatro linhas foram exfiltradas, incluindo nomes, endereços de e-mail, respostas de formulário e status de processamento.
O workflow foi então apagado.
Técnica 4: Exfiltrar a credencial bruta do OpenAI
A quarta técnica foi além do uso de uma credencial armazenada e extraiu seu valor subjacente.
Os pesquisadores iniciaram um listener HTTP e, em seguida, criaram um workflow com um gatilho de Schedule e um node HTTP Request.
O truque principal é que o node HTTP Request pode usar uma credencial armazenada do n8n como método de autenticação enquanto envia requisições para qualquer URL.
Eles configuraram o node para usar a credencial armazenada do OpenAI e o apontaram para o listener.
Quando o workflow foi disparado, o n8n anexou o valor da credencial como um Bearer token no cabeçalho Authorization de saída.
O listener capturou a chave de API bruta segundos após a ativação.
O workflow foi então apagado.
Juntas, essas técnicas mostram como um invasor pode evoluir de um token vazado do n8n para uma exposição mais ampla de credenciais e dados usando funcionalidades legítimas da plataforma:
- Enumerar usuários, workflows e a configuração de segurança.
- Identificar objetos de credenciais armazenadas e segredos hardcoded.
- Usar credenciais armazenadas sem ver seus valores.
- Ler dados disponíveis para workflows.
- Fazer o n8n transmitir uma credencial armazenada para uma infraestrutura controlada pelo invasor.
A exclusão do workflow malicioso também removeu os registros de execução associados da interface, o que pode deixar os defensores com evidências limitadas para investigação.
Workflows reais mostraram fraquezas semelhantes
A demonstração controlada não foi baseada em uma configuração puramente teórica.
Durante a pesquisa, os pesquisadores encontraram instâncias reais do n8n com padrões de exposição semelhantes.
Um workflow fazia backup automático das próprias definições para um repositório público no GitHub.
Uma chave de implantação SSH havia sido hardcoded diretamente em um dos nodes.
O histórico do Git do repositório continha versões anteriores de todos os workflows, e a chave SSH continuava válida.
Na prática, o workflow estava publicando sua própria configuração sensível e suas credenciais sempre que era executado.
O caso ilustra por que plataformas de automação de workflows podem ampliar de forma incomum o raio de impacto.
Elas ficam entre vários sistemas, processam dados sensíveis e autenticam rotineiramente serviços externos.
Uma fraqueza em um único workflow pode expor acessos muito além da própria plataforma de automação.
A divulgação responsável teve respostas limitadas
Encontrar uma credencial vazada válida é apenas o primeiro passo.
O risco persiste até que a organização afetada a revogue e trate qualquer exposição downstream.
Os pesquisadores tentaram a divulgação responsável com sete organizações:
- Três provedores de hospedagem associados coletivamente a cerca de 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 bug bounty, 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, disse estar ciente dos problemas e planejar corrigi-los, e posteriormente fechou os chamados.
Até o momento da publicação, a GitGuardian não havia confirmado de forma independente que as correções relacionadas tinham sido lançadas.
Aproximadamente 30% das 321 instâncias afetadas estavam hospedadas no n8n.cloud ou em serviços gerenciados semelhantes.
A 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.
Publicidade
Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...