O Inimigo Íntimo: CVE-2025-68613 e por que "Usuário Logado" não deveria significar "Dono do Servidor"

No mundo da segurança cibernética, vulnerabilidades "não-autenticadas" (como a recente Ni8mare) costumam roubar as manchetes. Afinal, a ideia de um hacker desconhecido invadindo seu servidor é aterrorizante.

Mas existe uma categoria de falhas que é igualmente perigosa, porém frequentemente subestimada por CTOs: a Escalação de Privilégio via RCE (Remote Code Execution).

A CVE-2025-68613, divulgada no final de 2025 e ainda afetando milhares de instâncias, é o exemplo perfeito disso. Ela provou que, no n8n, a distância entre "criar um workflow" e "virar root no servidor" era assustadoramente curta.

O Problema: A "Sandbox" que não segurava areia

O poder do n8n reside nas suas expressões. Quando você digita {{ $json.id }}, o n8n avalia isso como JavaScript. Para fazer isso com segurança, o n8n utiliza uma "Sandbox" — um ambiente isolado que deveria impedir que esse código acesse funções críticas do sistema operacional (como require('fs') ou child_process).

A CVE-2025-68613 revelou que essa sandbox tinha buracos.

Através de uma "Expression Injection" (Injeção de Expressão) especificamente formatada, um usuário autenticado consegue "escapar" da sandbox. Uma vez fora dela, ele tem acesso ao processo Node.js principal.

O Cenário de Ataque Realista

Muitos gestores pensam: "Mas eu confio na minha equipe, ninguém vai hackear a própria empresa."

Esse pensamento ignora dois vetores críticos:

1. Credenciais Comprometidas: Se o notebook de um desenvolvedor júnior for infectado por um InfoStealer e a senha do n8n vazar, o atacante não precisa mais explorar falhas complexas de firewall. Ele loga como o "Junior", cria um workflow com a expressão maliciosa e assume o controle total do servidor.
2. Workflows Importados: Se um desenvolvedor copia um template JSON de um fórum não confiável e o importa para o n8n, esse workflow pode conter a expressão maliciosa escondida. Ao clicar em "Execute", o ataque acontece.

Quem está vulnerável?

Praticamente todas as versões do n8n lançadas em 2024 e 2025 até o patch de correção.

• Vulneráveis: Versões >= 0.211.0 e < 1.120.4
• Corrigidas: 1.120.4, 1.121.1 e 1.122.0 (e superiores)

Se você está rodando uma versão antiga porque "está estável", você está sentado em cima de uma bomba relógio.

Como mitigar (além de atualizar)

Atualizar é obrigatório. Mas a n8nscale recomenda uma postura de defesa em profundidade para mitigar riscos futuros de RCE:

1. Isolamento de Rede (Egress Filtering): Mesmo que um atacante execute código, ele não deve conseguir baixar payloads externos ou enviar seus dados para fora. Bloqueie a saída de internet do container n8n para tudo que não for estritamente necessário.
2. Least Privilege no Sistema Operacional: Como mencionamos em posts anteriores, o n8n nunca deve rodar como root. Isso limita o dano que um RCE pode causar no sistema de arquivos.
3. Segregação de Ambientes: Não dê acesso de edição em Produção para toda a equipe. Use ambientes de Desenvolvimento e Homologação, e use pipelines de CI/CD para promover workflows para a Produção, onde o acesso humano direto é restrito.

A confiança nos seus usuários é importante, mas a segurança Zero Trust é melhor. Atualize seu n8n hoje.