420.452 instancias de n8n expuestas en internet (2026)

En pocas palabras: Según ZoomEye, el 28 de octubre de 2026 había 420.452 instancias de n8n indexadas con app=”n8n” (401.268 por título), frente a 117.523 de Gitea. Esa exposición no es vulnerabilidad en sí, pero cada instancia guarda credenciales de API dentro de sus workflows.

Gitea suma 117.523 instancias indexadas y n8n llega a 420.452, según una medición de ZoomEye del 28 de octubre de 2026. La exposición de instancias n8n a internet no implica vulnerabilidad en sí misma, pero significa que esa cantidad de servidores públicos guardan credenciales de API dentro de sus workflows, listas para ser robadas si la configuración quedó floja.

n8n es una herramienta de automatización de workflows con licencia fair-code que combina funciones de IA con procesos de negocio, según su documentación oficial. Gitea es un servidor Git autohospedado que funciona como alternativa liviana a GitHub o GitLab. Ambos guardan secretos de terceros (tokens, claves SSH, credenciales de API) y por diseño suelen quedar accesibles desde afuera.

¿Qué significa exposición de instancias n8n a internet?

Significa que el servidor responde a pedidos públicos sin estar restringido a una red privada o VPN. No es automáticamente un problema: n8n necesita ser alcanzable por webhooks de proveedores externos, así que su arquitectura empuja a los equipos a publicarlo con una dirección pública. El problema aparece cuando esa exposición se combina con configuración default, sin control de registro de usuarios ni auditoría de qué credenciales quedaron pegadas a workflows viejos.

Gitea, en cambio, puede vivir perfectamente detrás de una VPN porque solo lo necesitan tocar los desarrolladores del equipo. Esa diferencia de arquitectura explica buena parte de la brecha entre 117.523 y 420.452: no es que n8n sea más popular, es que su modelo de uso casi obliga a exponerlo. Más contexto en cómo funcionan las expresiones en n8n.

¿Qué midió ZoomEye sobre Gitea y n8n en octubre de 2026?

ZoomEye registró, el 28 de octubre de 2026, 117.523 assets que coinciden con app=”Gitea”, 420.452 con app=”n8n” y 401.268 con title=”n8n”, según el análisis publicado en dev.to. Son conteos de activos indexados que identifican al software, no conteos de secretos expuestos ni de vulnerabilidades confirmadas.

Ojo con esto: el propio artículo aclara que estos números no dicen nada sobre postura de seguridad. Una instancia bajo app=”n8n” puede tener SSO activo, registro restringido a un dominio corporativo y logs de cada login, o puede ser una instalación default que alguien levantó para “probar” en 2024 y nunca borró. El fingerprint identifica el software, no la configuración.

Tampoco hay deduplicación real. Una sola empresa puede tener varias instancias publicadas, y un proveedor de hosting puede correr cientos detrás de un mismo patrón de dominio. Así que cualquier argumento de “porcentaje de mercado” construido sobre estos números es, en el mejor caso, aproximado.

¿Qué credenciales guardan realmente Gitea y n8n?

Gitea guarda repositorios completos, con todo lo que los desarrolladores commitearon alguna vez (y eso incluye archivos .env olvidados, más de lo que a cualquiera le gustaría admitir). También concentra deploy keys, webhook secrets, tokens de acceso y, en muchas instalaciones, las claves SSH que se usan para pushear código. Esto se conecta con lo que analizamos en conectar n8n con Airtable paso a paso.

n8n guarda definiciones de workflow que se conectan a servicios externos, lo cual significa que las credenciales de API de esos servicios quedan adentro de la configuración del workflow.

Ejemplo hipotético: imaginá un workflow que envía correos a través de un proveedor de email transaccional, se conecta a una base de datos relacional de la empresa y dispara una notificación a un canal de mensajería interno del equipo. Esa única pantalla de n8n concentra, en los hechos, las llaves de acceso a esos tres sistemas distintos: quien comprometa esa instancia no roba un login, roba la posibilidad de mandar correos en nombre de la empresa, leer o escribir en la base y hablar en el canal como si fuera el equipo.

Comprometer cualquiera de las dos plataformas no da solo un login. Da el conjunto completo de credenciales que esa plataforma tenía a cargo. Por eso una instancia pública merece más atención de la que sugiere el número de assets, y por eso el número en sí mismo da menos miedo del que debería dar un titular.

¿Cómo funciona la autenticación por defecto en n8n self-hosted?

La superficie administrativa de n8n separa el despliegue y la configuración de la construcción de workflows, según la documentación oficial, e incluye gestión del owner de la instancia y administración de usuarios. El riesgo concreto: una instancia donde cualquier visitante puede crearse una cuenta, o donde el owner sigue usando el mail que puso durante el setup inicial, delegó la custodia de esas credenciales a quien la encuentre primero.

¿Alguien revisa esto en la práctica? En la mayoría de los despliegues chicos, no. El equipo levanta n8n para automatizar algo puntual, funciona, y la revisión de quién tiene acceso administrativo queda para “después”. Después nunca llega. En usar el nodo HTTP Request correctamente profundizamos sobre esto.

Qué configuraciones de seguridad revisar en Gitea: INSTALL_LOCK, SECRET_KEY y DISABLE_REGISTRATION

Tres variables del cheat sheet oficial de configuración de Gitea marcan la diferencia entre una instancia blindada y una abierta de par en par.

