Token API n8n esposti su GitHub: 321 istanze accettavano credenziali compromesse

L’accesso autenticato apre la strada ai sistemi collegati

GitGuardian ha individuato 4.576 token API n8n pubblicati in 5.469 commit GitHub, riconducibili a 1.255 hostname.

Tra le 896 istanze raggiungibili, 321 accettavano almeno un token compromesso. Il dato equivale al 36% delle istanze accessibili e a circa il 26% degli hostname rilevati.

Non serve sfruttare una vulnerabilità di n8n. Un token ancora valido e le API REST documentate possono bastare per ottenere accesso autenticato.

Workflow, credenziali e integrazioni nel raggio dell’attacco

n8n è una piattaforma low-code per automatizzare workflow, disponibile in modalità self-hosted e tramite n8n.cloud. Le sue integrazioni possono collegare database, repository, ambienti cloud, servizi AI e sistemi interni.

In ambiente controllato, GitGuardian ha riprodotto quattro tecniche d’attacco. Un aggressore può:

• leggere workflow e dati delle esecuzioni;
• creare o modificare automazioni;
• usare le credenziali archiviate nei workflow;
• estrarre i relativi valori in alcune configurazioni;
• raggiungere i sistemi downstream collegati.

Le credenziali sono cifrate a riposo con N8N_ENCRYPTION_KEY, ma l’istanza deve decifrarle durante l’esecuzione. La protezione della chiave resta quindi essenziale.

Sono stati inoltre trovati 372 token MCP, di cui 7 ancora validi. Questi token possono ampliare il rischio quando assistenti AI invocano workflow o interagiscono con l’ambiente n8n.

Token senza scadenza e versioni non aggiornate

I token più vecchi possono non avere il claim exp, quindi restare validi indefinitamente. n8n ha introdotto una scadenza predefinita di 30 giorni nella versione 1.78.0, rilasciata a febbraio 2025, ma la modifica non invalida automaticamente i token generati in precedenza.

Il rischio si somma all’esposizione delle istanze: oltre 100.000 risultavano visibili tramite Shodan. Inoltre, erano disponibili più di 50 advisory di sicurezza da gennaio 2026; al 31 marzo 2026, il 58% delle istanze analizzate eseguiva versioni interessate da almeno un advisory.

Tra questi figura CVE-2025-68613, con CVSS 9.9 e inserita nel catalogo KEV l’11 marzo 2026. Non è però necessaria per lo scenario basato sui token validi.

Revoca immediata e verifica dei sistemi collegati

Gli amministratori dovrebbero:

1. revocare e rigenerare i token n8n e MCP esposti;
2. cercare token, hostname e riferimenti a credenziali nei repository pubblici e privati;
3. aggiornare n8n alle versioni non interessate dagli advisory;
4. applicare scadenze brevi e rotazione automatica;
5. limitare l’esposizione Internet e filtrare l’accesso alle API;
6. controllare workflow, log delle esecuzioni, account e sistemi downstream;
7. proteggere N8N_ENCRYPTION_KEY e ridurre i privilegi delle credenziali usate dai workflow.

La presenza di un token in un commit storico va trattata come una compromissione, anche quando il file è stato successivamente rimosso.