A vulnerabilidade CVE-2025-68668, avaliada com CVSS 9.9, afeta versões do n8n anteriores à 2.0.0 e quebra o isolamento do Python Code Node baseado em Pyodide.
| Componente | n8n, especificamente o Python Code Node com execução baseada em Pyodide em versões de 1.0.0 até antes da 2.0.0 |
| Vetor | usuário autenticado com permissão para criar ou modificar workflows consegue abusar da falha de sandbox para alcançar capacidades do host |
| Impacto | execução de comandos arbitrários no sistema operacional do host com os mesmos privilégios do processo n8n |
| Prioridade | atualizar para o n8n 2.0.0 ou desabilitar temporariamente o Code Node, o suporte a Python ou migrar para o runner nativo com isolamento reforçado |
| Versões | afetadas de 1.0.0 até antes de 2.0.0; correção indicada na versão 2.0.0 |
| Artefatos | CVE-2025-68668, codinome N8scape, Pyodide, Python Code Node, NODES_EXCLUDE, N8N_PYTHON_ENABLED, N8N_RUNNERS_ENABLED, N8N_NATIVE_PYTHON_RUNNER |
Uma vulnerabilidade crítica no n8n permite que um usuário autenticado, desde que tenha permissão para criar ou modificar workflows, execute comandos arbitrários no sistema operacional do host onde a plataforma está em execução. A falha é rastreada como CVE-2025-68668, recebeu pontuação CVSS 9.9 e foi descrita como uma falha de mecanismo de proteção. O ponto central não é um acesso anônimo à instância, mas a quebra de uma barreira de confiança interna: uma funcionalidade que deveria limitar a execução de código Python dentro de um ambiente controlado pode ser desviada para alcançar o processo n8n e, por consequência, o host.
O componente afetado é o Python Code Node que usa Pyodide. Em versões do n8n de 1.0.0 até antes da 2.0.0, esse modelo de execução dependia de uma sandbox que bloqueava algumas funções consideradas perigosas, mas não removia completamente as capacidades subjacentes que poderiam levar à execução fora do limite pretendido. A exploração, portanto, depende de uma conta já autenticada e autorizada a alterar workflows, mas o impacto é elevado porque a execução ocorre com os privilégios do processo n8n, o que pode ampliar o dano em ambientes onde a aplicação roda com permissões excessivas, acesso a integrações sensíveis ou variáveis de ambiente contendo segredos operacionais.
A correção foi disponibilizada no n8n 2.0.0. A plataforma também havia introduzido, a partir da versão 1.111.0, uma implementação de Python nativo baseada em task runners como recurso opcional para melhorar o isolamento. Na versão 2.0.0, essa abordagem passou a ser o padrão. Para ambientes que não conseguem atualizar imediatamente, as medidas de contenção mencionadas envolvem desabilitar o Code Node, desabilitar suporte a Python nesse nó ou configurar o uso do runner nativo com as variáveis de ambiente específicas. Essas ações reduzem a superfície de execução de código dentro de workflows até que a atualização definitiva seja aplicada.
A falha ocorre em torno do limite entre o código Python executado no workflow e o ambiente do processo n8n. O Pyodide oferece uma forma de executar Python em um contexto controlado, e a sandbox do n8n deveria impedir que scripts inseridos por usuários alcançassem funções ou caminhos capazes de interagir com o sistema operacional. O problema descrito é estrutural: o modelo de bloqueio tenta enumerar elementos arriscados, mas mantém capacidades internas acessíveis por caminhos alternativos. Quando um invasor autenticado já possui permissão para alterar workflows, essa condição cria uma rota para escapar do isolamento planejado.
O detalhe técnico adicional divulgado aponta que a fuga da sandbox pode envolver capacidade interna relacionada a _pyodide._base.eval_code(). O ponto defensivo relevante é que o bloqueio de uma lista pequena de funções perigosas não equivale à remoção efetiva das capacidades de execução. Em um ambiente de automação como o n8n, workflows frequentemente manipulam credenciais de integrações, tokens de serviços, conexões com bancos de dados, webhooks e chamadas para APIs corporativas. Mesmo sem afirmar acesso a qualquer dado específico, a execução de comandos no host com os privilégios do processo amplia o risco operacional para além do workflow isolado.
A exploração bem-sucedida não foi apresentada como remota sem autenticação. As precondições importam: a conta precisa estar autenticada e possuir direito de criar ou modificar workflows. Ainda assim, essa exigência não torna a falha baixa prioridade, porque muitas implantações de ferramentas de automação concedem permissões de edição a equipes internas, contas de integração ou usuários de múltiplos times. Em cenários de credenciais comprometidas, conta interna mal configurada ou abuso por usuário com privilégio funcional, a vulnerabilidade transforma permissão de workflow em execução de comandos no host, mudando o limite de impacto.
A superfície afetada inclui instâncias do n8n em versões de 1.0.0 até antes da 2.0.0 que permitem uso do Python Code Node baseado em Pyodide. O risco aumenta quando usuários não administradores têm permissão para criar ou modificar workflows, quando ambientes compartilham a mesma instância entre equipes com diferentes níveis de confiança ou quando a execução do processo n8n ocorre com privilégios amplos no sistema operacional. A vulnerabilidade também exige atenção em ambientes auto-hospedados, contêineres, servidores de automação internos e integrações que concentram segredos operacionais no mesmo runtime.
A mudança de arquitetura indicada pelo n8n é relevante para a avaliação da exposição. A implementação de Python nativo baseada em task runners foi introduzida como opção na versão 1.111.0 e tornou-se padrão na versão 2.0.0, com objetivo de melhorar o isolamento. Organizações que permaneceram em versões anteriores ou que mantiveram configurações compatíveis com o modelo antigo devem tratar o Code Node como uma superfície de execução sensível, não apenas como um recurso de automação. A existência de outra vulnerabilidade crítica, CVE-2025-68613, também relacionada a execução de código sob certas circunstâncias, reforça a necessidade de revisar a postura de atualização da plataforma.
A análise de impacto deve considerar a identidade do processo n8n no host. Se o serviço executa com privilégios restritos e sem acesso amplo a arquivos, rede interna e variáveis sensíveis, o dano potencial fica mais contido. Se o processo tem acesso a diretórios persistentes, credenciais de integrações, rede lateral ou mecanismos de execução auxiliares, a execução de comandos pode se tornar uma etapa de comprometimento mais grave. O limite confirmado no material é execução com os mesmos privilégios do processo n8n, não uma elevação automática para administrador ou comprometimento de dados confirmado.
- Instâncias n8n de 1.0.0 até antes de 2.0.0 com Python Code Node disponível.
- Usuários autenticados com permissão para criar ou modificar workflows.
- Ambientes em que o processo n8n possui acesso a integrações, variáveis de ambiente ou recursos locais sensíveis.
- Implantações que ainda não adotaram a versão 2.0.0 ou o runner nativo de Python baseado em task runners.
A investigação deve começar pelo inventário de versões e pela revisão de permissões de workflow. Equipes de defesa devem identificar quais instâncias executam versões afetadas, quais usuários ou contas de serviço podem criar e modificar workflows e quais workflows usam Code Node com Python. O objetivo não é apenas localizar a versão vulnerável, mas entender se existe caminho prático para uma conta autenticada acionar execução de código em um ambiente com impacto relevante. Logs de autenticação, alterações de workflow e eventos administrativos são pontos centrais para reconstruir atividade suspeita.
Na camada de aplicação, vale procurar criação ou alteração incomum de workflows próximos a eventos de execução do Code Node, especialmente quando a alteração parte de contas que normalmente não mantêm automações com Python. Na camada de host, a telemetria deve correlacionar o processo n8n com criação de subprocessos, chamadas inesperadas ao sistema operacional, acesso incomum a arquivos de configuração e conexões de rede iniciadas logo após a execução de workflows. Como não há IoCs específicos fornecidos, a abordagem mais confiável é baseada em comportamento e sequência temporal.
Em ambientes conteinerizados, a investigação deve observar logs do contêiner, eventos do runtime e qualquer tentativa de acessar caminhos montados ou variáveis de ambiente sensíveis. Em servidores tradicionais, o foco deve incluir processos filhos do serviço n8n, alterações em arquivos relacionados à aplicação e conexões de saída não usuais. A presença de workflows recém-criados, editados fora de janela de mudança ou contendo nós de código com finalidade pouco clara deve ser tratada como sinal de revisão manual, principalmente se a instância ainda estiver em versão vulnerável.
- Versão do n8n em execução e presença de builds anteriores à 2.0.0.
- Workflows novos ou modificados por contas com permissão de edição e uso do Python Code Node.
- Processos filhos inesperados, gerados pelo processo n8n, após execução de workflows.
- Acesso incomum a variáveis de ambiente, arquivos de configuração ou diretórios persistentes ligados ao serviço.
- Conexões de saída iniciadas pelo host n8n em sequência temporal com execução de workflows.
A medida principal é atualizar o n8n para a versão 2.0.0, onde a falha foi corrigida e a implementação de Python baseada em task runners passa a ser o padrão. Antes da atualização, a equipe deve mapear dependências de automação, validar compatibilidade dos workflows e planejar uma janela de mudança proporcional ao uso da plataforma. Como o impacto envolve execução de comandos no host, a atualização deve ser acompanhada de revisão de permissões do processo n8n, com redução de privilégios quando possível e separação clara entre a aplicação, seus dados persistentes e segredos de integrações.
Quando a atualização imediata não for viável, as contenções documentadas reduzem a superfície explorável. Uma opção é excluir o Code Node por meio de NODES_EXCLUDE; outra é desabilitar suporte a Python no Code Node com N8N_PYTHON_ENABLED; também é possível configurar o uso do sandbox de Python baseado em task runner com N8N_RUNNERS_ENABLED e N8N_NATIVE_PYTHON_RUNNER. Essas mudanças devem ser tratadas como controles temporários ou de endurecimento, não como substituição permanente da atualização, porque a correção de versão continua sendo a referência mais direta.
Após aplicar correção ou contenção, a resposta deve incluir revisão de workflows existentes, auditoria de contas com permissão de edição e análise retroativa de eventos suspeitos. Workflows que usam Python devem ser reavaliados, especialmente se foram alterados por contas inesperadas. Também é prudente revisar segredos acessíveis ao processo n8n, rotacionar credenciais quando houver indício de execução suspeita e validar que logs de autenticação, alteração de workflow e execução estão retidos por tempo suficiente para investigação. A prioridade operacional é impedir que uma permissão funcional de automação continue podendo se converter em execução de comandos no host.
- Atualizar para n8n 2.0.0 e validar os workflows críticos após a mudança.
- Reduzir privilégios do processo n8n e limitar acesso a arquivos, variáveis e rede conforme a necessidade real.
- Restringir quem pode criar ou modificar workflows, principalmente em instâncias compartilhadas.
- Desabilitar temporariamente o Code Node ou o suporte a Python quando a atualização não puder ser aplicada de imediato.
- Revisar workflows com Python, logs de alteração e processos iniciados pelo n8n no período anterior à correção.
0 Comentários