Vulnerabilidades de seguridad de n8n: historial de divulgación y parches
Una revisión de cuánto tarda y qué tan transparente es n8n al divulgar y corregir sus vulnerabilidades de seguridad, según avisos, CERT e investigaciones.
Comprobado con las fuentes citadas el .
Vulnerabilidades de seguridad de n8n: alcance y criterios de revisión
Esta revisión pregunta con qué transparencia y rapidez divulga y corrige n8n sus vulnerabilidades de seguridad, y qué significa ese historial para un responsable técnico que ejecuta n8n en su propia infraestructura. Examinamos solo tres aspectos: la rapidez con la que una falla reportada se convierte en un aviso publicado, el nivel de detalle técnico que cada aviso ofrece a quien debe defenderse, y la claridad de las indicaciones de n8n sobre parches y soluciones provisionales para implementaciones en la nube frente a las autoalojadas. Nos apoyamos en los propios avisos de GitHub y páginas de política de n8n, en alertas de autoridades nacionales de ciberseguridad, y en informes de seguridad independientes del mismo periodo, principalmente de finales de 2025 a principios de 2026.
No pretendemos ofrecer un historial completo de todos los CVE de n8n jamás registrados. La evidencia disponible se concentra en un conjunto de avisos de noviembre de 2025 a febrero de 2026, más un caso anterior de 2023, por lo que esta es una revisión de ejemplos documentados y no una tendencia completa de varios años.
Cómo está estructurado el programa de divulgación de vulnerabilidades de n8n
La política de seguridad de n8n en GitHub indica a cualquiera que encuentre una falla que la reporte a través de un Programa formal de Divulgación de Vulnerabilidades, en lugar de escribir directamente a un responsable del mantenimiento, según la página SECURITY.md de n8n. Esa página es un breve esbozo de política sin historial de versiones, por lo que no es posible determinar desde cuándo existe este canal formal.
El vicepresidente de Ingeniería de n8n abordó directamente este patrón en el propio blog de la empresa, después de que el ritmo creciente de avisos publicados generara preguntas entre los usuarios sobre si el proyecto tenía un problema de seguridad.
La propia página de confianza de n8n describe además un régimen recurrente de pruebas: escaneos de vulnerabilidades por parte de terceros al menos cada 90 días y una prueba de penetración de terceros al menos una vez al año, como parte de su programa de gestión de amenazas y vulnerabilidades. Se trata de una descripción autoinformada por n8n de su propio proceso, no de un informe auditado de forma independiente sobre la frecuencia real con que se realizaron esas pruebas.
Sources: Security Policy · n8n-io/n8n · GitHub, Security
La velocidad de divulgación en la práctica: qué muestran los cronogramas recientes
Puestas una junto a otra, las vulnerabilidades de seguridad recientes de n8n muestran un patrón que vale la pena nombrar directamente: los parches a veces se publicaron de forma discreta, semanas antes de que el aviso público se pusiera al día. Para la falla que afecta a las versiones 1.65 a 1.120.4 de n8n, el propio aviso de n8n del 8 de enero de 2026 indica que la corrección se envió a toda su base de clientes el 18 de noviembre de 2025, pero el aviso en sí no se publicó hasta el 8 de enero de 2026, unas siete semanas después. n8n explica esta brecha como deliberada, al dar a los clientes una ventana para actualizar antes de que los detalles técnicos se hicieran públicos.
Informes independientes añaden un segundo relato de una brecha similar. El informe de CyberScoop del 7 de enero de 2026 indica que la firma de seguridad Cyera encontró y reportó el mismo CVE-2026-21858 a n8n el 9 de noviembre de 2025, que n8n lo corrigió el 18 de noviembre, pero que el CVE no se asignó ni divulgó públicamente hasta el 7 de enero de 2026, unos dos meses después del informe inicial. n8n no respondió a la solicitud de comentarios de CyberScoop, por lo que en ese medio solo queda registrada la versión de Cyera sobre esa brecha en particular.
Creemos que un retraso de tipo embargo entre la corrección y la publicación puede ser una compensación de seguridad defendible, ya que impide que los atacantes hagan ingeniería inversa de una corrección antes de que los clientes la apliquen. Pero solo funciona si cada equipo afectado realmente está ejecutando versiones recientes durante esa ventana silenciosa, lo cual es una suposición importante para n8n autoalojado.
Para cuando el Centro Cibernético de Canadá emitió su alerta del 12 de enero de 2026, señaló que ya circulaban públicamente exploits de prueba de concepto que encadenaban el CVE-2026-21858 con una vulnerabilidad anterior de 2025, y por separado advirtió que la línea de versiones 1.X de n8n llega al final de su vida útil a principios de marzo de 2026.
Sources: Security Advisory: Security Vulnerability in n8n Versions 1.65-1.120.4 – n8n Blog, Researchers rush to warn defenders of max-severity defect in n8n | CyberScoop, AL26-001 – Vulnerabilities affecting n8n – CVE-2026-21858, CVE-2026-21877 and CVE-2025-68613 - Canadian Centre for Cyber Security
Qué tan detallados son los avisos de CVE y las indicaciones de parches de n8n
Una vez publicados, los avisos de seguridad de n8n en GitHub tienden a ser técnicamente sustanciales. El aviso del CVE-2025-68613 (GHSA-v98v-ff95-f3cp, publicado el 19 de diciembre de 2025) detalla el rango de versiones afectadas, la versión corregida —n8n v1.122.0—, un vector CVSS, una clasificación CWE y el crédito a quien lo reportó.
- Rangos de versiones afectadas y corregidas
- Puntuación y vector CVSS
- Clasificación de debilidad CWE
- Crédito a quien reportó o a la firma de investigación
- Indicaciones de solución provisional cuando existe una
Las soluciones provisionales varían en solidez. El aviso de la vulnerabilidad del nodo Python Code relacionada con Pyodide (GHSA-62r4-hw23-cc8v, CVE-2025-68668, publicado el 24 de diciembre de 2025) ofrece tres opciones concretas de mitigación, incluida la configuración de la variable de entorno N8N_PYTHON_ENABLED=false para deshabilitar por completo la función afectada. En cambio, el aviso de la falla de ejecución remota de código por escape de expresiones (GHSA-6cqr-8cfr-67f8, CVE-2026-25049, publicado el 4 de febrero de 2026) afirma claramente que las soluciones provisionales que enumera no remedian por completo el riesgo y solo deben usarse como medida temporal.
Ese mismo aviso de febrero de 2026 también señala que n8n ha adoptado CVSS 4.0 como su estándar principal de puntuación a partir de ahora, aunque sigue publicando puntuaciones CVSS 3.1 para mantener la compatibilidad con versiones anteriores —un detalle de metodología más que una señal de velocidad, pero que ayuda a quienes se defienden a comparar la gravedad de forma coherente.
Sources: n8n Remote Code Execution via Expression Injection · Advisory · n8n-io/n8n · GitHub, Arbitrary Command Execution in Pyodide based Python Code Node · Advisory · n8n-io/n8n · GitHub, Expression Escape Vulnerability Leading to RCE · Advisory · n8n-io/n8n · GitHub
Validación externa: alertas CERT e investigación de seguridad independiente
Los propios avisos de n8n no son el único relato. La autoridad nacional de ciberseguridad de Bélgica, el CCB, documentó tanto el CVE-2026-21858 como el CVE-2026-21877 con la puntuación CVSS máxima de 10.0 en su aviso público, actualizado por última vez el 9 de enero de 2026. Ese aviso reproduce los datos de versión y mitigación que la propia n8n proporcionó, por lo que funciona como canal de distribución más que como auditoría técnica independiente.
| Fuente | Tipo de relato | Qué aporta |
|---|---|---|
| Aviso propio de n8n (8 de enero de 2026) | Proveedor, oficial | Confirma la fecha del parche y explica la razón de n8n para el retraso en la publicación |
| CyberScoop, citando a Cyera (7 de enero de 2026) | Informe de seguridad independiente | Aporta las fechas de Cyera sobre cuándo reportó por primera vez la falla a n8n |
| CCB de Bélgica (9 de enero de 2026) | Alerta de CERT nacional | Confirma las puntuaciones máximas de gravedad de ambos CVE críticos |
| Centro Cibernético de Canadá (12 de enero de 2026) | Alerta de CERT nacional | Confirma las puntuaciones de gravedad y señala que ya circulan exploits de prueba de concepto públicos |
| Rapid7 (8 de enero de 2026, actualizado el 1 de julio de 2026) | Investigación de proveedor de seguridad | Consolida cinco CVE con fechas de publicación y puntuaciones CVSS/NVD en una sola tabla |
La investigación de amenazas de Rapid7, publicada por primera vez el 8 de enero de 2026 y actualizada el 1 de julio de 2026, consolida cinco CVE que afectan a n8n divulgados entre el 19 de diciembre de 2025 y el 7 de enero de 2026 en una sola tabla de fechas de publicación y puntuaciones. Rapid7 vende productos de gestión de vulnerabilidades, por lo que su interés en destacar la exposición de n8n también es de carácter comercial.
Consideraríamos que contrastar las publicaciones de n8n con estas alertas CERT e informes independientes es una práctica estándar y no un extra opcional, porque las brechas entre el enfoque del proveedor y los informes externos son precisamente donde se esconde la verdadera ventana de exposición de un equipo autoalojado.
Este patrón de divulgaciones activas y graves no es exclusivo de finales de 2025. Una falla de escalada de privilegios de 2023, el CVE-2023-27563, que afecta a versiones de n8n anteriores a la 0.216.1, se documentó en la base de datos de avisos de GitHub el 10 de mayo de 2023, citando la investigación original de la firma de seguridad Synacktiv, aunque esa entrada no detalla el cronograma interno de divulgación de n8n para este caso.
Sources: Warning: Two critical vulnerabilities in n8n can lead to remote code execution, Patch Immediately! | CCB Belgium, AL26-001 – Vulnerabilities affecting n8n – CVE-2026-21858, CVE-2026-21877 and CVE-2025-68613 - Canadian Centre for Cyber Security, Ni8mare and N8scape flaws among multiple critical vulnerabilities affecting n8n, n8n Privilege Escalation vulnerability · CVE-2023-27563 · GitHub Advisory Database · GitHub
Qué significa este historial para el riesgo de un equipo autoalojado
En conjunto, el historial muestra a un proveedor que divulga, pero que a veces divulga tarde. Los avisos de n8n son técnicamente detallados una vez publicados, y n8n ejecuta su propio régimen recurrente de pruebas, pero la brecha entre un parche silencioso y un informe público ha llegado a durar unas siete semanas en al menos un caso bien documentado.
Nuestra lectura pragmática es que la brecha entre un parche silencioso y un aviso público es el verdadero riesgo operativo para los equipos autoalojados, más que el número bruto de vulnerabilidades de seguridad de n8n divulgadas en un trimestre dado. Un equipo que solo reacciona a los correos de aviso puede permanecer sin parchear durante semanas sin saberlo.
La alerta del Centro Cibernético de Canadá también señaló que la línea de versiones 1.X de n8n llega al final de su vida útil a principios de marzo de 2026, algo relevante para cualquier equipo autoalojado que aún esté planificando su ruta de actualización en lugar de tratar las actualizaciones de versión como opcionales.
Sources: Security Advisory: Security Vulnerability in n8n Versions 1.65-1.120.4 – n8n Blog, Security, AL26-001 – Vulnerabilities affecting n8n – CVE-2026-21858, CVE-2026-21877 and CVE-2025-68613 - Canadian Centre for Cyber Security
Recomendaciones prácticas para equipos autoalojados
Nada de esto cambia la tarea básica de un equipo autoalojado: mantenerse cerca de las versiones actuales y construir un proceso que no dependa de leer cada entrada de blog el día que se publica.
Un responsable técnico que quiera una respuesta clara sobre si una instancia está realmente parcheada y reforzada tal como suponen estos avisos, por lo general necesita que alguien revise la configuración en vivo, no solo la página de política.
Sources: Security Advisory: Security Vulnerability in n8n Versions 1.65-1.120.4 – n8n Blog, Researchers rush to warn defenders of max-severity defect in n8n | CyberScoop, n8n Remote Code Execution via Expression Injection · Advisory · n8n-io/n8n · GitHub, Arbitrary Command Execution in Pyodide based Python Code Node · Advisory · n8n-io/n8n · GitHub, Warning: Two critical vulnerabilities in n8n can lead to remote code execution, Patch Immediately! | CCB Belgium, AL26-001 – Vulnerabilities affecting n8n – CVE-2026-21858, CVE-2026-21877 and CVE-2025-68613 - Canadian Centre for Cyber Security, Ni8mare and N8scape flaws among multiple critical vulnerabilities affecting n8n
