Falhas de alta severidade no n8n permitem execução remota de código por usuários autenticados

Falhas de alta severidade no n8n permitem execução remota de código por usuários autenticados

Duas vulnerabilidades de injeção por avaliação de código permitem escapar de sandboxes de JavaScript e Python e podem levar ao controle completo de uma instância n8n.

ComponentePlataforma de automação de workflows n8n, incluindo o mecanismo de expressões em JavaScript e o executor de tarefas Python.
VetorUsuário autenticado submete código JavaScript ou Python especialmente criado para contornar restrições de sandbox em fluxos do n8n.
ImpactoExecução remota de código no nó principal do n8n ou no sistema operacional subjacente, com risco de tomada completa da instância.
PrioridadeAtualizar a instalação n8n para versões corrigidas, restringir usuários autenticados e evitar modo de execução interno em produção.
ArtefatosCVE-2026-1470 com CVSS 9.9 e CVE-2026-0863 com CVSS 8.5.
ConfiguraçãoO risco permanece relevante em ambientes que usam modo de execução interno, configuração que reduz o isolamento entre o n8n e processos de execução de tarefas.
Resumo técnico

Duas falhas de alta severidade foram divulgadas no n8n, plataforma usada para automatizar workflows que frequentemente conectam APIs, credenciais de serviços, dados de negócio, integrações de IA e sistemas internos. Ambas dependem de autenticação, mas o impacto é elevado porque qualquer usuário autorizado na instância pode acionar o caminho vulnerável e sair das restrições esperadas do ambiente de execução. Em uma implantação corporativa, esse detalhe muda a avaliação de risco: a fronteira relevante não é apenas a exposição pública da interface, mas também a confiança concedida a contas internas com capacidade de criar ou alterar automações.

A primeira vulnerabilidade, CVE-2026-1470, recebeu CVSS 9.9 e envolve injeção em avaliação de código capaz de burlar o mecanismo de sandbox de expressões do n8n. O efeito confirmado é execução remota de código no nó principal da aplicação por meio de JavaScript especialmente construído. A segunda, CVE-2026-0863, recebeu CVSS 8.5 e afeta as restrições do python-task-executor, permitindo que um usuário autenticado execute código Python arbitrário no sistema operacional subjacente. A combinação desses caminhos cria risco direto para a integridade da instância, para segredos usados nos workflows e para integrações conectadas ao ambiente de automação.

Fluxo técnico

O n8n permite que automações processem dados, executem expressões e coordenem chamadas entre serviços. Esse modelo exige que linguagens dinâmicas sejam executadas com restrições fortes, porque JavaScript e Python oferecem recursos de runtime, manipulação de exceções e construções de linguagem que podem enfraquecer controles baseados apenas em validação, listas de bloqueio ou análise sintática. Nas falhas divulgadas, o ponto central é a diferença entre o que o sandbox pretendia permitir e o comportamento real do interpretador diante de código criado para explorar essas lacunas.

Em CVE-2026-1470, o invasor já autenticado passa JavaScript especialmente criado para contornar o sandbox de expressões e alcançar execução no nó principal do n8n. Isso é crítico porque o nó principal normalmente coordena a aplicação e pode ter acesso a credenciais, configurações, tokens de integrações e dados processados pelos workflows. Em CVE-2026-0863, o desvio ocorre no executor Python: o operador autenticado contorna as restrições do python-task-executor e obtém execução arbitrária no sistema operacional. O material não traz uma prova de conceito operacional nem lista comandos, mas confirma que o resultado técnico é execução de código fora do limite esperado do sandbox.

O risco também se mantém quando a instância opera em modo de execução interno. Nesse modo, a separação entre a aplicação n8n e os processos de execução de tarefas é menor, e a própria documentação do produto alerta que essa configuração pode representar risco de segurança em produção. A recomendação documentada é usar modo externo para obter melhor isolamento entre o n8n e os processos responsáveis por executar tarefas. Esse isolamento não substitui a atualização, mas reduz o impacto de uma fuga de sandbox ao limitar a proximidade entre o código acionado pelo workflow e o processo principal.

Superfície afetada

A superfície de exposição inclui instâncias n8n nas quais usuários autenticados conseguem criar, alterar ou acionar workflows que usem expressões em JavaScript ou tarefas Python. O ponto importante é que a exploração não depende de uma conta administrativa, conforme descrito para CVE-2026-1470: qualquer usuário do n8n pode explorar o problema e assumir a instância inteira. Organizações que tratam o n8n como ferramenta interna de baixo risco devem revisar esse modelo, porque contas de automação, usuários de áreas de negócio e integrações delegadas podem ter permissões suficientes para alcançar o caminho vulnerável.

