Quem roda infra sabe: o elo mais fraco quase nunca é o seu core, é a ferramenta de apoio que você conecta por conveniência. Foi isso que aconteceu com o n8n. A equipe confirmou que o Metabase, usado internamente para analytics, foi comprometido em 3 de agosto de 2026, e o time só ficou sabendo três dias depois, em 6 de agosto.
A investigação, feita em conjunto com o time de segurança do próprio Metabase mais os times legal e de dados do n8n, apurou que um terceiro não autorizado conseguiu rodar queries dentro desse ambiente. O detalhe técnico interessante (e frustrante para quem investiga) é que as consultas retornavam um conjunto de linhas variável e não determinístico a cada execução. Na prática, isso significa que dá para saber o que estava exposto, mas não dá para afirmar com certeza quais registros específicos foram efetivamente lidos.
O que realmente foi acessado
No total, 136 registros com nomes e e-mails foram expostos, somando contas self-hosted e n8n Cloud. Desse grupo, 5 registros tinham hash bcrypt de senha de contas Cloud. Vale reforçar um ponto que qualquer arquitetura self-hosted deveria garantir por padrão: senhas de instâncias self-hosted nunca são compartilhadas com o n8n, então esse vetor específico fica fora do jogo para quem roda a própria infra.
A investigação também desenterrou um bug antigo, já corrigido via pull request público, que fazia um pequeno número de senhas de contas Cloud ficarem armazenadas em texto puro. O time considera improvável que esses registros tenham sido tocados neste incidente, mas mesmo assim contatou as 25 contas afetadas por precaução. Esse é o tipo de decisão que separa resposta a incidente séria de nota de imprensa genérica.
O que foi feito
- Metabase aplicou o patch da vulnerabilidade e derrubou as sessões ativas usadas no ataque
- Credenciais envolvidas no incidente foram revogadas
- O n8n auditou logs próprios e rotacionou credenciais potencialmente expostas
- Usuários afetados pelo bug histórico de senha em texto puro foram corrigidos
- O DPO da empresa e o órgão regulador de proteção de dados de Berlim foram notificados
Reset de senha não é burocracia depois de um incidente assim, é a ação mínima viável enquanto você não sabe exatamente quais linhas foram lidas.
Se você recebeu e-mail direto do n8n sobre isso, o caminho é seguir a instrução ali e trocar a senha. Se não recebeu, trocar mesmo assim custa dois minutos e elimina uma variável de risco. Para quem mantém pipelines de automação conectados a ferramentas de terceiros, o caso serve de lembrete prático: cada integração interna que você pluga no seu stack aumenta a superfície de ataque, e vale revisar periodicamente quem tem acesso a quê.
Fonte: https://blog.n8n.io/metabase-security-incident-update/