O n8n se tornou, nos últimos anos, a verdadeira central de comando de empresas, equipes técnicas e entusiastas de automação self-hosted, conectando APIs, serviços em nuvem, bancos de dados e fluxos críticos de negócio em um único ambiente. Justamente por concentrar tantos tokens OAuth, chaves de API e dados sensíveis, a plataforma passou a ser um alvo extremamente lucrativo para cibercriminosos.
Recentemente, pesquisadores de segurança identificaram um grave ataque à cadeia de suprimentos envolvendo pacotes maliciosos publicados no npm, que se passam por nós legítimos do n8n com o objetivo de roubar credenciais OAuth de instâncias vulneráveis.
Neste artigo, você vai entender em detalhes como funciona esse ataque npm n8n, quais pacotes já foram identificados como maliciosos, por que a arquitetura dos nós comunitários amplia o risco e, principalmente, como proteger sua instância agora mesmo para evitar tokens OAuth roubados e possíveis comprometimentos mais profundos.
Como o ataque aos nós do n8n funciona
O ataque identificado explora uma combinação perigosa de engenharia social, typosquatting e limitações de segurança inerentes ao ecossistema de nós comunitários do n8n. Os criminosos publicam pacotes no npm com nomes longos, confusos e aparentemente legítimos, imitando integrações populares e induzindo o administrador a acreditar que se trata de um novo nó oficial ou de uma extensão confiável.
Em muitos casos, os pacotes maliciosos simulam integrações amplamente utilizadas, como Google Ads, serviços de marketing, CRMs ou plataformas de análise, exatamente os pontos onde residem credenciais OAuth de alto valor. Essa estratégia aumenta significativamente a taxa de sucesso do ataque, especialmente em ambientes onde a instalação de nós comunitários é feita de forma rápida, sem auditoria prévia.
Tecnicamente, o fluxo do ataque segue uma sequência clara. Primeiro, o administrador instala o nó malicioso diretamente pelo mecanismo de nós comunitários do n8n, acreditando tratar-se de uma extensão legítima. Em seguida, o código do pacote é carregado e executado com o mesmo nível de privilégio do processo principal do n8n, sem qualquer sandboxing efetivo.
A partir daí, o nó malicioso acessa o sistema interno de gerenciamento de credenciais do n8n, utilizando a chave mestra configurada na instância para descriptografar os segredos armazenados, incluindo tokens OAuth, refresh tokens e, em alguns casos, chaves de API de serviços críticos. Por fim, esses dados são silenciosamente exfiltrados para servidores controlados pelos atacantes, geralmente via requisições HTTP ofuscadas ou canais aparentemente legítimos.
Esse tipo de Supply Chain Attack é especialmente perigoso porque não depende da exploração de uma vulnerabilidade clássica no código do n8n, mas sim da confiança do usuário no ecossistema de pacotes do npm.
Lista de pacotes maliciosos identificados
Até o momento, diversos pacotes foram identificados como parte desse ataque à segurança no n8n, todos publicados no npm e projetados para se passar por nós comunitários legítimos. Entre os exemplos já analisados por pesquisadores estão n8n-nodes-hfgjf-irtuinvcm-lasdqewriit, n8n-nodes-gasdhgfuy-rejerw-ytjsadx, n8n-nodes-fgdfghjk-uqwepoiuyt, além de outras variações com padrões semelhantes de nomenclatura.
Os autores associados a esses pacotes também chamam atenção por utilizarem nomes fictícios ou referências a personagens populares, como kakashi-hatake, zabuza-momochi, itachi-uchiha e variações semelhantes, uma tentativa clara de criar múltiplas identidades e dificultar a atribuição direta do ataque.
É importante destacar que essa lista não deve ser considerada definitiva. Como se trata de um ataque ativo, novos pacotes podem surgir a qualquer momento, reforçando a necessidade de vigilância constante e de políticas restritivas para instalação de extensões comunitárias.
O perigo da falta de sandboxing nos nós comunitários
Um dos pontos mais críticos revelados por esse incidente é a ausência de isolamento efetivo entre os nós comunitários e o núcleo do n8n. Diferentemente de ambientes que utilizam sandboxing rigoroso ou permissões granulares, os nós da comunidade rodam com o mesmo nível de acesso que o servidor principal.
Na prática, isso significa que qualquer pacote instalado tem potencial para acessar variáveis de ambiente, arquivos de configuração, banco de dados interno e, mais grave ainda, o mecanismo de criptografia responsável por proteger credenciais sensíveis. Essa arquitetura transforma um simples erro de confiança em uma vulnerabilidade n8n de alto impacto.
Para ambientes self-hosted, onde o controle é total do administrador, essa liberdade pode ser vista como uma vantagem, mas também transfere toda a responsabilidade de segurança para o usuário. Um único nó malicioso é suficiente para comprometer toda a instância e, dependendo das integrações configuradas, gerar um efeito dominó em múltiplos serviços externos.
Como proteger sua instância do n8n
A primeira e mais eficaz medida de mitigação é desativar completamente o suporte a nós comunitários caso eles não sejam estritamente necessários. Isso pode ser feito de forma simples utilizando a variável de ambiente N8N_COMMUNITY_PACKAGES_ENABLED=false, o que impede a instalação e o carregamento de pacotes externos não oficiais.
Para ambientes onde o uso de nós comunitários é inevitável, a recomendação é adotar um processo rigoroso de auditoria. Antes de instalar qualquer pacote do npm, verifique manualmente o código-fonte, analise dependências suspeitas, procure por funções de rede não documentadas e avalie a reputação do autor, incluindo histórico de publicações e atividade recente.
Outra prática essencial é revisar periodicamente os logs do n8n, buscando conexões de saída inesperadas, erros incomuns ou execuções de código fora do fluxo normal de automação. Sempre que possível, execute o n8n em contêineres com permissões mínimas, limite o acesso à rede e isole o serviço de outros componentes críticos da infraestrutura.
Essas medidas não eliminam completamente o risco, mas reduzem significativamente a superfície de ataque e dificultam a exploração silenciosa de tokens OAuth roubados.
Conclusão e o futuro da segurança em automação
O ataque à cadeia de suprimentos envolvendo o n8n e pacotes maliciosos no npm serve como um alerta claro para toda a comunidade de automação e software livre. Em ambientes self-hosted, a flexibilidade e o poder caminham lado a lado com a responsabilidade total pela segurança.
Garantir a segurança no n8n exige uma postura ativa, desconfiada e contínua, especialmente quando se trata de extensões comunitárias e integrações de terceiros. A tendência é que ataques desse tipo se tornem cada vez mais sofisticados, explorando justamente os pontos de confiança criados para facilitar a vida do desenvolvedor.
Como chamada à ação, verifique imediatamente sua instância do n8n, revise os pacotes instalados, analise logs recentes e, se necessário, revogue e regenere credenciais OAuth potencialmente expostas. Compartilhar esse alerta com sua equipe e com a comunidade pode evitar que outras instâncias sejam comprometidas e fortalecer o ecossistema como um todo.