O impacto é ampliado pela função do n8n dentro de ambientes modernos. A plataforma costuma intermediar fluxos com APIs de LLM, sistemas de vendas, funções internas, dados operacionais e componentes de IAM. Quando uma fuga de sandbox concede execução no processo principal ou no sistema operacional, o atacante pode passar do abuso de um workflow para a manipulação da própria camada de automação. O contexto também cita uma falha anterior, CVE-2026-21858, descrita como de severidade máxima e explorável sem autenticação, com mais de 39.000 instâncias ainda suscetíveis em 27 de janeiro de 2026; esse dado reforça que a exposição pública e a defasagem de atualização do ecossistema n8n já vinham sendo um problema operacional concreto.

  • Instâncias n8n com usuários autenticados capazes de editar ou executar workflows.
  • Ambientes que usam expressões JavaScript dentro do mecanismo de Expression sandbox.
  • Implantações que usam python-task-executor para tarefas Python.
  • Produção configurada com modo de execução interno, sem isolamento adequado entre aplicação e task runners.
Hunting e telemetria

A investigação deve começar pela linha do tempo de autenticação e de alterações em workflows. Como as duas falhas exigem usuário autenticado, eventos de login, criação de tokens, mudanças de permissão, edição de workflows e execuções incomuns por contas de baixo privilégio são sinais prioritários. A análise deve separar atividade legítima de automação de alterações que introduzem expressões novas, trechos Python inesperados ou execuções próximas a erros de sandbox, exceções do interpretador e falhas de validação.

No endpoint e no host que executa o n8n, a defesa deve procurar processos filhos ou chamadas de sistema incompatíveis com a função normal da instância. Para CVE-2026-1470, a atenção fica no processo principal do n8n e em sinais de execução fora do padrão após avaliação de expressões. Para CVE-2026-0863, os eventos ligados ao executor Python são mais relevantes, especialmente quando aparecem combinados com acesso a arquivos, variáveis de ambiente, credenciais de integração ou comunicação de rede não prevista. Como o material não fornece IoCs, hashes ou domínios, a detecção deve ser comportamental e baseada em anomalias locais.

  • Edições recentes de workflows feitas por contas sem histórico de manutenção técnica.
  • Execuções com falhas de sandbox, exceções incomuns ou mensagens de erro associadas a avaliação de JavaScript ou Python.
  • Processos filhos, acesso a arquivos ou conexões de rede originados do processo n8n ou do python-task-executor fora do padrão operacional.
  • Acesso inesperado a credenciais, variáveis de ambiente, integrações de IAM, APIs de LLM ou dados de vendas conectados aos workflows.
Mitigação

A primeira ação é atualizar o n8n para versões corrigidas assim que disponibilizadas no canal oficial usado pela organização. O contexto confirma a recomendação de atualização, mas não informa números de versão; portanto, a validação deve ser feita contra o inventário real de cada ambiente e o boletim do fornecedor. Até a correção estar aplicada, reduza a exposição de contas autenticadas, remova permissões de edição de workflows que não sejam indispensáveis e suspenda temporariamente automações que executem expressões ou tarefas Python de origem não revisada.

Ambientes de produção que ainda usam modo de execução interno devem ser priorizados para migração ao modo externo, porque essa configuração oferece separação mais adequada entre o n8n e os processos de tarefa. Depois da atualização, a equipe deve revisar workflows alterados no período de exposição, rotacionar segredos acessíveis pela instância quando houver indício de execução indevida e validar se integrações críticas não foram modificadas. A resposta deve considerar o n8n como um ponto de concentração de confiança: mesmo sem evidência de exploração ativa no contexto, a possibilidade de execução remota por usuário autenticado exige contenção de permissões, auditoria de mudanças e verificação de integridade da automação.

  • Aplicar a atualização corretiva do n8n nos ambientes afetados e confirmar a versão instalada no inventário.
  • Migrar produção do modo de execução interno para modo externo quando essa configuração ainda estiver em uso.
  • Restringir criação, edição e execução de workflows a usuários com necessidade comprovada.
  • Auditar workflows, credenciais e integrações alterados após a janela de exposição.
  • Rotacionar segredos acessíveis pela instância se houver qualquer sinal de execução de código não autorizada.

Postar um comentário

0 Comentários