n8n CVE-2026-42233 : SQL injection Oracle dans le node Database via webhook

n8n est devenu l'outil de référence pour l'automatisation low-code en entreprise, concurrent direct de Zapier et Make sur le segment self-hosted. Le 4 mai 2026, l'éditeur a publié CVE-2026-42233 (CVSS 9.8) : une SQL injection critique dans le node Oracle Database, spécifiquement sur l'opération select. Le champ Limit accepte une expression dont la valeur est concaténée directement dans la requête SQL sans paramétrage. Dans tous les workflows qui passent une entrée externe (webhook, formulaire, message) à ce champ, un attaquant peut injecter du SQL arbitraire et exfiltrer la base Oracle connectée.

C'est la classe de vulnérabilité la plus insidieuse : elle n'expose pas n8n directement, mais transforme n8n en arme contre les bases de données qu'il connecte.

Détails techniques

Composant vulnérable

Le node Oracle Database de n8n propose plusieurs opérations dont Select, qui exécute une requête SQL contre la base configurée. Le champ Limit (limite du nombre de résultats) accepte une expression n8n — c'est-à-dire que sa valeur peut être dynamiquement calculée à partir des données du workflow, y compris des entrées externes.

Le problème : la valeur résolue de cette expression est interpolée directement dans la requête SQL au lieu d'être passée comme paramètre :

// Pseudo-code reconstitué — pattern vulnérable
const limit = evaluateExpression(node.parameters.limit); // entrée externe possible
const query = `SELECT * FROM ${table} WHERE ${where} ORDER BY ${order} LIMIT ${limit}`;
oracle.execute(query); // pas de bind variables

Si le workflow Webhook → Oracle Select est configuré pour passer un paramètre du webhook au champ Limit, l'attaquant qui appelle le webhook peut injecter du SQL.

Caractéristiques

Produits et versions affectés

Vérifiez votre version :

# Docker
docker exec n8n n8n --version

# npm
npm list -g n8n

Exploitation et impact

Scénario type

Un workflow n8n exposé via webhook public reçoit une demande de l'extérieur (par exemple : « combien de produits as-tu ? »). Le n (limite) du webhook est passé au champ Limit du node Oracle Select. Configuration légitime mais piégée.

L'attaquant appelle le webhook avec :

POST /webhook/products
Content-Type: application/json
{
  "limit": "10 UNION SELECT username, password, NULL FROM users--"
}

n8n construit alors la requête :

SELECT * FROM products LIMIT 10 UNION SELECT username, password, NULL FROM users--

Et renvoie le résultat — y compris les credentials extraits.

Conséquences

• Exfiltration de toute la base Oracle connectée au workflow (et de toutes les bases que ce user Oracle peut atteindre via cross-database query)
• Lecture de credentials, données clients, secrets métiers stockés dans Oracle
• Potentiel RCE Oracle via DBMS_SCHEDULER ou xp_cmdshell équivalent (selon les privilèges du user Oracle utilisé par n8n)
• Pivot interne : Oracle DB est souvent placée en zone protégée, mais accessible depuis n8n — l'attaquant pivote via n8n

Conditions d'exploitation

Pas universel — il faut que :

1. Le workflow utilise le node Oracle Database avec opération Select
2. Le champ Limit soit en mode expression (et non valeur fixe)
3. La valeur de l'expression résolve à une entrée externe (webhook, formulaire, ou node précédent qui reçoit l'entrée)

Mais ces conditions sont courantes dans les déploiements n8n professionnels — les workflows webhook + DB select sont l'un des patterns les plus utilisés.

Détection et IOC

Audit des workflows

Listez tous vos workflows utilisant le node Oracle Database :

# Si vous avez accès à la DB n8n (Postgres)
psql -d n8n -c "
  SELECT id, name FROM workflow_entity 
  WHERE nodes::text LIKE '%oracle%' AND active = true;
"

Pour chaque workflow, vérifiez manuellement :

• L'opération du node Oracle est-elle Select ?
• Le champ Limit est-il en mode expression ?
• La chaîne d'inputs remonte-t-elle à un webhook ou un node recevant des données externes ?

Logs n8n

# Recherche dans les logs des appels webhook suspects
grep -E "webhook.*[;\"'].*UNION|SELECT|--" /var/log/n8n/*.log

Logs Oracle

-- Activer l'audit des requêtes
AUDIT SELECT ON ANY TABLE BY n8n_user BY ACCESS;

Indicateurs :

• Requêtes contenant UNION SELECT depuis le compte Oracle utilisé par n8n
• Lectures massives de tables hors du périmètre habituel du workflow
• Volume anormal de requêtes provenant de n8n

Mitigation et patch

Action immédiate : patcher

# Branche 1.x
docker pull n8nio/n8n:1.123.32

# Branche 2.17.x
docker pull n8nio/n8n:2.17.4

# Branche 2.18.x
docker pull n8nio/n8n:2.18.1

# Redémarrer
docker compose up -d

Workaround si patch impossible

1. Auditer et désactiver temporairement tout workflow qui passe une entrée externe au champ Limit du node Oracle
2. Convertir les expressions en valeurs fixes : remplacer {{ $json.limit }} par une valeur dure (10, 100)
3. Ajouter un node Function avant le node Oracle qui valide et coerce la limite en nombre entier :

// Node Function
const limit = parseInt(items[0].json.limit, 10);
if (isNaN(limit) || limit < 1 || limit > 1000) {
  throw new Error("Invalid limit");
}
return [{ json: { limit } }];

Hardening durable post-patch

• Limiter les privilèges du compte Oracle utilisé par n8n au strict minimum (SELECT sur les tables nécessaires uniquement, pas de SYS, pas de DBMS_SCHEDULER)
• Activer l'audit Oracle sur le compte n8n
• Mettre un WAF devant les webhooks publics de n8n
• Faire tourner les credentials Oracle utilisés par n8n
• Vérifier l'historique des requêtes Oracle des 30 derniers jours pour détecter d'éventuelles exfiltrations passées

Pourquoi surveiller en continu vos outils d'automatisation

Les outils low-code comme n8n, Make, Zapier self-hosted ou Apache Airflow connectent souvent des bases de données critiques à des entrées externes (webhook, formulaire, scraping). Une CVE comme celle-ci ne compromet pas l'outil lui-même mais les données qu'il manipule — un angle souvent ignoré par les scanners de vulnérabilités traditionnels.

Avec cveo.tech, inventoriez vos plateformes d'automatisation et d'orchestration au même titre que vos serveurs et bases de données, et soyez alerté automatiquement dès qu'une CVE critique cible une de vos versions exactes — pour patcher avant que vos workflows légitimes ne deviennent des vecteurs d'exfiltration.