CVE-2025-68613 : RCE d'injection d'expression authentifiée dans n8n (CWE-913) - Ce qui est affecté, ce qui doit être corrigé et comment le contenir

Ce qu'est réellement CVE-2025-68613

CVE-2025-68613 affecte n8nune plateforme open-source d'automatisation des flux de travail. La vulnérabilité est une l'exécution de code à distance (RCE) question dans n8n's système d'évaluation de l'expression du flux de travail: sous certaines conditions, les expressions fournies par utilisateurs authentifiés lors de la configuration du flux de travail peut être évaluée dans un contexte d'exécution qui est pas suffisamment isolés de l'exécution sous-jacente. Un attaquant peut abuser de ce comportement pour exécuter du code arbitraire avec les privilèges du processus n8n, ce qui peut conduire à la compromission totale de l'instance (accès aux données, modification du flux de travail, opérations au niveau du système). (NVD)

L'entrée de la base de données nationale sur la vulnérabilité (BNV) indique actuellement que l'enrichissement de la notation de la BNV n'est pas encore fourni, mais il est possible d'y accéder. affiche le score CNA de GitHub, Inc.: Score de base CVSS v3.1 9.9 (CRITIQUE) avec le vecteur CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. (NVD)

Ce vecteur est important d'un point de vue opérationnel : le problème est accessible par le réseau, peu complexe, ne nécessite que de faibles privilèges, aucune interaction avec l'utilisateur et a changé de portée - exactement le schéma qui tend à transformer un "bogue d'application" en une "compromission de l'environnement" lorsque le service est connecté à des systèmes internes.

La cartographie des faiblesses est CWE-913. MITRE définit CWE-913 comme un contrôle inapproprié des ressources de code gérées dynamiquement (variables, objets, classes, attributs, fonctions, instructions/états exécutables), ce qui correspond à la nature de ce problème : "l'évaluation de l'expression échappe à l'isolement prévu". (cwe.mitre.org)

Un tableau que vous pouvez intégrer dans un avis de sécurité

Pourquoi l'expression "nécessite une authentification" mérite-t-elle toujours d'être traitée d'urgence ?

Traiter cette question comme "moins urgente parce qu'elle est authentifiée" est un mode d'échec courant. Dans n8n, les utilisateurs authentifiés ne sont souvent pas de simples administrateurs ; ils peuvent être des constructeurs d'automatisation, des opérateurs d'intégration ou des comptes de service. Une fois que la limite d'évaluation de l'expression est franchie, l'attaquant n'est pas limité aux actions de l'application - la NVD note explicitement l'exécution de code arbitraire avec les privilèges du processus n8n et la possibilité d'une compromission complète de l'instance. (NVD)

Dans la pratique, les plateformes de flux de travail concentrent trois choses que les attaquants adorent : une large connectivité, des secrets et l'exécution de la logique. C'est pourquoi vous devriez ancrer votre plan de réponse au vecteur CVSS (PR:L + S:C + C/I/A:H) plutôt qu'à votre intuition concernant la "connexion requise". (NVD)

Une stratégie de répartition qui ne s'effondre pas dans le chaos

L'état final "correct" est simple : exécuter une version corrigée. La NVD indique que le problème est corrigé dans 1.120.4, 1.121.1 et 1.122.0. (NVD)

Le texte de l'avis de n8n/GitHub souligne que le problème est corrigé en v1.122.0 et recommande de passer à la version 1.122.0 ou plus récent parce qu'elle "introduit des garanties supplémentaires pour restreindre l'évaluation de l'expression". (GitHub)

D'un point de vue opérationnel, il s'agit d'une règle simple :

Si vous pouvez avancer en toute sécurité, convergez vers 1.122.0+si vous êtes attaché à une version spécifique, utilisez les versions fixes minimales indiquées par NVD tout en planifiant une évolution dès que possible. (NVD)

