A vulnerabilidade CVE-2025-68613 permite execução remota de código por injeção de expressão em instâncias n8n, com exploração ativa e mais de 24.700 exposições sem correção observadas online.
| Componente | Sistema de avaliação de expressões de workflow do n8n. |
| Vetor | Injeção de expressão explorável por atacante autenticado, levando à execução de código com os privilégios do processo n8n. |
| Impacto | Comprometimento completo da instância, com acesso a dados sensíveis, alteração de workflows e execução de operações em nível de sistema. |
| Prioridade | Atualizar instâncias n8n para 1.120.4, 1.121.1, 1.122.0 ou versões posteriores corrigidas e reduzir exposição direta à internet. |
| Versões | Correção publicada em dezembro de 2025 nas versões 1.120.4, 1.121.1 e 1.122.0. |
| Exposição | Mais de 24.700 instâncias sem correção foram observadas expostas online, incluindo mais de 12.300 na América do Norte e 7.800 na Europa no início de fevereiro de 2026. |
| Prazo regulatório | Órgãos federais civis do Poder Executivo dos EUA receberam prazo até 25 de março de 2026 para corrigir as instâncias afetadas. |
A CISA adicionou a vulnerabilidade crítica CVE-2025-68613 ao catálogo Known Exploited Vulnerabilities após evidência de exploração ativa contra o n8n. A falha recebeu pontuação CVSS 9.9 e afeta o mecanismo de avaliação de expressões usado pela plataforma de automação de workflows. O problema foi descrito como controle impróprio de recursos de código gerenciados dinamicamente, uma condição que permite transformar a avaliação de expressões em execução remota de código dentro do processo da aplicação.
O impacto técnico é alto porque o n8n frequentemente opera conectado a serviços internos, credenciais de integração, automações administrativas e fluxos que movimentam dados entre aplicações. O contexto confirmado indica que um atacante autenticado pode executar código arbitrário com os privilégios do processo n8n. Em uma instância comprometida, isso pode permitir acesso a dados sensíveis disponíveis para a aplicação, modificação de workflows existentes e operações no sistema onde o serviço está em execução, dentro dos limites de permissão desse processo.
A falha está concentrada no sistema de avaliação de expressões de workflow. Em plataformas de automação, expressões costumam ser usadas para transformar dados, referenciar variáveis, compor campos dinâmicos e direcionar decisões dentro de um fluxo. Quando esse mecanismo não separa corretamente dados controlados pelo usuário de recursos capazes de executar código, uma entrada manipulada pode deixar de ser apenas conteúdo avaliado e passar a acionar execução no ambiente da aplicação.
O vetor confirmado exige autenticação. Esse detalhe reduz a exposição em comparação com uma exploração totalmente anônima, mas não elimina o risco operacional. Contas válidas, tokens de sessão, integrações mal configuradas ou acessos concedidos a usuários de baixa confiança podem criar as precondições necessárias. Como não há detalhes públicos no contexto sobre a forma usada em ataques reais, a defesa deve tratar a exploração como confirmada, mas evitar assumir um payload específico, uma rota única ou uma sequência fixa de chamadas.
A correção foi disponibilizada em dezembro de 2025 nas versões 1.120.4, 1.121.1 e 1.122.0. A inclusão no catálogo KEV em março de 2026 altera a prioridade de resposta: a vulnerabilidade deixa de ser apenas uma falha crítica corrigida e passa a representar uma condição observada em atividade real. Também há relação técnica com falhas posteriores divulgadas no mesmo sistema de avaliação de expressões, incluindo CVE-2026-27577, classificada como exploração adicional descoberta após CVE-2025-68613. Isso reforça que a área funcional deve ser tratada como superfície sensível, não como um bug isolado.
A superfície de maior risco envolve instâncias n8n expostas à internet e ainda abaixo das versões corrigidas. Dados de varredura indicaram mais de 24.700 instâncias sem correção acessíveis online, com concentração superior a 12.300 na América do Norte e 7.800 na Europa no início de fevereiro de 2026. A exposição externa importa porque facilita descoberta, enumeração de versão, tentativa de autenticação e abuso de contas existentes contra o serviço.
Ambientes internos também não devem ser descartados. Uma instância n8n pode ter permissões amplas para automatizar tarefas entre sistemas corporativos, APIs, bancos de dados, filas, aplicações SaaS e serviços administrativos. Mesmo quando o serviço não está publicado diretamente na internet, um atacante que já possua acesso autenticado ao painel ou a uma conta integrada pode abusar da falha para avançar do plano de workflow para o plano do sistema operacional do host ou contêiner onde o processo é executado.
- Instâncias n8n anteriores às versões 1.120.4, 1.121.1 e 1.122.0 devem ser tratadas como vulneráveis quando ainda não receberam correção equivalente.
- Serviços n8n publicados diretamente na internet concentram risco por combinarem descoberta remota com uma falha já explorada ativamente.
- Contas autenticadas com capacidade de criar, alterar ou acionar workflows merecem revisão de permissão e histórico de atividade.
- Workflows com acesso a segredos, integrações administrativas ou dados sensíveis ampliam o impacto de uma execução de código bem-sucedida.
A investigação defensiva deve começar pelo inventário de instâncias e versões, cruzando exposição externa, responsáveis pelo serviço e presença das versões corrigidas. Como o contexto não detalha artefatos de exploração em campo, a busca não deve depender de um indicador único. O foco deve ser comportamento anômalo: alterações inesperadas em workflows, criação de automações fora do padrão, execução incomum pelo processo n8n e acessos autenticados que antecedem mudanças de alto impacto.
No endpoint ou no contêiner que executa o serviço, procure processos filhos, operações de sistema e acessos a arquivos que não correspondam ao comportamento normal da plataforma. Em logs de aplicação, revise eventos de autenticação, criação e edição de workflows, acionamentos manuais ou automatizados em sequência e mudanças feitas por contas que normalmente não administram integrações críticas. Em rede, avalie conexões de saída iniciadas pelo host n8n para destinos incomuns, principalmente após alterações recentes em workflows.
- Eventos de login e sessão associados a contas com permissão para modificar workflows, especialmente antes de alterações incomuns.
- Criação, edição ou ativação de workflows fora de janela operacional ou por usuários que não costumam administrar automações.
- Processos filhos ou operações de sistema iniciados pelo processo n8n sem relação com conectores e tarefas esperadas.
- Acessos a segredos, variáveis, credenciais de integração ou dados sensíveis logo após mudanças em workflows.
- Conexões de saída anômalas partindo do host ou contêiner n8n após eventos de autenticação e alteração de fluxo.
A medida principal é atualizar o n8n para uma versão corrigida, tomando como referência as versões 1.120.4, 1.121.1 e 1.122.0 ou ramos posteriores que contenham a correção. A atualização deve ser acompanhada de validação funcional dos workflows, porque a área afetada envolve avaliação de expressões e automações podem depender desse mecanismo. Instâncias expostas publicamente devem receber prioridade, seguidas por ambientes internos com integrações sensíveis ou permissões elevadas.
A contenção deve reduzir a probabilidade de um atacante autenticado alcançar o vetor. Restrinja acesso administrativo ao n8n, imponha autenticação forte onde aplicável, revise usuários com permissão de edição de workflows e remova contas sem necessidade operacional. Para instalações em contêineres ou hosts dedicados, execute o serviço com privilégios mínimos e limite acesso a arquivos, variáveis e redes internas. Após a correção, revise workflows recentes, credenciais usadas pela plataforma e registros de execução para identificar sinais de abuso anterior.
- Atualizar instâncias vulneráveis para 1.120.4, 1.121.1, 1.122.0 ou versões posteriores corrigidas.
- Remover exposição direta desnecessária à internet e restringir acesso por controles de rede compatíveis com o ambiente.
- Revisar contas autenticadas, permissões de edição de workflows e sessões recentes associadas a mudanças administrativas.
- Validar histórico de workflows, credenciais de integração e execuções recentes em busca de alterações não autorizadas.
- Executar o processo n8n com privilégio mínimo e limitar o alcance de rede e sistema disponível à aplicação.
0 Comentários