CVE-2025-68613: RCE de injeção de expressão autenticada no n8n (CWE-913) - o que foi afetado, o que deve ser corrigido e como contê-lo

O que o CVE-2025-68613 realmente é

O CVE-2025-68613 afeta n8numa plataforma de automação de fluxo de trabalho de código aberto. A vulnerabilidade é uma execução remota de código (RCE) questão no n8n's sistema de avaliação de expressão de fluxo de trabalho: sob certas condições, expressões fornecidas por usuários autenticados durante a configuração do fluxo de trabalho pode ser avaliada em um contexto de execução que é não suficientemente isolado do tempo de execução subjacente. Um invasor pode abusar desse comportamento para executar código arbitrário com os privilégios do processo n8n, o que pode levar ao comprometimento total da instância (acesso a dados, modificação do fluxo de trabalho, operações em nível de sistema). (NVD)

Atualmente, a entrada do National Vulnerability Database (NVD) mostra que o enriquecimento de pontuação do próprio NVD ainda não é fornecido, mas exibe a pontuação CNA do GitHub, Inc.: CVSS v3.1 pontuação base 9.9 (CRÍTICO) com o vetor CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. (NVD)

Esse vetor é importante do ponto de vista operacional: o problema é acessível pela rede, de baixa complexidade, requer apenas privilégios baixos, nenhuma interação com o usuário e mudou de escopo - exatamente o padrão que tende a transformar "um bug de aplicativo" em "um comprometimento do ambiente" quando o serviço está conectado a sistemas internos.

O mapeamento de pontos fracos é CWE-913. O MITRE define CWE-913 como controle inadequado sobre recursos de código gerenciados dinamicamente (variáveis, objetos, classes, atributos, funções, instruções/declarações executáveis), o que se alinha com a natureza de "avaliação de expressão que escapa ao isolamento pretendido" desse problema. (cwe.mitre.org)

Uma tabela que pode ser inserida em uma consultoria de segurança

Por que "requer autenticação" ainda merece um tratamento emergencial

Tratar isso como "menos urgente porque é autenticado" é um modo de falha comum. No n8n, os usuários autenticados geralmente não são apenas administradores; eles podem ser criadores de automação, operadores de integração ou contas de serviço. Quando o limite de avaliação da expressão é rompido, o invasor não se limita às ações do aplicativo - o NVD observa explicitamente a execução arbitrária de código com os privilégios do processo n8n e a possibilidade de comprometimento total da instância. (NVD)

Na prática, as plataformas de fluxo de trabalho concentram três coisas que os invasores adoram: ampla conectividade, segredos e execução de lógica. É por isso que você deve ancorar seu plano de resposta ao vetor CVSS (PR:L + S:C + C/I/A:H) em vez de sua intuição sobre "login necessário". (NVD)

Estratégia de patches que não se desintegra no caos

Seu estado final "correto" é simples: execute uma versão corrigida. O NVD lista o problema como corrigido em 1.120.4, 1.121.1 e 1.122.0. (NVD)

O texto de aviso do n8n/GitHub destaca que o problema foi corrigido em v1.122.0 e recomenda a atualização para 1.122.0 ou posterior porque "introduz salvaguardas adicionais para restringir a avaliação da expressão". (GitHub)

Operacionalmente, isso sugere uma regra simples:

Se você puder avançar com segurança, converja para 1.122.0+Se você estiver preso a um trem de lançamento específico, use as versões fixas mínimas indicadas pelo NVD e planeje uma mudança futura assim que possível. (NVD)

Aqui está um somente para auditoria verificador de versão que pode ser executado na CI, em hosts ou em um trabalho de frota (sem lógica de exploração, apenas sinalização de versão/risco):

#!/usr/bin/env bash
# CVE-2025-68613 auditoria de versão do n8n (sem exploração)

set -euo pipefail

if command -v n8n >/dev/null 2>&1; then
  VER="$(n8n --version | tr -d 'v' | head -n1)"
else
  VER="${N8N_VERSION:-unknown}"
fi

echo "Versão do n8n detectada: $VER"

# Faixa afetada de acordo com a consultoria do GitHub: >=0.211.0 <1.120.4
# Versões corrigidas por NVD: 1.120.4, 1.121.1, 1.122.0
se [["$VER" != "unknown" ]] && \\
   [[ "$(printf '%s\\n' "0.211.0" "$VER" | sort -V | head -n1)" == "0.211.0" ]] && \\
   [[ "$(printf '%s\\n' "$VER" "1.120.4" | sort -V | head -n1)" == "$VER" ]] && \\
   [[ "$VER" != "1.120.4" ]]; then
  echo "FLAG: potencialmente afetado pelo CVE-2025-68613. Atualize de acordo com a orientação do NVD/GitHub."
  exit 2
