A plataforma de automação de fluxos de trabalho n8n entregava contas erradas no momento do login.
Em instâncias Enterprise configuradas para confiar em mais de um emissor externo de tokens, o sistema associava um JWT recebido a um usuário local apenas com base na claim sub e ignorava iss.
Na prática, isso permitia que um token válido emitido pelo emissor A, mas com um sub pertencente a alguém do emissor B, autenticassse o usuário como se fosse essa outra pessoa.
A senha não entrava em cena.
A correção foi liberada pela n8n em 24 de junho.
A falha é acompanhada como
CVE-2026-59208
.
O registro da CVE só foi tornado público em 9 de julho.
A n8n credita o relato à conta bearsyankees, no GitHub, cujo perfil informa a Strix, empresa que desenvolve um agente de teste de intrusão com IA.
Segundo a Strix, a ferramenta apontou o problema durante a análise do fluxo de troca de token e identificou ali o bug de vinculação de identidade.
Dois emissores, uma conta
A troca de token é a rota Enterprise da n8n para parceiros OEM que incorporam o produto.
Trata-se de uma implementação do RFC 8693 que evita uma segunda tela de login para os usuários.
Nesse fluxo, o parceiro assina um JWT de curta duração com sua própria chave, a n8n o verifica com uma chave pública configurada, cruza as claims com uma conta local e autentica o usuário.
As chaves confiáveis ficam em N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, e a documentação de implantação ainda classifica o recurso como versão prévia.
O token em si está correto.
O problema está na associação.
Um valor de sub só é garantidamente único dentro do emissor que o gerou.
O RFC 7519 pede que ele seja “restrito para ser localmente único no contexto do emissor” ou então globalmente único.
Portanto, o identificador de um usuário é o par iss mais sub.
A n8n considerava apenas metade disso.
Nada impede que dois emissores gerem a mesma string de sujeito e, quando isso acontece, ambos acabam mapeados para uma única conta na n8n.
O tamanho do problema
A falha só afeta uma instância quando a troca de token está ativada e a configuração confia em pelo menos dois emissores externos.
A n8n afirma que nada além disso é impactado.
Como a troca de token é exclusiva da edição Enterprise e ainda está marcada como versão prévia, o conjunto exposto é pequeno e específico, concentrado em implantações OEM nas quais confiar em um segundo emissor é uma configuração suportada.
O que o comunicado não esclarece é como o invasor obtém o token.
Ele apenas diz que isso é possível.
A questão prática é saber se um usuário comum, em um emissor confiável, consegue influenciar o valor de sub que recebe.
O registro público não responde a isso.
A matriz CVSS 4.0 do GitHub marca requisitos de ataque como presentes e encerra por aí.
O próprio GitHub atribuiu essa pontuação.
Como CNA neste caso, ele classificou a
CVE-2026-59208
com 7,6 no CVSS 4.0, o que representa risco alto.
Já o NVD atribuiu 6,8 no CVSS 3.1, risco médio, e ainda não publicou uma análise em CVSS 4.0.
O registro traz ainda CWE-287 e CWE-346.
Na avaliação SSVC da CISA em 13 de julho, a exploração aparece como inexistente, e não foram encontradas provas de conceito públicas em buscas realizadas em 16 de julho.
Duas semanas antes da correção de 24 de junho, os mantenedores também corrigiram a
CVE-2026-54305
, outra falha restrita à edição Enterprise.
Nesse caso, qualquer usuário autenticado podia sobrescrever ou revogar os tokens OAuth armazenados de outro usuário por meio dos endpoints Dynamic Credentials.
Era uma falha de verificação de propriedade, não de vinculação de identidade.
Bugs diferentes, mesma superfície.
Em contato com a n8n, o Caveira Tech aguarda confirmação sobre o escopo e o impacto da
CVE-2026-59208
e atualizará a reportagem se houver resposta.
Atualize ou reduza a lista de emissores
A
CVE-2026-59208
afeta todas as versões da n8n anteriores à 2.27.4 e também a 2.28.0.
A correção chegou primeiro nas versões 2.27.4 e 2.28.1.
Esse é o patamar mínimo seguro.
Em 16 de julho, o pacote npm da n8n já exibía a versão 2.30.6 nas tags latest e stable.
Segundo a própria empresa, há lançamentos menores novos quase toda semana, então vale conferir a tag e adotar o build estável mais recente compatível com o ambiente.
Se a atualização precisar esperar, é importante verificar a configuração em uso.
N8N_TOKEN_EXCHANGE_TRUSTED_KEYS armazena as chaves de assinatura confiáveis, e há uma flag separada, também em versão prévia, que controla se a troca de token está habilitada.
A saída mais prudente é reduzir para um único emissor confiável ou desativar o recurso.
O comunicado recomenda essas duas medidas temporárias, mas afirma que nenhuma delas elimina totalmente o risco.
A formulação é padrão e aparece em pelo menos outros três comunicados da n8n, incluindo o de 10 de junho.
Pela própria definição de escopo da empresa, uma instância com a troca de token desativada não é afetada.
As notas de versão não mencionam a correção.
Foram verificadas ambas.
Entre as mudanças listadas nas versões 2.27.4 e 2.28.1 estão uma correção de importação em Python, uma atualização do nó do Google Ads, uma verificação de fluxo de trabalho com IA e uma alteração na construção de nós, mas nada sobre identidade.
É no comunicado que essa correção aparece.
Para quem decide upgrades apenas com base em notas de versão, esse é o tipo de ajuste que passa despercebido.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...