n8n self-hosted: actualizá ya por 14 vulnerabilidades corregidas
n8n corrigió 14 vulnerabilidades de seguridad en su versión self-hosted. Te contamos qué versiones instalar, qué fallas afectan a una pyme y cómo actualizar sin riesgos.
10 min de lectura Investigado y publicado con Claude
En este artículo
Si tenés n8n instalado en tu propio servidor (self-hosted), tenés que actualizarlo: el boletín de seguridad que n8n publicó el 1 de octubre de 2026 informa 14 vulnerabilidades (10 de severidad alta y 4 media) que se corrigen en las versiones 2.41.4 (canal estable), 2.42.1 (canal beta) y 1.123.83 (rama 1.x). Si usás n8n Cloud, no tenés que hacer nada: según el mismo aviso, esas instancias reciben el parche de forma automática. En esta nota te contamos qué fallas son las más relevantes para una pyme, cómo saber si estás expuesto y qué pasos seguir hoy.
Qué publicó n8n y a quién afecta#
El aviso oficial, publicado en el foro de la comunidad de n8n el 1 de octubre de 2026, agrupa 14 avisos de seguridad de GitHub (identificados con códigos GHSA) que el equipo había publicado el 30 de septiembre en su página de avisos de seguridad. La recomendación textual es: "If you are running a self-hosted n8n instance on a version below the fixed versions listed above, we recommend upgrading at your earliest convenience" (si tenés una instancia self-hosted con una versión anterior a las corregidas, actualizá cuanto antes).
Las versiones que corrigen el problema, según el boletín del 1 de octubre, son:
| Rama de n8n | Versión corregida | Para quién |
|---|---|---|
| Estable (2.41.x) | 2.41.4 o superior | La mayoría de las instalaciones en producción |
| Beta (2.42.x) | 2.42.1 o superior | Quienes usan el canal más reciente |
| Rama 1.x | 1.123.83 o superior | Instalaciones que todavía no migraron a la versión 2 |
| n8n Cloud | Automático | No requiere acción |
Al momento de escribir esta nota, la documentación de n8n indica que la versión estable vigente es la 2.41.6 y la beta es la 2.42.2, así que si vas a actualizar, lo lógico es ir directamente a la última de tu canal.
El boletín no informa que estas fallas se estén explotando activamente. Aun así, varias permiten actuar sin estar logueado o escalar permisos dentro de la instancia, y n8n suele tener guardadas las credenciales de los sistemas más sensibles de una empresa: CRM, base de datos, correo, Mercado Pago, WhatsApp. Por eso conviene tratarlo como una actualización prioritaria y no dejarlo para "cuando haya tiempo".
Las fallas más importantes, explicadas sin tecnicismos#
No todas las vulnerabilidades afectan a todas las instalaciones: muchas dependen de qué nodos usás y de quién tiene acceso a tu n8n. Estas son las que más conviene revisar.
Fallas que se pueden aprovechar sin usuario#
- Creación ilimitada de registros OAuth (GHSA-3qcw-p65v-c7vq). Según el aviso de GitHub, tiene un puntaje CVSS v4 de 8,2 y no requiere autenticación: un atacante puede generar registros sin límite en la base de datos de n8n hasta llenar el disco. El resultado práctico es que tu servidor se queda sin espacio y tus automatizaciones dejan de funcionar.
- Aprobaciones falsas en "Send and Wait" (GHSA-728h-pmr2-7cgh). El nodo Send and Wait se usa para pedir una aprobación humana antes de seguir (por ejemplo, "¿apruebo este pago?" o "¿envío este presupuesto?"). El aviso explica que alguien que tenga el token de reanudación de una ejecución podía aprobarla sin la firma correspondiente, y que las acciones siguientes se ejecutan con las credenciales del dueño del flujo. Tiene un CVSS v4 de 7,0.
- Código malicioso en el chat público (GHSA-x5cw-hm7v-q7mj). Si publicaste un chat de n8n sin autenticación (muy común en chatbots de atención al cliente), el parámetro de estilos personalizados (customCss) no se filtraba bien y permitía inyectar código. Según el aviso, eso podía comprometer las sesiones de usuarios logueados en la instancia. Los chats publicados con autenticación de usuarios de n8n no están afectados.
Fallas que necesitan un usuario dentro de n8n#
- Inyección SQL en el nodo Microsoft SQL (GHSA-5qpp-pqww-h7fp). Si un flujo mete datos que vienen de afuera (un formulario, un webhook) directamente en el campo Query, alguien externo podía ejecutar consultas SQL arbitrarias con los permisos de la credencial guardada. El aviso recomienda, además de actualizar, pasar los valores dinámicos a "Query Parameters" en lugar de interpolarlos en el texto de la consulta.
- Ejecución de código desde el nodo Git (GHSA-x8wx-g24x-3549). Con CVSS 7,7, permite a un usuario con acceso a n8n que apunte el nodo Git a un repositorio manipulado ejecutar código con los permisos del proceso de n8n, según el aviso. Afecta también a la rama 1.x.
- Credenciales usadas sin permiso en flujos compartidos (GHSA-r6g9-5cpp-ppwr y GHSA-x25p-9mr6-cwgp). Son controles incompletos que permitían a un editor usar credenciales a las que no tenía acceso. Para la rama 1.x, el aviso GHSA-r6g9-5cpp-ppwr indica que se corrige en la 1.123.83.
Si en tu n8n trabaja una sola persona de confianza, el riesgo de este segundo grupo es menor. Si hay varios usuarios, freelancers o proveedores con acceso, es justamente el escenario que estas fallas aprovechan.
No es un caso aislado: el ritmo de parches de n8n#
Este boletín llega dos semanas después de otra tanda de avisos. El 16 de septiembre de 2026, n8n publicó diez avisos más en su página de seguridad, entre ellos uno de severidad alta (CVSS 8,3) que permitía a un miembro común extraer en texto plano credenciales de otros usuarios, incluidos administradores, a través de agentes de IA (GHSA-9rhv-fhr8-7q5r). Ese caso se corrigió en las versiones 2.40.1 y 2.39.6.
La lectura para una pyme es simple: n8n saca una versión menor casi todas las semanas (la propia documentación lo dice: "n8n releases a new minor version most weeks") y los parches de seguridad viajan en esas versiones. Una instalación self-hosted que se actualiza "una vez al año" acumula fallas conocidas y públicas. Ya lo vimos con otros productos: en el blog repasamos hace poco el parche urgente de Fortinet FortiMail y la alerta por las fallas de Citrix NetScaler, donde la demora en actualizar es lo que más expone a las empresas.
Qué hacer ahora#
Estos son los pasos que recomendamos para una pyme con n8n self-hosted, en orden:
- Fijate qué versión tenés. Revisala en la interfaz de n8n o en la etiqueta de la imagen o el paquete que instalaste. Si es anterior a 2.41.4 (estable), 2.42.1 (beta) o 1.123.83 (rama 1.x), estás dentro del alcance del boletín.
- Hacé un backup antes de tocar nada. Exportá los flujos y respaldá la base de datos y la configuración del servidor (incluida la clave con la que n8n cifra las credenciales), para poder volver atrás si algo falla.
- Actualizá a la última versión de tu canal. Hoy eso es la 2.41.6 si usás estable, según la documentación de n8n. Si seguís en la rama 1.x, actualizá al menos a la 1.123.83 y planificá la migración a la versión 2.
- Probá los flujos críticos. Después de actualizar, ejecutá manualmente los flujos que mueven plata, pedidos o clientes, y revisá que los webhooks respondan.
- Si no podés actualizar hoy, aplicá mitigaciones temporales. Los avisos de n8n coinciden en estas medidas parciales:
- limitar el acceso a la instancia solo a usuarios de confianza (por ejemplo, detrás de una VPN o con restricción por IP);
- exigir autenticación en los nodos Chat Trigger y revisar sus valores de customCss;
- no usar Send and Wait para aprobar acciones críticas en flujos con disparadores públicos;
- deshabilitar el nodo Git si no lo usás, con la variable
NODES_EXCLUDE; - poner alertas de uso de disco en el servidor.
- Revisá quién tiene acceso. Eliminá usuarios que ya no trabajan con vos y revisá qué flujos y credenciales están compartidos. El mismo criterio de permisos mínimos aplica al resto de tu infraestructura: por ejemplo, contamos cómo usar el control de accesos por roles y las alertas de gasto de Cloudflare.
- Armá una rutina. Definí una ventana fija (por ejemplo, cada dos semanas) para revisar los avisos de seguridad de n8n y actualizar.
Si te tienta probar las novedades de la última versión, como las que repasamos en la nota sobre n8n 2.42 y sus mejoras para agentes de IA, tené en cuenta que la 2.42 todavía es el canal beta: para producción, la recomendación de n8n es usar el estable.
Self-hosted o n8n Cloud: qué cambia en seguridad#
Este boletín deja clara una diferencia práctica entre las dos formas de usar n8n:
| Aspecto | n8n self-hosted | n8n Cloud |
|---|---|---|
| Aplicación de parches | La hace tu equipo o tu proveedor | Automática, según el aviso de n8n |
| Control del servidor y los datos | Total | Lo gestiona n8n |
| Responsabilidad ante fallas como estas | Tuya | Compartida con n8n |
| Necesidad de backups y monitoreo propios | Sí | Menor |
Self-hosted sigue siendo una gran opción para muchas pymes, sobre todo por costos y control de datos, pero solo si alguien se ocupa del mantenimiento. Una instancia expuesta a internet, con credenciales de todos tus sistemas y sin actualizar, es un riesgo concreto.
Preguntas frecuentes#
¿Tengo que hacer algo si uso n8n Cloud?#
No. El boletín de n8n aclara que las instancias de n8n Cloud reciben los parches de forma automática.
¿Estas vulnerabilidades se están explotando?#
El aviso oficial no informa explotación activa. Igualmente, los detalles técnicos ya son públicos en GitHub, lo que facilita que alguien intente aprovecharlos contra instancias sin actualizar.
¿Qué versión de n8n tengo que instalar?#
Como mínimo, 2.41.4 en el canal estable, 2.42.1 en beta o 1.123.83 en la rama 1.x. Lo más recomendable es ir a la última versión de tu canal: hoy, 2.41.6 en estable.
¿Uso un chatbot hecho con n8n en mi web: estoy en riesgo?#
Si el chat está publicado sin autenticación y tu versión es anterior a las corregidas, sí estás dentro del alcance de la falla del Chat Trigger. La solución es actualizar; mientras tanto, revisá que el campo customCss no tenga contenido extraño.
¿Actualizar puede romper mis flujos?#
Entre versiones de la misma rama el riesgo es bajo, pero siempre conviene hacer un backup y probar los flujos críticos después. El salto de la rama 1.x a la 2 sí requiere revisar los cambios incompatibles antes.
Te ayudamos a mantener tu n8n seguro#
En Mark-Co Digital instalamos y mantenemos instancias de n8n self-hosted para pymes de toda Argentina: actualizaciones, backups, monitoreo y revisión de accesos. Si querés que revisemos tu instalación o que nos ocupemos de mantenerla al día, mirá nuestro servicio de actualización de n8n self-hosted, el de backups y seguridad para n8n, conocé todo lo que hacemos en automatización con n8n, o escribinos desde nuestra página de contacto.
Fuentes#
- Security update — 01 October 2026 (n8n Community)
- Security advisories del repositorio n8n-io/n8n (GitHub)
- GHSA-3qcw-p65v-c7vq: Unauthenticated Unbounded OAuth Client Persistence via the Authorize Endpoint
- GHSA-728h-pmr2-7cgh: Send-and-Wait HMAC Bypass Allows Unauthenticated Approval
- GHSA-x5cw-hm7v-q7mj: n8n Chat Trigger Stored XSS via customCss Parameter
- GHSA-5qpp-pqww-h7fp: SQL Injection in the Microsoft SQL Node
- GHSA-x8wx-g24x-3549: Code Execution in Git Node Log Operation
- GHSA-r6g9-5cpp-ppwr: Shared-Workflow Credential Check Misses Nested and Tool Inline Sub-Workflows
- GHSA-9rhv-fhr8-7q5r: Inline Agent Node-Tool Introspection Decrypts Any Instance Credential
- Release notes 2.x (documentación de n8n)