Alerta de seguridad en n8n CVE-2026-25049 permite ejecución remota de comandos y escapa de la sandbox

La comunidad de seguridad ha detectado un fallo grave en n8n, la plataforma de automatización de flujos de trabajo, que permite la ejecución remota de comandos en el servidor donde corre la aplicación si se explota con éxito. El problema, registrado como CVE-2026-25049 y con una puntuación alta en el sistema CVSS (9.4), es una evasión de controles de saneamiento en la evaluación de expresiones que revierte parcialmente una corrección aplicada el año pasado para la vulnerabilidad CVE-2025-68613 (CVSS 9.9).

Los mantenedores de n8n publicaron un aviso en GitHub donde detallan que un usuario autenticado con permisos para crear o editar flujos puede inyectar expresiones especialmente construidas en parámetros del flujo que terminan escapando del mecanismo de sandbox y provocando la ejecución de comandos del sistema anfitrión. Puede leerse la explicación oficial y las versiones corregidas en el aviso de seguridad de n8n en GitHub.

Desde el punto de vista técnico, la raíz del problema está en la diferencia entre las comprobaciones que hace TypeScript en tiempo de compilación y lo que ocurre en tiempo de ejecución con JavaScript. Como han explicado varios equipos de investigación, entre ellos Endor Labs, TypeScript puede ayudar a identificar que cierta propiedad debería ser una cadena en el código fuente, pero esas garantías desaparecen al ejecutarse valores que un atacante introduce dinámicamente. Aprovechando esto, se pueden pasar valores no esperados (objetos, arrays, símbolos, etc.) que burlan las funciones de saneamiento y permiten salir de la caja de protección.

Investigadores independientes han publicado análisis técnicos que ilustran cómo se consigue la evasión y cómo se encadenan los pasos para lograr la ejecución remota. El trabajo de divulgación incluye un desglose minucioso de las técnicas empleadas y ejemplos prácticos; uno de esos análisis detallados puede consultarse en la investigación de Fatih Çelik sobre la secuencia de fallos y bypasses: n8n RCEs: A Tale of 4 Acts.

El riesgo se agrava cuando se combina con la funcionalidad de webhooks de n8n. Si un atacante crea un flujo con un webhook público y sin autenticación, puede insertar la carga que provoca ejecución de comandos y, una vez activado el flujo, cualquiera que conozca el endpoint puede dispararlo y ejecutar código en el servidor. Equipos como SecureLayer7 y Pillar Security han detallado escenarios de impacto que incluyen robo de claves API, acceso a secretos de nube, movimiento lateral hacia cuentas conectadas y toma de control de workflows ligados a servicios de inteligencia artificial.

n8n ha liberado correcciones en las ramas afectadas; las versiones que contienen los parches son 1.123.17 para la serie 1.x y 2.5.2 para la serie 2.x. Actualizar a una versión parcheada debe ser la prioridad número uno para cualquier despliegue vulnerable. Si no es posible aplicar la actualización de inmediato, conviene tomar medidas compensatorias para reducir la exposición: limitar quién puede crear y editar flujos a un grupo reducido de usuarios de confianza, deshabilitar o proteger los webhooks públicos, y ejecutar n8n en entornos con privilegios del sistema y reglas de red restringidas para minimizar el daño en caso de una intrusión.

También es importante auditar los flujos existentes y los registros de actividad para detectar cambios sospechosos o endpoints públicos recién creados. En sistemas que puedan haber sido comprometidos, las credenciales y claves que hayan estado disponibles en el entorno afectado deben rotarse y los accesos revisados. Las empresas que dependan de integraciones y automatizaciones críticas deberían priorizar esta revisión y la campaña de parcheo.

La cadena de descubrimiento de esta vulnerabilidad incluyó contribuciones de varios equipos y analistas de seguridad, entre ellos Fatih Çelik, Cris Staicu de Endor Labs, Eilon Cohen de Pillar Security y Sandeep Kamble de SecureLayer7; los mantenedores de n8n los han reconocido públicamente por sus informes.

Este episodio subraya una lección clásica pero frecuentemente ignorada: las comprobaciones estáticas del tipo no sustituyen a validaciones robustas en tiempo de ejecución cuando se manejan entradas no confiables. Organizaciones como OWASP llevan años insistiendo en la necesidad de múltiples capas de defensa y en la validación estricta de entradas; la documentación general sobre riesgos de validación y control de entrada puede consultarse en recursos como OWASP. Para comprender mejor por qué TypeScript no evita este tipo de exploits, la guía del propio proyecto TypeScript ofrece contexto sobre cómo su sistema de tipos actúa en tiempo de compilación pero no persiste en el bundle final: documentación de TypeScript.

En resumen, si utilizas n8n en producción: primero, actualiza cuanto antes a las versiones parcheadas. Después, revisa permisos y exposición de webhooks, endurece el entorno de ejecución y realiza una auditoría de posibles indicadores de compromiso. Si necesitas más información técnica, los análisis de los investigadores y el aviso de n8n son recursos públicos útiles para entender el alcance y los vectores de explotación: el aviso de GitHub, el deep-dive de Fatih Çelik, y los informes de Endor Labs, SecureLayer7 y Pillar Security.