O n8n, plataforma de automação de fluxos de trabalho, entregava contas erradas no login. Em instâncias Enterprise configuradas para confiar em mais de um emissor externo de tokens, ele associava um JWT (JSON Web Token, token padrão usado para autenticação) recebido a um usuário local apenas pela claim (informação declarada no token) sub e ignorava a iss.
Um token válido do emissor A carregando um sub que pertence a alguém do emissor B fazia login como essa pessoa. A senha dela nem entrava na história. O n8n enviou a correção em 24 de junho.
A falha é registrada como CVE-2026-59208. O registro do CVE (Common Vulnerabilities and Exposures, identificador público de vulnerabilidades) não se tornou público até 9 de julho. O n8n credita o relatório à conta do GitHub bearsyankees, cujo perfil lista a Strix, que fabrica um agente de teste de penetração com IA (inteligência artificial).
A Strix afirma ter apontado o agente para o fluxo de token-exchange e encontrado a falha de vinculação de identidade ali.
Dois emissores, uma conta
Token exchange é a rota Enterprise do n8n para parceiros OEM (Original Equipment Manufacturer, fabricante original que integra o produto) que embarcam o produto, uma implementação do RFC 8693 (Request for Comments 8693, padrão de troca de tokens) que dispensa uma segunda tela de login para os usuários deles.
O parceiro assina um JWT de curta duração com sua própria chave, o n8n verifica contra uma chave pública configurada, associa as claims a uma conta local, e o usuário entra. As chaves confiadas vão em N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, e a documentação de implantação ainda marca o recurso como preview (versão de testes).
O token em si é válido. A associação é o problema. Um valor sub só tem garantia de ser único dentro do emissor que o emitiu. O RFC 7519 (Request for Comments 7519, padrão que define o JWT) pede que ele seja "limitado a ser localmente único no contexto do emissor" ou então globalmente único. O identificador de um usuário é, portanto, o par, iss mais sub.
O n8n usou apenas metade disso. Nada impede dois emissores de emitirem a mesma string de subject, e quando isso acontece, ambos aterrissam em uma mesma conta do n8n.
Qual a gravidade disso
A falha só atinge uma instância se o token exchange estiver ativado e a configuração confiar em pelo menos dois emissores externos. O n8n afirma que nada mais é afetado. O token exchange é exclusivo da versão Enterprise e ainda está marcado como preview, então o conjunto exposto é pequeno e específico: implantações OEM, onde confiar em um segundo emissor é uma configuração suportada.
O que o aviso não esclarece é como um atacante consegue o token. Diz apenas que eles podem obter um. A pergunta prática é se um usuário comum em um emissor confiável pode influenciar o sub que recebe. O registro público não responde. O vetor CVSS 4.0 (Common Vulnerability Scoring System, sistema de pontuação de vulnerabilidades) do GitHub marca os requisitos de ataque como presentes e para por aí.
O GitHub atribuiu esse vetor. Como CNA (CVE Numbering Authority, autoridade responsável por atribuir identificadores de CVE) aqui, ele coloca o CVE-2026-59208 em 7,6 no CVSS 4.0, alto. A NVD (National Vulnerability Database, base de dados nacional de vulnerabilidades dos EUA) coloca a mesma falha em 6,8 no CVSS 3.1, médio, e não emitiu nenhuma avaliação 4.0; o registro dela carrega CWE-287 (Common Weakness Enumeration 287, categoria de falha de autenticação) e CWE-346 (Common Weakness Enumeration 346, categoria de falha de origem). A avaliação SSVC (Stakeholder-Specific Vulnerability Categorization, categorização de vulnerabilidades por partes interessadas) da CISA (Cybersecurity and Infrastructure Security Agency, agência de segurança cibernética dos EUA) de 13 de julho registra a exploração como inexistente, e o The Hacker News não encontrou nenhuma prova de conceito pública em buscas em 16 de julho.
Duas semanas antes da correção de 24 de junho, os mantenedores corrigiram o CVE-2026-54305, outra falha exclusiva da versão Enterprise. Ele permite que qualquer usuário autenticado sobrescreva ou revogue os tokens OAuth (Open Authorization, protocolo aberto de autorização) armazenados de outro usuário pelos endpoints de Dynamic Credentials. Era uma verificação de propriedade ausente, não uma vinculação de identidade. Falha diferente, mesma superfície.
O The Hacker News procurou o n8n para confirmação sobre o escopo e o impacto do CVE-2026-59208 e atualizará esta reportagem com qualquer resposta.
Corrija ou reduza a lista de emissores
O CVE-2026-59208 afeta todas as versões do n8n anteriores à 2.27.4 e a versão 2.28.0. A correção chegou primeiro em 2.27.4 e 2.28.1. Esses são o piso mínimo. Em 16 de julho, o pacote npm (gerenciador de pacotes do Node.js) do n8n carregava 2.30.6 tanto em sua tag latest quanto stable. Segundo a própria empresa, ele lança uma nova versão menor na maioria das semanas, então verifique a tag e pegue a versão estável mais recente que sua implantação suporta.
Se a correção tiver que esperar