• INSTALL_LOCK: controla el acceso a la pantalla de instalación. Si está en true, esa pantalla deja de ser alcanzable. Una instancia que se configuró y nunca se bloqueó sigue mostrando su pantalla de setup inicial a cualquiera que pase, lo que es una invitación innecesaria.
• SECRET_KEY: se genera al azar en cada instalación. La documentación es categórica: los datos cifrados con esta clave, incluidos los secretos de doble factor, no se pueden descifrar si la clave se pierde. Copiarla entre entornos para “simplificar” una migración debilita la garantía en todos los lugares donde se copió.
• DISABLE_REGISTRATION: viene en true por defecto en la configuración documentada, lo que significa que solo los administradores pueden crear cuentas. El modo de falla acá es conocido: una página de registro que quedó abierta en una instancia pensada para un equipo chico, y que se descubre recién cuando aparecen cuentas desconocidas en la lista de usuarios.

Qué revisar en la administración de n8n: owner, usuarios y credenciales de workflows

Confirmar quién tiene el rol de owner y auditar las credenciales activas son los dos puntos no negociables. Las plataformas de automatización acumulan conexiones porque sacar una corre el riesgo de romper un proceso que nadie se acuerda haber escrito.

Una secuencia de revisión razonable no toma más de una hora:

• Confirmá la versión y la política de registro primero. En n8n, revisá si la gestión de usuarios está habilitada y quién tiene la cuenta de owner.
• Enumerá todo lo que la instancia puede alcanzar. Listá las credenciales adjuntas a workflows activos y confirmá que cada una siga siendo necesaria.
• Decidí si la instancia debería ser pública. Un servidor de automatización muchas veces puede andar detrás de un reverse proxy que limite el acceso a un conjunto chico de rutas permitidas.

Qué significa esto para quienes tienen Gitea o n8n autohospedado en Argentina y España

Si administrás una instancia self-hosted desde Argentina o España, la pregunta no es si aparecés en un conteo de ZoomEye. La pregunta es si alguien reviso INSTALL_LOCK, DISABLE_REGISTRATION y la lista de credenciales de workflows en los últimos tres meses. Spoiler: en la mayoría de los casos, no.

Un repositorio de código que solo necesitan tocar cinco desarrolladores no tiene por qué responder al internet abierto. Y un servidor de automatización, aunque necesite recibir webhooks externos, puede terminar detrás de un reverse proxy que solo deje pasar las rutas que realmente usás. Si estás evaluando dónde correr este tipo de infraestructura con más control sobre la red y los accesos, en donweb.com hay servidores y hosting pensados justamente para ese nivel de configuración.

Errores comunes al autohospedar Gitea o n8n

• Copiar SECRET_KEY entre entornos de Gitea. Parece un atajo para migrar más rápido, pero debilita el cifrado en cada entorno donde quedó esa copia.
• Dejar DISABLE_REGISTRATION sin tocar en falso. Si por algún motivo quedó en false, cualquiera puede crearse una cuenta sin pasar por un admin.
• No auditar credenciales viejas en workflows de n8n. Una conexión a una API que ya no se usa sigue siendo una llave activa que alguien podría explotar.
• Confundir “no está en los índices públicos” con “está seguro”. Que una instancia no aparezca en ZoomEye hoy no significa que la configuración interna esté bien.

Preguntas Frecuentes

¿Cuántas instancias de n8n están expuestas públicamente en 2026?

ZoomEye contó 420.452 assets con fingerprint app=”n8n” y 401.268 con title=”n8n” el 28 de octubre de 2026. Son conteos de activos indexados, no de instancias vulnerables ni comprometidas. Tema relacionado: configurar notificaciones de Slack.

¿Qué datos guarda Gitea que pueden ser robados?

Gitea guarda repositorios completos con lo que los desarrolladores hayan commiteado, además de deploy keys, webhook secrets, tokens de acceso y, en muchas instalaciones, claves SSH usadas para pushear código.

¿Cómo configuro INSTALL_LOCK en Gitea?

INSTALL_LOCK se setea en el archivo app.ini de Gitea. Poniéndolo en true, la pantalla de instalación inicial deja de ser accesible, lo que evita que cualquiera reconfigure una instancia que ya está en producción.

¿Es seguro tener n8n autohospedado y público en internet?

Puede serlo si la gestión de usuarios está restringida y el owner de la instancia es verificable, pero el riesgo sube si cualquiera puede registrarse o si las credenciales de workflows no se auditan. La exposición pública en sí misma no es el problema; la configuración default sí.

¿Qué credenciales quedan guardadas en los workflows de n8n?

Las credenciales de API de cada servicio externo conectado al workflow (bases de datos, servicios de email, webhooks de terceros) quedan almacenadas dentro de la definición del workflow mismo.

Qué está confirmado y qué no

Confirmado: los conteos de ZoomEye (117.523 para Gitea, 420.452 para n8n, 401.268 para title=”n8n”) del 28 de octubre de 2026, y las tres variables de seguridad documentadas oficialmente por Gitea.

No confirmado: cuántas de esas instancias tienen configuración default, cuántas repiten organización (deduplicación) y cuántas efectivamente tienen credenciales explotables. El dato de ZoomEye identifica software, no postura de seguridad.

Conclusión

Los números de ZoomEye no son una alarma de seguridad, son un punto de partida para una revisión que cualquier equipo con Gitea o n8n autohospedado puede hacer en una hora. Revisá INSTALL_LOCK y DISABLE_REGISTRATION en Gitea, auditá el owner y las credenciales de workflows en n8n, y preguntate si esa instancia necesita de verdad estar abierta a todo internet o si puede vivir detrás de un reverse proxy. El dato concreto que importa no es cuántas instancias hay indexadas, es si la tuya pasó esa revisión.

Fuentes

• Gitea – Configuration Cheat Sheet, sección de seguridad
• n8n – Documentación oficial
• dev.to – Gitea at 117,523 and n8n at 420,452
• ZoomEye – búsqueda app=”Gitea”
• ZoomEye – búsqueda app=”n8n”