CVE-2026-27493 in n8n
Riassunto
di VulDB • 14/07/2026
n8n è una piattaforma di automazione dei flussi di lavoro open source. Prima delle versioni 2.10.1, 2.9.3 e 1.123.22, era presente in n8n un bug di vulnerabilità second-order expression injection nei Form nodes che consentiva a un attaccante non autenticato di iniettare ed eseguire espressioni arbitrarie di n8n inviando dati di modulo appositamente creati (crafted form data). Se concatenata con una fuga dall'expression sandbox, questa vulnerabilità poteva portare all'esecuzione remota di codice (RCE) sull'host che esegue n8n. La vulnerabilità richiede una specifica configurazione del flusso di lavoro per essere sfruttabile. In primo luogo, deve esserci un Form node con un campo che interpola un valore fornito da un utente non autenticato, ad esempio il valore inviato tramite un modulo. In secondo luogo, il valore del campo deve iniziare con un carattere `=`, cosa che induceva n8n a trattarlo come un'espressione e attivava una doppia valutazione (double-evaluation) del contenuto del campo. Non vi è alcun motivo pratico per cui un progettista di flussi di lavoro prefixi intenzionalmente un campo con `=`: il carattere non viene renderizzato nell'output, quindi il risultato non corrisponderebbe alle aspettative del progettista. Se aggiunto accidentalmente, sarebbe evidente e molto improbabile che persista. Un attaccante non autenticato dovrebbe o conoscere questa specifica circostanza su un'istanza target oppure scoprire per caso un modulo corrispondente. Anche quando le precondizioni sono soddisfatte, l'iniezione di espressioni è limitata ai dati accessibili all'interno del contesto delle espressioni n8n. L'escalation a remote code execution richiede la concatenazione con una vulnerabilità separata di fuga dalla sandbox (sandbox escape). Il problema è stato risolto nelle versioni 2.10.1, 2.9.3 e 1.123.22 di n8n. Gli utenti dovrebbero effettuare l'upgrade a una di queste versioni o successive per risolvere la vulnerabilità. Se l'aggiornamento non è immediatamente possibile, gli amministratori dovrebbero valutare le seguenti mitigazioni temporanee: esaminare manualmente l'utilizzo dei Form nodes rispetto alle precondizioni sopra menzionate; disabilitare il Form node aggiungendo `n8n-nodes-base.form` alla variabile d'ambiente `NODES_EXCLUDE`; e/o disabilitare il Form Trigger node aggiungendo `n8n-nodes-base.formTrigger` alla variabile d'ambiente `NODES_EXCLUDE`. Queste soluzioni alternative (workarounds) non risolvono completamente il rischio e dovrebbero essere utilizzate solo come misure di mitigazione a breve termine.
If you want to get best quality of vulnerability data, you may have to visit VulDB.