Investigadores de seguridad revelan un fallo crítico (CVSS 9.4) en n8n que permite escapar del sandbox de JavaScript. La vulnerabilidad es, irónicamente, un intento fallido de arreglar un problema reportado en diciembre.
Si utilizas n8n para automatizar tus flujos de trabajo, parece que no hay descanso. Apenas un mes después de reportar vulnerabilidades críticas como “Ni8mare”, hoy 5 de febrero de 2026, sobre un nuevo agujero de seguridad masiva: CVE-2026-25049 .
Este fallo no es una nueva vulnerabilidad per se, sino un “Bypass” del parche anterior. En diciembre de 2025, n8n intentó corregir el CVE-2025-68613 (otro fallo crítico de 9,9 puntos). Sin embargo, la solución fue incompleta, y los investigadores han encontrado una forma de volver a saltarse las restricciones de seguridad.
El mecanismo: TypeScript vs. Runtime
El núcleo del problema es fascinante para los desarrolladores. Según explican los investigadores, el fallo surge de confiar demasiado en TypeScript.
- La Teoría: TypeScript verifica el código durante la compilación (“Compile-Time”), asegurándose de que las variables sean del tipo correcto (por ejemplo, que una entrada sea siempre texto).
- La Realidad: En tiempo de ejecución (“Runtime”), JavaScript es mucho más permisivo. Un atacante puede enviar objetos, matrices o símbolos maliciosos en lugar de texto. Como el sistema de sanitización de n8n asumía que TypeScript ya había hecho su trabajo, no validaba estos objetos extraños en tiempo real.
- El Resultado: Un usuario autenticado puede inyectar una sola línea de JavaScript malicioso (usando sintaxis de desestructuración) en los parámetros de un flujo de trabajo. Esto rompe el sandbox de expresiones de n8n y permite ejecutar comandos del sistema operativo en el servidor host.
El Peligro de los Webhooks Públicos
Lo que eleva la gravedad de este fallo es su combinación con la función de Webhooks.
- Un atacante (o un empleado con acceso básico) crea un flujo de trabajo malicioso.
- Le añade un Webhook público sin autenticación.
- Inyecta la carga útil de ejecución de código.
- Impacto: Ahora, cualquiera en internet que visite la URL del webhook puede disparar la ejecución de comandos en el servidor, tomando el control total de la máquina, robando claves API, contraseñas de bases de datos y tokens OAuth.
Versiones afectadas
El fallo afecta a las versiones recientes que se creían seguras:
- Versiones 1.x: Versiones anteriores afectadas a 1.123.17.
- Versiones 2.x: Versiones anteriores afectadas a 2.5.2.
¿Qué hacer ahora?
- Actualizar ya: Migra inmediatamente a las versiones 1.123.17 o 2.5.2 (o superiores), donde se han implementado controles en tiempo de ejecución más estrictos.
- Restringir permisos: Si no puedes actualizar hoy, asegúrate de que solo los usuarios de absoluta confianza tengan permisos para crear o editar flujos de trabajo.
- Aislar el Servidor: Ejecuta n8n en un entorno endurecido (hardened), preferiblemente en un contenedor con privilegios mínimos y sin acceso directo a redes internas sensibles, asumiendo que el sandbox de aplicación podría fallar de nuevo.