fi

echo "Nenhum sinalizador dessa verificação rápida. Valide com base na orientação oficial + seus detalhes exatos de implementação."

Mitigações de curto prazo

Tanto o NVD quanto a consultoria do GitHub fornecem as mesmas mitigações de curto prazo: restringir as permissões de criação/edição de fluxo de trabalho a usuários totalmente confiáveise implantar o n8n em um ambiente reforçado com privilégios restritos do sistema operacional e acesso à rede para reduzir o impacto, ao mesmo tempo em que declara explicitamente que essas atenuações não eliminam totalmente o risco. (NVD)

Se você quiser que isso seja aplicável, o "ambiente reforçado" deve se traduzir em controles de tempo de execução. Aqui está um esboço conservador de proteção de contêineres para reduzir a alavancagem pós-exploração (defesa em profundidade):

serviços:
  n8n:
    image: n8nio/n8n:1.122.0
    read_only: true
    tmpfs:
      - /tmp
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    user: "1000:1000"
    environment:
      - N8N_LOG_LEVEL=info
    # Emparelhar com a política de rede / firewall:
    # negar saída por padrão, permitir apenas os destinos necessários

Detecção e caça a ameaças: comportamento em vez de assinaturas frágeis

Como o mecanismo de acionamento é "expressões durante a configuração do fluxo de trabalho avaliadas em um contexto insuficientemente isolado", é possível criar uma detecção útil em torno de quem está editando os fluxos de trabalho, com que frequênciae o que o tempo de execução faz depois. (NVD)

Uma abordagem prática que sobrevive às diferenças de implementação é a correlação:

Edições incomuns do fluxo de trabalho por usuários com poucos privilégios (ou contas de serviço) + execução suspeita de processos/conexões de saída do tempo de execução do n8n. Isso se alinha com a declaração da NVD de que a exploração bem-sucedida pode resultar em operações em nível de sistema executadas com os privilégios do processo n8n. (NVD)

Exemplo de ideia de auditoria (adaptar-se ao seu ambiente):

-a always,exit -F arch=b64 -S execve -F comm=node -k n8n_exec
-a always,exit -F arch=b64 -S connect -F comm=node -k n8n_net

CVEs n8n adjacentes de alto impacto que você deve analisar

Se sua organização depende do n8n, o CVE-2025-68613 não deve ser tratado como um caso isolado. Dois exemplos adjacentes ilustram um tema recorrente em plataformas de fluxo de trabalho: recursos que obscurecem o limite entre configuração e execução.

CVE-2025-65964 é um problema n8n separado que envolve o nó Git: O NVD descreve que as versões 0.123.1 a 1.119.1 não tinham proteções adequadas para evitar RCE por meio de ganchos do Git, em que as ações do fluxo de trabalho poderiam influenciar a configuração do Git (por exemplo, core.hooksPath) e causar a execução de ganchos; o problema foi corrigido em 1.119.2. (NVD)

CVE-2025-57749 é uma vulnerabilidade de passagem de link simbólico no nó Read/Write File do n8n antes do 1.106.0onde as restrições de diretório podiam ser contornadas por meio de links simbólicos, permitindo o acesso a caminhos que, de outra forma, seriam restritos. (NVD)

São bugs diferentes, mas a lição é a mesma: os mecanismos de fluxo de trabalho ficam perigosamente próximos dos "recursos de código e sistema", portanto, o isolamento, as proteções em nível de nó e os limites rígidos de privilégio não são opcionais. A definição CWE-913 do MITRE mostra por que esses problemas reaparecem quando os recursos de código dinâmico podem ser influenciados inesperadamente. (cwe.mitre.org)

Se o seu objetivo for um ciclo fechado de engenharia - descoberta de ativos, validação de versão, verificação de patches e relatórios com grau de evidência -, uma plataforma de fluxo de trabalho de segurança orientada por IA, como a Penligent, pode se encaixar naturalmente na fase "verificar correções e regressões". Se o seu único objetivo for reduzir o risco de produção imediatamente, a ação de maior alavancagem continua sendo: atualizar para as versões corrigidas e aplicar as atenuações de curto prazo do fornecedor até que você possa. (NVD)

https://nvd.nist.gov/vuln/detail/CVE-2025-68613
https://github.com/n8n-io/n8n/security/advisories/GHSA-v98v-ff95-f3cp
https://cwe.mitre.org/data/definitions/913.html
https://docs.n8n.io/release-notes/
https://nvd.nist.gov/vuln/detail/CVE-2025-65964
https://github.com/n8n-io/n8n/security/advisories/GHSA-wpqc-h9wp-chmq
https://nvd.nist.gov/vuln/detail/CVE-2025-57749