CVE-2026-25049 en n8n: vulnerabilidad crítica en la sandbox de JavaScript expone a ejecución remota de código

CyberSecureFox 🦊

La popular plataforma de automatización de flujos de trabajo n8n se ha visto afectada por una vulnerabilidad crítica, identificada como CVE-2026-25049, con una puntuación de 9,4 en la escala CVSS. El fallo en el mecanismo de aislamiento del código JavaScript permitía que usuarios autenticados ejecutaran comandos arbitrarios en el servidor, con potencial para tomar el control completo del instance de n8n.

CVE-2026-25049: fallo en la sandbox de JavaScript y evasión de parches previos

El problema reside en el componente de sandbox de JavaScript, encargado de ejecutar de forma segura las expresiones personalizadas que los usuarios incorporan a sus flujos de trabajo. n8n utilizaba un enfoque basado en análisis de árbol de sintaxis abstracta (AST) para detectar y bloquear construcciones peligrosas antes de la ejecución.

Investigadores de Pillar Security, Endor Labs y SecureLayer7 demostraron que la implementación de este análisis era incompleta. Aprovechando huecos en la lógica de filtrado, fue posible escapar de la sandbox, acceder al objeto global de Node.js y, desde ahí, invocar funciones del sistema operativo.

Un aspecto relevante es que CVE-2026-25049 habría permitido eludir el parche diseñado para corregir una vulnerabilidad anterior, CVE-2025-68613 (puntuación 9,9 CVSS), cerrada en diciembre de 2025. Es decir, incluso con el parche previo aplicado, existía un vector alternativo para lograr ejecución remota de código.

Quién está en riesgo: escenarios de ataque sobre n8n y su infraestructura

Para explotar la vulnerabilidad, el atacante necesitaba únicamente una cuenta con permisos para crear o editar flujos de trabajo. Según Pillar Security, este nivel de acceso bastaba para comprometer el servidor: “si puedes crear flujos de trabajo, puedes tomar el control del servidor”.

Entre los principales escenarios de impacto destacan:

1. Ejecución remota de código (RCE) y toma de control del servidor. El atacante puede lanzar comandos del sistema operativo, desplegar backdoors, instalar herramientas adicionales y utilizar el servidor n8n como trampolín hacia el resto de la red.

2. Robo de datos sensibles y secretos de integración. Quedan expuestos API keys, tokens OAuth, credenciales de bases de datos y accesos a servicios externos configurados en n8n. Esto abre la puerta a comprometer CRM, almacenes de datos y plataformas cloud conectadas.

3. Acceso a la red interna y a la filesystem. Desde el servidor comprometido es posible leer y, en algunos casos, modificar archivos, así como interactuar con servicios internos y recursos que no son accesibles desde Internet.

4. Manipulación de flujos de trabajo de IA. Dado el uso creciente de n8n para orquestar workflows de inteligencia artificial, un atacante podría interceptar prompts, alterar respuestas de modelos, modificar silenciosamente la lógica de las cadenas o redirigir tráfico hacia servicios bajo su control.

El riesgo se amplifica en despliegues multi-tenant. Un compromiso exitoso en un tenant podría ser aprovechado para intentar moverse lateralmente y acceder a datos de otros clientes dentro del mismo clúster.

Cronología, investigación y detalles técnicos de la explotación

De acuerdo con Pillar Security, los desarrolladores de n8n fueron notificados el 21 de diciembre de 2025. Los investigadores demostraron un escape práctico de la sandbox con acceso al objeto global de Node.js, lo que conduce de forma directa a RCE.

Un primer parche se liberó dos días después, pero posteriores auditorías evidenciaron que no cubría todos los vectores posibles. Mediante operaciones y construcciones equivalentes, todavía era factible evadir el análisis AST.

La vulnerabilidad quedó completamente corregida en la versión n8n 2.4.0, publicada el 12 de enero de 2026. Expertos de Endor Labs desarrollaron un proof of concept sencillo que ilustra la explotación de CVE-2026-25049.

SecureLayer7 hizo públicos detalles técnicos adicionales: lograron ejecutar JavaScript del lado servidor utilizando el constructor Function, que teóricamente debía bloquearse dentro de la sandbox. Según su reporte, se requirieron más de 150 iteraciones de prueba y error para encontrar una combinación de construcciones que eludiera los filtros.

Actualizaciones de seguridad en n8n y medidas de mitigación recomendadas

El equipo de n8n insta a los administradores a actualizar lo antes posible a las versiones estables 1.123.17 y 2.5.2, que incorporan un mecanismo de sandbox reforzado y corrigen el conjunto de vulnerabilidades relacionadas, incluida CVE-2026-25049.

Buenas prácticas inmediatas para reducir el riesgo en n8n

Además del parcheo, se recomiendan las siguientes acciones de respuesta y endurecimiento:

1. Rotar la clave de cifrado. Generar un nuevo valor para N8N_ENCRYPTION_KEY, encargado de proteger los secretos almacenados.

2. Regenerar todas las credenciales. Contraseñas, tokens, API keys y credenciales OAuth configuradas en n8n deberían ser renovadas, incluso si no se observan indicios claros de incidente.

3. Auditar flujos de trabajo y código JavaScript. Revisar los workflows existentes en busca de expresiones sospechosas, especialmente aquellas que interactúan con la filesystem, comandos del sistema o endpoints poco habituales.

En entornos donde la actualización inmediata no sea viable, es aconsejable restringir severamente los permisos de creación y edición de flujos a un grupo muy reducido de usuarios de máxima confianza y ejecutar n8n en un entorno lo más aislado posible, con privilegios mínimos, segmentación de red y filtros estrictos hacia servicios internos.

Otras vulnerabilidades críticas corregidas en n8n

Junto con CVE-2026-25049, se han solucionado otras cuatro vulnerabilidades, dos de ellas también con puntuación 9,4 CVSS:

CVE-2026-25053: inyección de comandos en el nodo Git, que permite ejecutar órdenes arbitrarias al interactuar con repositorios;
CVE-2026-25056: escritura de archivos arbitrarios mediante SQL Query en el nodo Merge, con capacidad para alterar el contenido del sistema de archivos.

Además, se han corregido problemas adicionales de seguridad:

CVE-2026-25054: vulnerabilidad de cross-site scripting (XSS) almacenada en el componente de renderizado de Markdown, con impacto sobre los usuarios de la interfaz;
CVE-2026-25055: path traversal en el nodo SSH durante el manejo de archivos cargados, que podía permitir acceso a rutas no previstas.

Este incidente pone de relieve la importancia de diseñar y revisar de forma continua los mecanismos de sandboxing e aislamiento de código en plataformas de automatización como n8n. Para reducir el impacto de vulnerabilidades inevitables en ecosistemas complejos, las organizaciones deberían combinar actualizaciones rápidas con una política de mínimo privilegio para quienes diseñan flujos de trabajo, una fuerte segmentación de red, monitorización de actividad anómala y rotación periódica de secretos. Adoptar estas prácticas como estándar eleva de forma significativa la resiliencia frente a futuros fallos de seguridad.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.