Investigadores de GitGuardian descubrieron que 321 instancias de n8n eran vulnerables debido a tokens de API expuestos en GitHub. Estos tokens permiten a atacantes acceder a datos sensibles, flujos de trabajo y credenciales almacenadas sin necesidad de explotar vulnerabilidades de software. El riesgo es crítico ya que n8n centraliza la conexión con bases de datos, servicios de IA y nubes corporativas.







Los investigadores de GitGuardian encontraron 321 instancias de n8n que aceptaban tokens de API expuestos en commits públicos de GitHub y demostraron cuatro formas en que los atacantes podrían usarlos para acceder a datos sensibles y credenciales derivadas sin explotar ninguna vulnerabilidad de software.

Escaneamos commits públicos de GitHub en busca de tokens de API de n8n expuestos e identificamos 4,576 credenciales únicas asociadas con 1,255 nombres de host. De las 896 instancias accesibles en el momento de la prueba, 321 aceptaron al menos un token filtrado.

Eso significa que las credenciales filtradas proporcionaron acceso autenticado al 36% de las instancias accesibles que probamos, o aproximadamente al 26% de todos los nombres de host identificados en los commits.

Las implicaciones van mucho más allá de n8n. Las organizaciones utilizan la plataforma de automatización para conectar bases de datos, repositorios de código fuente, entornos de nube, servicios de inteligencia artificial, plataformas de soporte al cliente y otros sistemas internos. Un token de n8n con suficientes privilegios puede exponer definiciones de flujos de trabajo y datos de ejecución, permitir que los atacantes utilicen credenciales almacenadas y, en algunas configuraciones, permitirles extraer los valores de las credenciales subyacentes.

Para medir el radio potencial de impacto, reproducimos cuatro técnicas de ataque prácticas en un entorno de n8n controlado. Cada una requirió únicamente funcionalidad documentada de la API REST y solicitudes HTTP estándar. No fue necesaria la explotación de CVE ni herramientas especializadas.

Por qué n8n es un objetivo de alto valor

n8n es una plataforma de automatización de flujos de trabajo de código abierto y bajo código con soporte para agentes de IA y cientos de integraciones integradas. Las organizaciones la utilizan para conectar herramientas internas, automatizar flujos de trabajo, implementar lógica de negocio y orquestar integraciones de API en sus pilas tecnológicas.

La plataforma puede ser autoalojada o implementada a través de n8n.cloud, y su repositorio de código abierto https://github.com/n8n-io/n8n ha atraído casi 200,000 estrellas en GitHub.

Una instancia de n8n ejecuta flujos de trabajo compuestos por nodos. Algunos nodos activan flujos de trabajo según un horario o a través de webhooks, mientras que otros transforman datos, ejecutan código o se conectan a servicios externos utilizando credenciales almacenadas como claves de API, tokens y contraseñas de bases de datos.

Esas credenciales están cifradas en reposo utilizando un secreto maestro llamado N8N_ENCRYPTION_KEY. Pero n8n todavía necesita descifrarlas y usarlas cada vez que se ejecuta un flujo de trabajo. Por lo tanto, un atacante con suficientes privilegios de API puede referenciar esas credenciales en nuevos flujos de trabajo y hacer que la instancia las use en nombre del atacante.

