Aviso de segurança: n8n corrige vulnerabilidade que permitia a editores de workflows executar comandos no servidor

O n8n libertou adesivos para uma vulnerabilidade de escape do sandbox de expressões que permite a um editor autenticado de workflows executar comandos do sistema operacional no servidor que aloja a plataforma de automação. A falha afeta versões anteriores a 2.31.5 e a série 2.32.0 até 2.32.0 inclusive; as correções estão em 2.31.5 e 2.32.1, e o problema está registrado no GitHub como GHSA-gv7g-jm28-cr3m com uma pontuação CVSS 4.0 de 8.7. O fornecedor publicou os lançamentos adesivos em 22 de julho após receber o relatório dos pesquisadores em 15 de julho; não havia CVE atribuído a 27 de julho de 2026.

Do ponto de vista técnico, o vetor aproveita duas fraquezas combinadas no reescritor da árvore de sintaxe abstrata (AST) que n8n usa para transferir identificadores de JavaScript para um contexto controlado pela plataforma. A primeira é uma omissão no manejo de ArrowFunctionExpression, que permitia que uma forma concisa de uma arrow function - por exemplo () => process— resolvesse o identificador contra o runtime de Node.js em vez do contexto seguro. A segunda é uma verificação de propriedades que apenas inspecionava nomes estáticos em expressões-membro, ignorando que funções como Reflect.get podem receber a propriedade solicitada como argumento e ser usadas para recuperar módulos integrados e executar child_process.

A combinação desses dois erros permitiu aos pesquisadores recuperar process.getBuiltinModule, carregar child_process e executar comandos com os privilégios do processo n8n. A exploração requer apenas uma conta válida com permissão para criar ou modificar workflows; não depende da interação de outro usuário. Um ataque bem sucedido pode expor a variável N8N_ENCRYPTION_KEY e com isso decifrar credenciais armazenadas em n8n, bem como abrir caminhos para bases de dados, serviços internos e endpoints na nuvem acessíveis a partir do host.

Além da técnica, este incidente destaca uma lição recorrente para plataformas low-code/no-code e automations: que podem editar fluxos são objetivos de alto valor. Permitir que usuários com acesso à construção de workflows tenham entrada livre para scripts embebidos ou expressões aumenta a superfície de ataque. A segurança operacional exige combinar adesivos rápidos com controlos de acesso fortes e políticas de segredos e privilégios.

Como medidas imediatas, a recomendação-chave é actualizar as versões corrigidas (2.31.5 ou 2.32.1) em todas as instâncias afectadas em vez de confiar apenas nas mitigações provisórias que n8n descreve no seu aviso. Essas mitigações – restringir o acesso à edição de workflows a usuários completamente de confiança – são úteis como medida temporária, mas o vendor as qualifica como incompletas e de curto prazo.

Após a atualização, é conveniente realizar uma revisão de alcance: inspeccionar workflows criados ou modificados recentemente em busca de arrow functions concisas ou JavaScript ofuscado, auditar os logs do host para processos filhos não esperados (bash, sh, PowerShell, curl, wget ou outros invocados por Node.js/n8n) e procurar atividades de decifração ou acessos a recursos sensíveis. Se for detectada uma execução suspeita, o N8N_ENCRYPTION_KEY deve ser rotatado, rodar credenciais armazenadas e auditar as contas e acessos envolvidos, pois o risco de pivot para serviços internos ou APIs na nuvem é real.

Em termos de mitigação a médio e longo prazo, as organizações deveriam aplicar controle de acesso baseado em papéis e autenticação forte (MFA/SSO) para separar claramente os construtores de workflows das contas que só consomem máquinas. Também é recomendável minimizar os privilégios que as credenciais armazenadas em n8n têm nos sistemas conectados, empregar credenciais de alcance limitado ou temporários quando possível, e segmentar a rede para reduzir o alcance de um host comprometido.

O incidente também evidencia a importância dos testes de segurança de componentes que manipulam código ou sintaxe (parsers, reescritores AST, sandboxes). Segundo os pesquisadores, nenhuma das duas condições exploradas estava coberta por testes automatizados, o que facilitou a regressão após um acordo prévio em fevereiro (CVE-2026-27577) destinado a fechar um escape semelhante. As organizações fornecedoras destas plataformas devem melhorar os testes de segurança e as revisões de código para casos-limite.

Se utilizar n8n Cloud, verifique com o fabricante se o seu ambiente hospeda a versão vulnerável: o aviso público não especificou o estado de n8n Cloud. Para referências e detalhes técnicos do aviso e do seguimento, consulte a entrada do advisory no GitHub GHSA-gv7g-jm28-cr3m e a página de lançamentos oficiais onde aparecem as versões corrigidas Releases de n8n no GitHub. Para contexto jornalístico e relatórios de terceiros, você pode revisar coberturas e análises em meios especializados como The Hacker News thehackernews.com.

Em resumo: atualize sem demora, não confie apenas em mitigações administrativas, audite mudanças recentes em workflows e segredos, e trate as contas de edição de workflows como ativos críticos em sua política de segurança. A combinação de sistemas técnicos, restrições de acesso e uma resposta forense rápida é a melhor defesa contra este tipo de escape do sandbox.