Vulnerabilidad crítica en n8n permite RCE sin autenticación y tomar control del servidor
La Vulnerabilidad crítica en n8n identificada como CVE-2026-21858 expone a instancias del popular motor de automatización a Remote Code Execution (RCE) sin autenticación, con una puntuación CVSS 10.0. El hallazgo, atribuido a investigadores de Cyera, implica que cualquier actor con acceso de red a un servidor vulnerable puede ejecutar código arbitrario y tomar control completo del entorno, un escenario especialmente grave por el rol de n8n como “hub” de credenciales, tokens y conexiones a servicios empresariales.
Según el informe técnico de Cyera, el fallo (apodado “ni8mare”) afecta a la forma en la que n8n procesa webhooks, un componente central que dispara workflows cuando llegan eventos desde sistemas externos. Mediante un problema de Content-Type Confusion, un atacante puede manipular cabeceras HTTP para sobrescribir variables internas, lo que habilita la lectura de archivos arbitrarios y, posteriormente, la escalada a ejecución remota de código.
Impacto: por qué la Vulnerabilidad crítica en n8n es especialmente peligrosa
El riesgo no se limita a la caída de un servicio: n8n suele concentrar secretos de alto valor (API keys, OAuth tokens, credenciales de bases de datos y accesos a almacenamiento cloud) para orquestar procesos entre aplicaciones. En términos operativos, una intrusión por esta Vulnerabilidad crítica en n8n puede convertirse en un punto de pivote hacia sistemas conectados, ampliando el impacto más allá del servidor comprometido.
En entornos self-hosted, donde las instancias quedan expuestas por configuración o por accesos internos amplios, el vector “sin login” reduce drásticamente la fricción para explotación: basta con que el atacante alcance el endpoint vulnerable en la red. Esto incrementa el atractivo para campañas oportunistas que buscan compromisos rápidos con alto retorno.
Versiones afectadas y actualización
Cyera indica que no existe un workaround práctico: la mitigación pasa por actualizar. La corrección se distribuyó en la versión n8n 1.121.0 (o superior). La recomendación inmediata para organizaciones con despliegues en producción es verificar inventario de versiones y priorizar el despliegue del update, especialmente si la instancia es accesible desde Internet o desde segmentos internos amplios.
Línea temporal de divulgación
De acuerdo con Cyera, la vulnerabilidad fue reportada de forma privada el 9 de noviembre de 2025, confirmada por el equipo de seguridad al día siguiente y corregida el 18 de noviembre en la release 1.121.0. La asignación pública del identificador CVE se produjo posteriormente, lo que puede haber contribuido a que algunas organizaciones mantengan versiones sin parchear en producción.
Qué debes revisar si operas n8n en producción
Más allá del parche, el incidente vuelve a poner el foco en la superficie de ataque de plataformas de automatización: webhooks expuestos, segmentación de red insuficiente y acumulación de secretos en un único servicio. A nivel de riesgo, la Vulnerabilidad crítica en n8n subraya que estos servidores deben tratarse como infraestructura sensible, al mismo nivel que un sistema de IAM o un CI/CD controller.
Para información de referencia y seguimiento, pueden consultarse fuentes de alta autoridad: el análisis de Cyera sobre CVE-2026-21858 en Cyera Research Labs y el registro oficial del identificador en MITRE CVE.
En un contexto donde las automatizaciones conectan almacenamiento cloud, CRM, bases de datos y servicios de IA, la Vulnerabilidad crítica en n8n se convierte en una alerta de máxima prioridad: un solo servidor expuesto puede concentrar el acceso a una parte sustancial del stack operativo de una organización.
