Alerta de seguridad: CVE-2026-25049 en n8n permite escapar del sandbox y tomar control del servidor

Si gestionas automatizaciones con n8n —la plataforma de código abierto que permite encadenar aplicaciones y procesos mediante workflows— conviene que prestes atención: varias investigaciones recientes han descubierto fallos graves en el aislado que ejecuta código del lado del servidor, lo que ha permitido a atacantes autenticados escapar del sandbox y ejecutar comandos arbitrarios en el host.

La debilidad, registrada colectivamente como CVE‑2026‑25049, afecta a la forma en que n8n sanitiza y evalúa fragmentos de JavaScript que pueden incluir los usuarios dentro de los workflows. Equipos de investigación independientes —entre ellos Pillar Security, Endor Labs y SecureLayer7— han mostrado cómo, con permisos para crear o modificar workflows, un atacante puede aprovechar estas fallas para tomar control total del servidor donde corre n8n.

Para entender por qué esto es serio basta pensar en lo que n8n almacena y con qué suele conectarse: credenciales de API, tokens OAuth, claves y flujos que interactúan con servicios en la nube o con modelos de IA. Según las descripciones técnicas, el exploit permite desde ejecutar instrucciones en la máquina víctima hasta leer archivos sensibles, extraer credenciales y pivotar hacia cuentas y recursos conectados, incluso secuestrar flujos de IA interceptando o alterando prompts y respuestas.

En el corazón del problema está la estrategia de "sandboxing" basada en el análisis de la sintaxis del código (AST). Los investigadores explican que las comprobaciones asumían ciertas restricciones tipadas (reflejadas en los tipos de TypeScript), pero esas garantías no se aplicaban en tiempo de ejecución, lo que derivó en una condición de confusión de tipos que permite eludir la limpieza del código. En términos prácticos, esto abre la puerta a construir expresiones que, al evaluarse en el servidor, recuperan objetos globales de Node.js o usan el constructor Function para ejecutar código arbitrario.

El fallo no apareció de la nada: el equipo de investigación de Pillar Security reportó una cadena de evasión el 21 de diciembre de 2025 y n8n implementó una corrección inicial poco después, pero los investigadores demostraron que aquella solución no cerró todos los vectores. Tras análisis adicionales se encontraron bypasses alternativos y los desarrolladores de n8n confirmaron nuevas evasiones antes de publicar parches posteriores. Los análisis y pruebas de concepto completos están accesibles en los informes técnicos de Pillar Security, Endor Labs y SecureLayer7.

n8n ha ido publicando parches y mitigaciones; es clave revisar la advisoria anterior relacionada y la nota de seguridad con la mitigación temporal para confirmar qué versiones contienen las correcciones definitivas. Asimismo, los equipos que no puedan actualizar de inmediato deberían aplicar las medidas provisionales que sugiere el proyecto y restringir quién puede crear o editar workflows dentro de la instalación.

La amenaza es mayor en despliegues multi‑tenant: si un atacante logra acceder a servicios internos del clúster, podría potencialmente escalar y acceder a datos de otros inquilinos. Además, la atención que ha despertado n8n en la comunidad maliciosa ya se refleja en escaneos masivos y sondeos dirigidos a instancias expuestas; por ejemplo, GreyNoise ha documentado actividad de sondeo contra endpoints vulnerables en campañas recientes, lo que muestra interés por puntos de entrada que faciliten un control posterior de los sistemas comprometidos (informe de GreyNoise).

Si administras n8n, la prioridad inmediata es verificar si tu instalación está en una versión parcheada y, si no es así, actualizar cuanto antes. Los equipos de seguridad y operaciones deberían además rotar la clave de cifrado de n8n y todas las credenciales almacenadas en la plataforma, revisar workflows en busca de expresiones sospechosas y limitar la capacidad de creación/edición de workflows a usuarios plenamente de confianza. En el repositorio de seguridad de n8n encontrarás instrucciones sobre las mitigaciones temporales para quienes no puedan aplicar el parche de inmediato: mitigación temporal en GitHub.

Desde el punto de vista técnico, la lección es clara: permitir que usuarios definan fragmentos de código ejecutable en el servidor siempre exige un sandbox rígido y comprobaciones en tiempo de ejecución, no solo en los tipos o en la superficie del código. Los errores sutiles en la lógica de sanitización, especialmente en entornos que usan tipado estático como ayuda para el desarrollador, pueden ser aprovechados si la implementación del runtime no impone las mismas garantías.

Por ahora no hay informes públicos confirmados de ataques en producción explotando esta vulnerabilidad concreta, pero la visibilidad del problema y las pruebas de concepto publicadas por investigadores aumentan el riesgo. Mantener actualizadas las plataformas, endurecer permisos y rotar secretos son medidas que reducen exposición y tiempo de respuesta ante posibles incidentes.

Si necesitas consultar las investigaciones originales, los informes técnicos y pruebas de concepto están disponibles en las publicaciones de Pillar Security, Endor Labs y SecureLayer7, y la información oficial y mitigaciones las publica n8n en su repositorio de GitHub (advisories de n8n).

Conclusión: si tu organización depende de n8n, actúa ahora: confirma la versión, aplica parches, rota claves y reduzca quién puede editar workflows. La combinación de ejecución de código en el servidor y una sanitización deficiente convierte un permiso aparentemente benigno —crear o editar un workflow— en una puerta directa al sistema.