CVE-2026-21877: por qué está justificada la puntuación CVSS 9.9
La vulnerabilidad está clasificada como CWE-434 — subida de archivo de tipo peligroso sin restricciones. El nodo Git de n8n permite, bajo ciertas condiciones, a un usuario autenticado escribir un archivo arbitrario en el sistema de archivos del servidor. Un atacante puede escribir un script en un directorio ejecutado por el proceso n8n y luego activarlo mediante un workflow para lograr ejecución remota de código.
El vector de ataque es de red, sin interacción adicional del usuario requerida. El alcance cambia (scope: Changed), lo que significa que el impacto va más allá del proceso n8n: la confidencialidad, integridad y disponibilidad del host quedan comprometidas. La puntuación EPSS alcanza el 5,449% (percentil 92), lo que indica una alta probabilidad de explotación activa en 30 días.
La alerta AL26-001 del Centro Canadiense de Ciberseguridad también cubre CVE-2026-21858 (validación de entrada insuficiente en peticiones webhook, CVSS 10.0 según algunas fuentes) y CVE-2025-68613 (aislamiento insuficiente de expresiones en configuraciones de workflows). Las tres deben abordarse en el mismo ámbito de remediación.
Quién está expuesto y en qué rango de versiones
- Todas las instancias autoalojadas de n8n >= 0.123.0 y < 1.121.3 son vulnerables a CVE-2026-21877 según el advisory de GitHub GHSA-v364-rw7m-3263.
- Las instancias detrás de un proxy inverso no están protegidas: la vulnerabilidad es autenticada — una cuenta comprometida o un colaborador interno malicioso son suficientes; el perímetro de red no cambia la exposición.
- Tanto los despliegues Docker como npm están afectados: el vector es el nodo Git, presente en todas las distribuciones de n8n independientemente del método de instalación.
- Las instancias n8n Cloud gestionadas por n8n.io recibieron el parche sin ninguna acción requerida por el operador.
- CVE-2025-68613 cubre las versiones 0.211.0 a < 1.120.4: si aún no has alcanzado la 1.120.4, estás expuesto a ambas CVE simultáneamente.
- CVE-2026-21858 afecta a las versiones 1.65.0 a < 1.121.0: actualizar a 1.121.3 resuelve las tres CVE en una sola operación.
- La puntuación EPSS del 5,449% coloca esta CVE en el percentil 92 de probabilidad de explotación activa, justificando la prioridad del parche sobre el resto del mantenimiento programado.
Verificar la versión de tu instancia n8n
Antes de aplicar el parche, identifica la versión exacta en ejecución. Tres métodos según tu contexto de despliegue.
A través de la interfaz web: inicia sesión en tu instancia, haz clic en el icono de perfil en la parte inferior izquierda y luego en "About n8n". La versión aparece en la ventana modal.
A través de Docker: el comando docker inspect <nombre-del-contenedor> --format '{{index .Config.Labels "org.opencontainers.image.version"}}' devuelve la versión de la imagen en ejecución. Si el contenedor se inició desde la imagen n8nio/n8n:latest, este valor refleja lo que estaba vigente en el momento del último docker pull.
A través de la API interna: un curl http://localhost:5678/healthz en el host devuelve {"status":"ok"} con la versión en los headers si la instancia está en ejecución.
Si tu versión es inferior a 1.121.3, aplica el procedimiento siguiente sin esperar a la próxima ventana de mantenimiento.
Procedimiento de actualización a n8n ≥ 1.121.3
Copia de seguridad de la base de datos y archivos de configuración
Antes de cualquier actualización, guarda el estado actual. Para una instalación Docker Compose, exporta la base de datos SQLite o PostgreSQL según tu configuración:
# SQLite (ruta por defecto) cp ~/.n8n/database.sqlite ~/.n8n/database.sqlite.bak-$(date +%Y%m%d) # PostgreSQL pg_dump -U n8n -d n8n > n8n-backup-$(date +%Y%m%d).sqlCopia también tu
docker-compose.ymly archivo.enven un directorio de backup.Actualizar el archivo docker-compose.yml
Si usas la imagen
n8nio/n8n:latest, no se requieren cambios en el archivodocker-compose.yml. Si has fijado una versión explícita (por ejemplon8nio/n8n:1.115.0), actualiza la líneaimage:services: n8n: image: n8nio/n8n:1.121.3Si quieres seguir la rama estable de larga duración, usar una etiqueta de versión explícita es preferible a
latestpara controlar las ventanas de actualización.Descargar la nueva imagen
Desde el directorio que contiene tu
docker-compose.yml:docker compose pullEste comando descarga únicamente las capas de la imagen que han cambiado. Con un enlace ascendente de 100 Mbit/s, cuenta con 30 a 90 segundos según tu caché local.
Detener la instancia actual
docker compose downEl cierre es ordenado: n8n espera a que terminen las ejecuciones en curso antes de detenerse, a menos que añadas
--timeout 0. En una instancia con alta carga, es preferible esperar a que los workflows activos terminen antes de ejecutar este comando, o suspender los workflows críticos desde la interfaz.Reiniciar con la nueva imagen
docker compose up -dDocker Compose utiliza la imagen recién descargada. El arranque suele tardar de 10 a 20 segundos. El log de inicio debe mostrar la versión 1.121.3 o superior.
Verificar la versión desplegada
docker compose logs n8n | grep -i 'version\|n8n@'O a través de la API interna, desde el host:
curl -s http://localhost:5678/healthzConfirma que la versión mostrada en la interfaz (icono de perfil → About n8n) sea 1.121.3 o superior antes de considerar la actualización completa.
Deshabilitar el nodo Git si no lo utilizas
Para neutralizar el vector de ataque inmediatamente sin esperar la actualización (por ejemplo si no hay ventana de mantenimiento disponible), deshabilita el nodo Git mediante la variable de entorno:
N8N_NODES_EXCLUDE='["n8n-nodes-base.git"]'Añade esta variable a tu archivo
.envy reinicia la instancia. Esto no es un sustituto de la actualización: aplica el parche tan pronto como sea posible.Para una instalación npm (sin Docker)
npm update -g n8n # O, si usas un gestor de procesos: pm2 stop n8n npm update -g n8n pm2 start n8nVerifica la versión instalada con
n8n --version. Se recomienda migrar a Docker para nuevas instalaciones — la guía dedicadan8n-migration-npm-docker-avant-v3cubre este recorrido en detalle.
Endurecimiento post-parche: reducir la superficie de ataque
La actualización corrige la vulnerabilidad conocida, pero varias configuraciones refuerzan la postura de seguridad general de la instancia.
Restringe los permisos del proceso n8n. El contenedor no debe ejecutarse como root. La imagen oficial utiliza el usuario node por defecto desde varias versiones — verifica que tu docker-compose.yml no contenga user: root.
Activa la autenticación. Si tu instancia está expuesta en internet sin autenticación, añade N8N_BASIC_AUTH_ACTIVE=true con credenciales fuertes, o coloca la instancia detrás de un proxy que requiera autenticación. CVE-2026-21877 es autenticada, pero existen otros vectores no autenticados en el ecosistema.
Limita los nodos permitidos. La variable N8N_NODES_INCLUDE permite autorizar solo un subconjunto de nodos. En instancias dedicadas a workflows sin necesidad de acceso Git o al sistema, una lista de inclusión reduce la superficie.
Audita las cuentas de usuario. En la interfaz de administración, verifica que cada cuenta activa sea legítima y que las cuentas de prueba o de antiguos colaboradores estén desactivadas.
Suscríbete a las alertas de seguridad de n8n. El repositorio de GitHub n8n-io/n8n permite suscribirse a notificaciones de seguridad mediante "Watch → Security alerts".
Bug de scheduling tras la versión 2.21.7: síntoma y workaround
El issue de GitHub #31100 documenta un comportamiento reportado tras actualizar a la versión 2.21.7: los workflows con disparadores programados (nodo Schedule Trigger) dejan de ejecutarse en su hora, sin ningún mensaje de error visible en los logs.
Síntoma exacto: los workflows permanecen en estado «activo» en la interfaz, se muestra el próximo tiempo de disparo programado, pero las ejecuciones no tienen lugar. El historial de ejecuciones no muestra ningún intento fallido — los workflows simplemente no se disparan. Este comportamiento se observa principalmente en despliegues en modo cola (multi-worker), con PostgreSQL, pero también puede afectar a instancias de proceso único.
Lo que el issue indica sobre el workaround: en el momento de publicación de este artículo, el issue está marcado como "Needs Feedback" por el equipo de n8n y no se ha publicado ningún workaround oficial documentado en el hilo. Varios operadores han reportado que los siguientes enfoques restauraron las ejecuciones programadas en su entorno:
- Desactivar y luego reactivar manualmente cada workflow afectado desde la interfaz (alternancia Active/Inactive).
- Reiniciar el contenedor o servicio de n8n, lo que fuerza la reinicialización de la cola de programación interna.
- En despliegues en modo cola: reiniciar primero el nodo principal (main), antes que los workers.
Estas acciones no son un fix: el problema puede reproducirse. Monitoriza el issue #31100 para el estado oficial y la versión de corrección.
Identificación rápida de los workflows afectados: en la interfaz de n8n, filtra el historial de ejecuciones por disparador «Schedule» y comprueba la ausencia de ejecuciones durante el período esperado. Un workflow que debería haberse ejecutado diez veces desde medianoche sin ningún rastro en el log es una señal clara.
Verificaciones post-migración: qué controlar antes de reabrir el tráfico
Una actualización exitosa de n8n se confirma en varios ejes, no solo en la versión mostrada.
Versión: la interfaz «About n8n» muestra 1.121.3 o superior. El comando docker inspect sobre la imagen en ejecución devuelve el mismo número.
Integridad de credenciales: n8n cifra las credenciales con una clave derivada de N8N_ENCRYPTION_KEY. Si esta variable no ha cambiado entre versiones, las credenciales existentes están intactas. Abre un workflow que use una conexión externa y verifica que se ejecuta sin errores de descifrado.
Workflows activos: en el dashboard, verifica que el número de workflows activos coincide con el estado previo a la actualización. Un workflow que estaba activo y ya no lo está tras el reinicio es una señal de alerta.
Ejecuciones programadas: si tu instancia usa nodos Schedule Trigger, espera al próximo tiempo de disparo y confirma la ejecución en el log. Si estás en la versión 2.21.7 de la rama 2.x, consulta la sección anterior sobre el bug de scheduling.
Logs de inicio: docker compose logs n8n --tail 50 debe mostrar un arranque limpio sin excepciones. Los errores de conexión a la base de datos o de descifrado de credenciales aparecen en estas primeras líneas.
Acceso de red: si tu instancia está expuesta a través de un proxy inverso, verifica que las rutas /webhook/ y /webhook-test/ respondan correctamente tras la actualización.
Versiones de n8n: exposición a los CVE de la alerta AL26-001
Desplace la tabla
| Versión | CVE-2025-68613 | CVE-2026-21858 | CVE-2026-21877 | Acción requerida |
|---|---|---|---|---|
| < 1.120.4 | Vulnerable | Vulnerable | Vulnerable | Actualizar a ≥ 1.121.3 |
| 1.120.4 – 1.120.x | Corregida | Vulnerable | Vulnerable | Actualizar a ≥ 1.121.3 |
| 1.121.0 – 1.121.2 | Corregida | Corregida | Vulnerable | Actualizar a ≥ 1.121.3 |
| ≥ 1.121.3 | Corregida | Corregida | Corregida | Sin acción CVE requerida |
| 2.x < 2.21.7 | Ver release notes | Ver release notes | Ver release notes | Consultar release notes 2.x |
| 2.21.7+ | Ver release notes | Ver release notes | Ver release notes | Bug scheduling #31100 activo |
Mantener actualizada tu instancia n8n: la vía con VPS
CVE-2026-21877 ilustra el coste de una instancia autoalojada cuya actualización depende de una ventana de mantenimiento externa. En un VPS con acceso root, docker compose pull && docker compose up -d aplica el parche en menos de diez minutos, sin depender de un proveedor para decidir el momento.
Esta autonomía tiene una contrapartida: la vigilancia de advisories de seguridad recae en el operador. Dos fuentes para seguir n8n: el repositorio de GitHub (pestaña Security, notificaciones activables) y las alertas del Centro Canadiense de Ciberseguridad o su equivalente CERT en tu región.
Para profundizar en la configuración de una instancia n8n sólida — instalación inicial, proxy inverso Caddy o nginx, TLS automático y copias de seguridad — consulta la guía instalar n8n en VPS. Si vienes de una instalación npm y estás considerando la migración a Docker antes de pasar a la rama 2.x, la guía migración de npm a Docker antes de v3 cubre ese recorrido. El patrón de parcheo aplicado aquí es idéntico al documentado para CVE-2026-6471 en PostgreSQL.
