n8n Enterprise sob alerta: falha de ligação de identidade entre emissores de confiança pode permitir iniciar sessão como outro usuário

n8n, a plataforma de automação de fluxos de trabalho, sistemaizou no final de junho um erro sério que permitia iniciar sessão como outro usuário sem conhecer sua senha quando a instância Enterprise tinha ativada a função de "token exchange" e confiava em mais de um emissor externo. Em termos técnicos a raiz do problema foi um ligação de identidade incorrecta: o sistema comparava apenas a claim "sub" do JWT entrante com usuários locais e não tomava em conta o "iss" (issuer)RFC 7519, e o fluxo de troca de tokens que n8n implementa segue RFC 8693.

Na prática, a falha significava que um token legítimo assinado por um emissor A que incluía um "sub" igual ao de um usuário criado pelo emissor B poderia ser aceito por n8n como se fosse esse outro usuário. O vetor de ataque concreto que permitiria a um atacante obter um token válido não está explicitado no aviso público; isso deixa incerteza sobre se um usuário normal em um dos emissores poderia forçar ou conseguir um "sub" determinado. As bases de dados públicas de vulnerabilidades refletem avaliações distintas: o CNA atribuiu uma pontuação alta em CVSS 4.0 enquanto NVD o catalogou com uma gravidade menor em CVSS 3.1. A CISA registrou a incidência e, de momento, não confirmou exploração ativa em campo.

O alcance técnico é, no entanto, bastante preciso: só afeta a implantaçãos Enterprise que tenham ativado o token exchange e que confiem em pelo menos duas chaves emissoras configuradas na variável N8N_TOKEN_EXCHANGE_TRUSTED_KEYS. Ou seja, a superfície exposta é reduzida e geralmente corresponder a implementações OEM ou integradas onde n8n aceita tokens assinados por parceiros. O n8n distribuiu o arranjo em versões concretas do produto; se o seu ambiente usa uma versão anterior, convém considerá-la vulnerável até que se atualize.

Se você administra ou depende de uma instância n8n Enterprise, as ações prioritárias são claras e urgentes: primeiro, verifique a versão que está correndo e planifique a atualização ao patch mais recente que inclua a correcção. Em paralelo, se você não puder corrigir imediatamente, reduza a exposição desativando a função de token exchange ou restringindo a configuração para confiar apenas em um único emissor. Localize e reveja a variável N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, confirme quem são os emissores de confiança e, se necessário, retire entradas desnecessárias até que a solução definitiva possa ser aplicada. Estas medidas de mitigação são temporárias e, como alertam os avisos técnicos, não substituem a atualização do software.

Mais medidas complementares de defesa incluem reforçar a telemetria e os registros: active e reveja os logs de autenticação e de token exchange em busca de logins incomuns, implemente alertas para sessões recém criadas com identidades externas, active autenticação multifator para as contas locais com privilégios e reduza permissões desnecessários em workflows e credenciais. Se sua implantação suporta registros de auditoria externos ou SIEM, exporte esses eventos para uma correlação mais ampla e para facilitar uma pesquisa posterior.

Esta vulnerabilidade não chega isolada: nas semanas anteriores n8n corrigiu outra falha Enterprise diferente que permitia manipular credenciais OAuth através de endpoints de credenciais dinâmicas, o que sugere que as implantaçãos com funcionalidades preview ou integrações OEM merecem uma revisão particular e contínua. Para seguir as comunicações oficiais e os adesivos, é conveniente não fixar apenas os changelogs habituais: o arranjo concreto de identidade nem sempre aparece nas notas de mudança dos pacotes, e a informação oficial pode residir no aviso de segurança ou na base de CVE. Mantenha um acompanhamento activo das fontes do fornecedor e dos repositórios de vulnerabilidades públicas como NVD e documentação do produto em causa a documentação do n8n.

Finalmente, avalie a necessidade de comunicar aos usuários afetados e de iniciar uma análise forense se houver indícios de acessos não autorizados. Embora não haja prova pública de exploração massiva por agora, o vetor permite acesso sem senha em condições concretas, e qualquer exposição de credenciais ou execuções inesperadas de workflows deve ser tratada como incidente potencial. A lição operacional é clara: quando confia em tokens externos, o código de ligação de identidades deve respeitar completamente o modelo iss+sub e as implementações que simplificam essa verificação estão em risco. Rever a configuração, aplicar adesivos e melhorar a monitorização são passos indispensáveis para mitigar o problema.