Con más de 100,000 instancias visibles a través de Shodan [https://www.shodan.io/] y más de 50 avisos de seguridad publicados desde enero de 2026, n8n ha atraído la misma atención que otras plataformas de integración de alto valor.

Al 31 de marzo de 2026, el 58% de las instancias que escaneamos ejecutaban una versión afectada por al menos un aviso de seguridad conocido. Varios CVE recientes permitieron a los atacantes escapar de los sandboxes de ejecución y obtener acceso arbitrario de lectura o escritura al sistema de archivos del host.

El CVE-2025-68613, una vulnerabilidad de inyección de expresiones con una puntuación CVSS de 9.9, fue añadida al catálogo de Vulnerabilidades Explotadas Conocidas de la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. el 11 de marzo de 2026, confirmando su explotación en el mundo real.

Los tokens de API filtrados crean un riesgo independiente. Un atacante no necesita necesariamente explotar una vulnerabilidad de n8n si una credencial válida ya proporciona acceso autenticado a la instancia.

Encontramos 321 instancias que aceptan tokens filtrados

GitGuardian Public Monitoring escanea fuentes públicas en busca de credenciales expuestas. Para esta investigación, recopilamos cada token de API de n8n que había identificado en commits públicos de GitHub desde abril de 2025.

Nuestro pipeline extrajo el nombre de host de n8n enviado junto con cada token, envió una solicitud de validación de solo lectura a la instancia asociada y registró la respuesta.

El escaneo produjo:

Etapa | Recuento
Tokens de API únicos | 4,576
Commits de GitHub que contienen tokens | 5,469
Nombres de host únicos extraídos | 1,255
Instancias accesibles públicamente | 896
Instancias que aceptan un token filtrado | 321

Las 321 instancias confirmadas representan aproximadamente el 36% de las 896 instancias accesibles y el 26% de los 1,255 nombres de host identificados en los commits.

Ejecutamos el mismo proceso contra las claves de la API del Protocolo de Contexto de Modelo (MCP) de n8n encontradas en el mismo conjunto de commits. Los tokens MCP permiten que los asistentes de IA llamen a los flujos de trabajo de n8n a través del Model Context Protocol, lo que los convierte en una superficie de exposición más nueva que la API REST.

De los 372 tokens MCP identificados, siete seguían siendo válidos en el momento de la prueba, aproximadamente el 2%.

Por qué los tokens de n8n filtrados pueden seguir siendo válidos

Una clave de API de n8n es un JSON Web Token firmado con una reclamación de audiencia "aud": "public-api". Un token decodificado se ve así:

{
"sub": "efdf9cca-049a-46aa-afdc-172f0824f6cb",
"iss": "n8n",
"aud": "public-api",
"jti": "aac8a7a8-c8c4-4855-8e8b-2806e90b16e1",
"iat": 1781551662
}

El token registra su tiempo de emisión en la reclamación iat. Las claves de API de n8n más antiguas frecuentemente no contienen ninguna reclamación exp que defina cuándo expiran.

n8n introdujo una expiración predeterminada de 30 días en la versión 1.78.0 en febrero de 2025, pero muchos de los tokens encontrados durante la investigación habían sido generados sin una fecha de expiración. Por lo tanto, una clave enviada a GitHub meses antes podría seguir siendo utilizable hasta que alguien la eliminara o revocara explícitamente.

En la práctica, las claves de API de n8n se comportan de manera diferente a los JWT autónomos que pueden validarse solo con sus firmas. La clave también debe existir todavía en la base de datos de n8n. Un token expuesto en GitHub sigue siendo peligroso mientras la instancia continúe reconociéndolo.

Probar un token candidato requiere una solicitud de solo lectura con la clave pasada a través del encabezado X-N8N-API-KEY:

curl -s -o /dev/null -w "%{http_code}" \
-H "X-N8N-API-KEY: <token>" \
https://n8n.example.com/api/v1/workflows

GET /api/v1/workflows devuelve las definiciones de flujo de trabajo disponibles para el usuario autenticado.

Una respuesta 200 confirma que el token es aceptado. Un 401 indica que el token es inválido, ha sido eliminado de la base de datos o falló la verificación de la firma. Un 404 puede indicar que la API pública está desactivada en la instancia.

La solicitud no realiza cambios en la instancia objetivo.

La URL de la instancia a menudo se envía junto al token

Una clave de API de n8n es útil solo cuando un atacante puede identificar la instancia que la acepta. Sin embargo, en los commits públicos de GitHub, el nombre de host y el token aparecen juntos con frecuencia.

Un archivo .env es un ejemplo común:

N8N_URL="https://n8n.redacted.cloud:5678"
N8N_API_KEY="eyJhREDACTEDPWw4"

También encontramos un patrón más nuevo asociado con los archivos de permisos de Claude Code.

Claude Code puede almacenar comandos de shell permitidos en .claude/settings.json o .claude/settings.local.json. Cuando los usuarios configuran Claude Code para interactuar con n8n, pueden colocar tanto la URL de la instancia como la clave de la API directamente dentro de un comando curl aprobado.

Bash(curl -s "https://automation.redacted.fr/api/v1/workflows" \
-H "X-N8N-API-KEY: eyJhREDACTEDegE")

Estos archivos de configuración pueden entonces ser enviados a un repositorio sin las mismas salvaguardas de .gitignore que los desarrolladores aplican comúnmente a los archivos .env.

El mismo emparejamiento de nombre de host y token apareció bajo varios otros nombres de variables, incluyendo:

N8N_MCP_URL
N8N_WEBHOOK_BASE_URL
process.env.N8N_URL
os.getenv("N8N_HOST", "...")

Debido a que el nombre de host solía estar disponible en el mismo commit que el token, nuestro pipeline no requirió un paso separado de descubrimiento de infraestructura.

Qué expone un token de n8n autenticado

Un token de API de n8n proporciona acceso según los permisos del usuario que lo creó. En la práctica, muchos de los tokens expuestos parecían pertenecer a propietarios de instancias o administradores, probablemente porque esos eran los usuarios que configuraban las integraciones y enviaban las claves.

Dependiendo del rol de la cuenta, la API REST pública puede exponer:

* GET /api/v1/users: Nombres de usuario, direcciones de correo electrónico, fechas de creación de cuentas e invitaciones pendientes. Parte de la información está restringida a los propietarios de la instancia.
* GET /api/v1/workflows: Definiciones completas de flujos de trabajo, incluyendo la configuración de nodos, código JavaScript o Python en nodos de Código, consultas SQL y secretos hard-coded en los parámetros del flujo de trabajo.
* GET /api/v1/credentials: Nombres, tipos e información de uso compartido de credenciales, pero no los valores subyacentes. Este endpoint está restringido a propietarios y administradores.
* GET /api/v1/executions: Historial de ejecución de flujos de trabajo. Añadir ?includeData=true puede devolver la carga útil completa de entrada y salida de cada ejecución.
* GET /api/v1/data-tables: Filas de tablas visibles para el usuario autenticado.
* GET /api/v1/variables: Nombres de variables y sus contenidos. Este endpoint está restringido a propietarios y administradores.

Las definiciones de flujos de trabajo crean la exposición más inmediata porque la API devuelve configuraciones completas de nodos. Si un desarrollador colocó una clave de API o token directamente en un parámetro de nodo en lugar de usar el almacén de credenciales de n8n, el valor puede aparecer en texto plano.

El endpoint de credenciales en sí no devuelve los valores secretos almacenados. Sin embargo, como demuestran nuestras pruebas controladas, un atacante con permiso para crear y ejecutar flujos de trabajo puede referenciar una credencial almacenada y hacer que n8n la use o la transmita.

El endpoint de auditoría proporciona un mapa de ataque

El endpoint de auditoría de n8n puede proporcionar a un usuario autenticado un informe de seguridad de la instancia:

curl -H "X-N8N-API-KEY: $JWT" \
-d "{}" \
-H "Content-Type: application/json" \
https://$N8N_INSTANCE/api/v1/audit

La respuesta puede identificar:

* Exposiciones potenciales de inyección SQL en flujos de trabajo
* Nodos con acceso al sistema de archivos
* Webhooks no protegidos
* La versión de n8n en ejecución, que puede compararse con CVEs conocidos
* Credenciales no utilizadas
* Nodos de alto riesgo o instalados por la comunidad
* Funciones de seguridad habilitadas
* Listas blancas y negras de nodos
* Configuraciones de telemetría

Para un administrador legítimo, esta información sirve para revisiones de seguridad. Para un atacante con un token privilegiado filtrado, puede proporcionar un mapa priorizado de las rutas de ataque más prometedoras de la instancia.

Cuatro técnicas de ataque contra una instancia totalmente parcheada

GitGuardian no realizó las siguientes técnicas de explotación contra sistemas de terceros expuestos. Las reproducimos en un despliegue de n8n controlado construido específicamente para la investigación.

El flujo de trabajo de prueba contenía tres debilidades deliberadas:

* Un formulario web almacenaba envíos en una tabla de datos accesible a través de flujos de trabajo autenticados.
* Un nodo de OpenAI procesaba cada envío utilizando un objeto de credencial almacenada.
* Un nodo de Solicitud HTTP publicaba el resultado en GitHub utilizando un token hard-coded en sus parámetros de nodo.

Usando ese entorno, demostramos cuatro técnicas, progresando desde la enumeración pasiva hasta la exfiltración activa de credenciales.

Ejemplo de flujo de trabajo de n8n

TÉCNICA 1: Enumerar la instancia

GET /api/v1/users devolvió cuatro cuentas: el propietario de la instancia, dos usuarios activos y un registro pendiente.

GET /api/v1/workflows devolvió nueve definiciones completas de flujos de trabajo. En el flujo de trabajo objetivo, los parámetros de un nodo de Solicitud HTTP contenían un token de GitHub en texto plano.

Esta primera técnica no requirió ninguna modificación del flujo de trabajo. La información expuesta ya estaba disponible a través de operaciones de lectura permitidas para la cuenta autenticada.

TÉCNICA 2: Usar una credencial de OpenAI almacenada

GET /api/v1/credentials listó cada objeto de credencial almacenada, incluyendo uno llamado "OpenAI account". El endpoint reveló su nombre, tipo e identificador, pero no la clave de API en sí.

Creamos un flujo de trabajo con un disparador de Programación y un nodo de OpenAI que referenciaba la credencial por su ID, y luego lo activamos.

Dos trucos hacen que esto funcione. El disparador de Programación se activa automáticamente después de unos 10 segundos, dando tiempo al flujo de trabajo para completarse. Luego, GET /api/v1/executions?includeData=true recupera el registro de ejecución completo. Debido a que n8n persiste la salida completa de cada nodo, la respuesta de OpenAI aparece en texto plano.

Logramos ejecutar prompts arbitrarios de OpenAI utilizando la credencial almacenada de la instancia sin haber visto nunca su valor.

TÉCNICA 3: Leer la tabla de datos

Se aplican los mismos dos trucos.

Creamos un flujo de trabajo con un disparador de Programación y un nodo de Tabla de Datos configurado para recuperar todas las filas, y luego lo activamos. GET /api/v1/executions?includeData=true devolvió el registro de ejecución segundos después, con cada fila en texto plano.

Se exfiltraron cuatro filas, incluyendo nombres, direcciones de correo electrónico, respuestas de formularios y estados de procesamiento.

El flujo de trabajo fue luego eliminado.

TÉCNICA 4: Exfiltrar la credencial raw de OpenAI

La cuarta técnica fue más allá de usar una credencial almacenada y extrajo su valor subyacente.

Iniciamos un escucha HTTP, luego creamos un flujo de trabajo con un disparador de Programación y un nodo de Solicitud HTTP.

El truco clave es que el nodo de Solicitud HTTP puede usar una credencial almacenada de n8n como su método de autenticación mientras envía solicitudes a cualquier URL. Configuramos el nodo para usar la credencial almacenada de OpenAI y lo apuntamos a nuestro escucha.

Cuando el flujo de trabajo se activó, n8n adjuntó el valor de la credencial como un token Bearer en el encabezado de Autorización saliente. El escucha capturó la clave de API raw segundos después de la activación.

El flujo de trabajo fue luego eliminado.

Juntos, estos pasos muestran cómo un atacante puede progresar desde un token de n8n filtrado hasta una exposición más amplia de credenciales y datos utilizando la funcionalidad legítima de la plataforma:

1. Enumerar usuarios, flujos de trabajo y configuración de seguridad.
2. Identificar objetos de credenciales almacenadas y secretos hard-coded.
3. Usar credenciales almacenadas sin ver sus valores.
4. Leer datos disponibles para los flujos de trabajo.
5. Hacer que n8n transmita una credencial almacenada a una infraestructura controlada por el atacante.

Eliminar el flujo de trabajo malicioso también eliminó los registros de ejecución asociados de la interfaz, dejando potencialmente a los defensores con evidencia limitada para investigar.

Flujos de trabajo del mundo real mostraron debilidades similares

La demostración controlada no se basó en una configuración puramente teórica. Durante la investigación, encontramos instancias reales de n8n que contenían patrones expuestos similares.

Un flujo de trabajo realizaba automáticamente copias de seguridad de sus propias definiciones en un repositorio público de GitHub. Una clave de despliegue SSH había sido hard-coded directamente en uno de sus nodos.

El historial de Git del repositorio contenía versiones anteriores de cada flujo de trabajo, y la clave SSH seguía siendo válida.

El flujo de trabajo estaba, efectivamente, publicando su propia configuración sensible y credenciales cada vez que se ejecutaba.

Este caso ilustra por qué las plataformas de automatización de flujos de trabajo pueden crear radios de impacto inusualmente grandes. Se sitúan entre múltiples sistemas, procesan datos sensibles y se autentican rutinariamente en servicios externos. Una debilidad en un solo flujo de trabajo puede exponer el acceso mucho más allá de la propia plataforma de automatización.

La divulgación responsable produjo respuestas limitadas

Encontrar una credencial expuesta válida es solo el primer paso. El riesgo persiste hasta que la organización afectada la revoque y aborde cualquier exposición derivada.

Intentamos la divulgación responsable con siete organizaciones:

* Tres proveedores de hosting asociados colectivamente con aproximadamente 100 instancias afectadas
* Cuatro empresas individuales

Un proveedor de hosting no respondió. Tres de las cuatro empresas individuales tampoco respondieron.

Una empresa operaba un programa de bug bounty, reconoció el informe, pagó una recompensa de $1,200 y revocó la credencial inmediatamente. Esa combinación de reconocimiento y remediación rápida fue la excepción.

GitGuardian también realizó varias divulgaciones directamente a n8n durante la investigación. n8n reconoció los informes, dijo que estaba al tanto de los problemas y planeaba abordarlos, y posteriormente cerró los informes. Al momento de la publicación, GitGuardian no había confirmado independientemente que los arreglos relacionados hubieran sido lanzados.

Aproximadamente el 30% de las 321 instancias afectadas estaban alojadas en n8n.cloud o servicios gestionados similares.

GitGuardian Public Monitoring ya identifica tokens de API de n8n expuestos y notifica a los desarrolladores afectados a través del programa de divulgación Good Samaritan [https://www.gitguardian.com/good-samaritan] de la empresa. Los hallazgos también llevaron a GitGuardian a actualizar su detector de claves de API de n8n y sus comprobaciones de validez para mejorar la precisión de la detección.

Conclusiones

Un token de n8n filtrado no es una exposición de credenciales aislada. Un token con suficientes privilegios puede exponer definiciones de flujos de trabajo, secretos hard-coded, datos de ejecución y tablas internas. También puede permitir que un atacante use credenciales almacenadas o, mediante la creación de un flujo de trabajo que las envíe a un endpoint externo, extraiga sus valores subyacentes.

No se requirió ningún CVE ni herramientas especializadas en nuestras pruebas controladas. Unas pocas solicitudes HTTP estándar fueron suficientes para pasar de un token expuesto al acceso a datos sensibles y credenciales derivadas. Un atacante podría entonces eliminar el flujo de trabajo y sus registros de ejecución asociados, dejando a los defensores con evidencia limitada dentro del propio n8n.

Revocar el token de n8n expuesto es el primer paso, pero puede no ser el último. Las organizaciones deben determinar a qué flujos de trabajo, datos y credenciales derivadas podía acceder la cuenta, revisar la instancia en busca de cambios no autorizados y rotar las credenciales conectadas donde no se pueda descartar la exposición.

Las plataformas de automatización crean un radio de impacto particularmente grande porque se encuentran en el centro de las integraciones de una organización. Un solo token puede proporcionar un camino hacia el control de fuentes, bases de datos, servicios en la nube, APIs de IA, plataformas de soporte y datos de clientes. El riesgo no está definido solo por la instancia de n8n, sino por cada sistema conectado a ella.



Fuente:
THN