Tokens de API de n8n expuestos en GitHub: 321 instancias aceptaban credenciales comprometidas

El acceso autenticado abre el camino a los sistemas conectados

GitGuardian identificó 4.576 tokens de API de n8n publicados en 5.469 commits de GitHub, asociados a 1.255 hostnames.

De las 896 instancias accesibles, 321 aceptaban al menos un token comprometido. Esto equivale al 36 % de las instancias accesibles y aproximadamente al 26 % de los hostnames detectados.

No es necesario explotar una vulnerabilidad de n8n. Un token aún válido y las API REST documentadas pueden bastar para obtener acceso autenticado.

Workflows, credenciales e integraciones al alcance del ataque

n8n es una plataforma low-code para automatizar workflows, disponible en modalidad self-hosted y a través de n8n.cloud. Sus integraciones pueden conectar bases de datos, repositorios, entornos cloud, servicios de IA y sistemas internos.

En un entorno controlado, GitGuardian reprodujo cuatro técnicas de ataque. Un atacante puede:

• leer workflows y datos de las ejecuciones;
• crear o modificar automatizaciones;
• usar las credenciales almacenadas en los workflows;
• extraer sus valores en algunas configuraciones;
• acceder a los sistemas downstream conectados.

Las credenciales se cifran en reposo mediante N8N_ENCRYPTION_KEY, pero la instancia debe descifrarlas durante la ejecución. Por tanto, proteger la clave sigue siendo esencial.

También se encontraron 372 tokens MCP, de los cuales 7 seguían siendo válidos. Estos tokens pueden ampliar el riesgo cuando los asistentes de IA invocan workflows o interactúan con el entorno de n8n.

Tokens sin caducidad y versiones desactualizadas

Los tokens más antiguos pueden no incluir el claim exp y, por tanto, seguir siendo válidos indefinidamente. n8n introdujo una caducidad predeterminada de 30 días en la versión 1.78.0, publicada en febrero de 2025, pero el cambio no invalida automáticamente los tokens generados anteriormente.

El riesgo se suma a la exposición de las instancias: más de 100.000 aparecían visibles mediante Shodan. Además, había más de 50 avisos de seguridad desde enero de 2026; a 31 de marzo de 2026, el 58 % de las instancias analizadas ejecutaba versiones afectadas por al menos un aviso.

Entre ellos figura CVE-2025-68613, con una puntuación CVSS de 9.9 e incluida en el catálogo KEV el 11 de marzo de 2026. Sin embargo, no es necesaria para el escenario basado en tokens válidos.

Revocación inmediata y verificación de los sistemas conectados

Los administradores deberían:

1. revocar y regenerar los tokens de n8n y MCP expuestos;
2. buscar tokens, hostnames y referencias a credenciales en repositorios públicos y privados;
3. actualizar n8n a versiones no afectadas por los avisos;
4. aplicar caducidades breves y rotación automática;
5. limitar la exposición a Internet y filtrar el acceso a las API;
6. revisar workflows, logs de ejecución, cuentas y sistemas downstream;
7. proteger N8N_ENCRYPTION_KEY y reducir los privilegios de las credenciales utilizadas por los workflows.

La presencia de un token en un commit histórico debe tratarse como una posible compromisión, aunque el archivo se haya eliminado posteriormente.