Voici un audit uniquement un vérificateur de version que vous pouvez exécuter en CI, sur des hôtes, ou dans un job de flotte (pas de logique d'exploitation, juste un signalement de la version/du risque) :

#!/usr/bin/env bash
# CVE-2025-68613 audit de la version de n8n (pas d'exploitation)

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 "Version de n8n détectée : $VER"

# Gamme affectée par l'avis de GitHub : >=0.211.0 <1.120.4
# Versions corrigées par NVD : 1.120.4, 1.121.1, 1.122.0

   [[ "$(printf '%s\\n' "0.211.0" "$VER" | sort -V | head -n1)" == "0.211.0" ]] & & \\n
   [[ "$(printf '%s\\n' "$VER" "1.120.4" | sort -V | head -n1)" == "$VER" ]] && \\
   [[ "$VER" != "1.120.4" ]] ; then
  echo "FLAG : Potentiellement affecté par CVE-2025-68613. Mettre à jour selon les conseils de NVD/GitHub."
  exit 2
fi

echo "Pas de drapeau à partir de cette vérification rapide. Validez par rapport à l'avis officiel + les détails exacts de votre déploiement."

Mesures d'atténuation à court terme

La NVD et l'avis de GitHub proposent tous deux les mêmes mesures d'atténuation à court terme : limiter les autorisations de création/édition de flux de travail à utilisateurs de confianceet déployer n8n dans un environnement durci en limitant les privilèges du système d'exploitation et l'accès au réseau afin de réduire l'impact, tout en indiquant explicitement que ces mesures d'atténuation n'éliminent pas totalement le risque. (NVD)

Si vous voulez que cela soit applicable, "l'environnement renforcé" doit se traduire par des contrôles d'exécution. Voici un schéma conservateur de durcissement d'un conteneur pour réduire l'effet de levier post-exploitation (défense en profondeur) :

services :
  n8n :
    image : n8nio/n8n:1.122.0
    read_only : true
    tmpfs :
      - /tmp
    security_opt :
      - no-new-privileges:true
    cap_drop :
      - ALL
    user : "1000:1000"
    environnement :
      - N8N_LOG_LEVEL=info
    # Pair avec la politique réseau / pare-feu :
    # refuse les sorties par défaut, n'autorise que les destinations requises

Détection et chasse aux menaces : le comportement plutôt que des signatures fragiles

Le mécanisme de déclenchement étant "des expressions pendant la configuration du flux de travail évaluées dans un contexte insuffisamment isolé", vous pouvez mettre en place une détection utile autour des éléments suivants qui modifie les flux de travail, à quelle fréquenceet ce que fait le moteur d'exécution par la suite. (NVD)

Une approche pratique qui résiste aux différences de mise en œuvre consiste à établir des corrélations :

Modifications inhabituelles du flux de travail par des utilisateurs à faibles privilèges (ou des comptes de service) + exécution suspecte du processus / connexions sortantes de l'exécution n8n. Cela correspond à la déclaration de la NVD selon laquelle une exploitation réussie peut entraîner des opérations au niveau du système exécutées avec les privilèges du processus n8n. (NVD)

Exemple d'idée auditd (s'adapter à son environnement) :

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

CVE n8n adjacents à fort impact que vous devriez examiner

Si votre organisation s'appuie sur n8n, CVE-2025-68613 ne doit pas être considéré comme un cas isolé. Deux exemples adjacents illustrent un thème récurrent dans les plateformes de flux de travail : des fonctionnalités qui brouillent la frontière entre la configuration et l'exécution.

CVE-2025-65964 est un problème n8n distinct impliquant le nœud Git : NVD décrit que les versions 0.123.1 à 1.119.1 n'ont pas de protections adéquates pour empêcher le RCE à travers les hooks Git, où les actions du flux de travail pourraient influencer la configuration Git (par exemple, core.hooksPath) et provoquer l'exécution du hook ; le problème est corrigé dans la version 1.119.2. (NVD)

CVE-2025-57749 est une vulnérabilité de traversée de liens symboliques dans le nœud Read/Write File de n8n avant 1.106.0où les restrictions sur les répertoires pouvaient être contournées par des liens symboliques, ce qui permettait d'accéder à des chemins d'accès autrement restreints. (NVD)

Il s'agit de bogues différents, mais la leçon est la même : les moteurs de flux de travail sont dangereusement proches des "capacités du code et du système", de sorte que l'isolation, les garde-fous au niveau des nœuds et les limites strictes des privilèges ne sont pas facultatifs. La définition CWE-913 de MITRE explique pourquoi ces problèmes réapparaissent lorsque des ressources de code dynamiques peuvent être influencées de manière inattendue. (cwe.mitre.org)

Si votre objectif est une boucle fermée d'ingénierie - découverte des actifs, validation de la version, vérification des correctifs et rapports de qualité - alors une plateforme de workflow de sécurité pilotée par l'IA comme Penligent peut s'intégrer naturellement dans la phase de " vérification des correctifs et des régressions ". Si votre seul objectif est de réduire immédiatement le risque de production, l'action la plus efficace reste la mise à niveau vers les versions corrigées et l'application des mesures d'atténuation à court terme du fournisseur jusqu'à ce que vous puissiez le faire. (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