Introducción
La inclusión de CVE-2025-68613 en el catálogo KEV de CISA confirma que la falla de ejecución remota en n8n ya no es un riesgo teórico. Para equipos de plataforma y operaciones, el foco pasa de “actualizar cuando se pueda” a “reducir exposición hoy”, con controles sobre permisos, aislamiento y monitoreo de workflows.
n8n se volvió una pieza habitual en stacks de automatización: orquesta integraciones, mueve datos entre SaaS internos y externos, y en muchos casos opera con credenciales sensibles. Por eso, cuando una vulnerabilidad de ejecución remota pasa a estar asociada con explotación activa, su impacto excede al producto puntual: afecta el plano operativo de todo el entorno conectado.
Eso es exactamente lo que ocurre con CVE-2025-68613. La vulnerabilidad fue documentada por el ecosistema de advisories técnicos y luego incorporada al Known Exploited Vulnerabilities Catalog (KEV) de CISA, lo que cambia la prioridad para equipos de seguridad, SRE y DevOps.
Qué ocurrió
Según NVD y GitHub Advisory Database, CVE-2025-68613 afecta el sistema de evaluación de expresiones de workflows en n8n. Bajo ciertas condiciones, expresiones definidas por usuarios autenticados pueden evaluarse en un contexto insuficientemente aislado del runtime subyacente, habilitando ejecución de código arbitrario con privilegios del proceso n8n.
El alcance reportado incluye compromiso completo de la instancia: lectura y modificación de datos, alteración de workflows y operaciones de sistema. Los parches fueron publicados para ramas específicas y la recomendación explícita es migrar a versiones corregidas (incluyendo 1.122.0 o superiores en la línea principal).
El punto de inflexión llegó con la entrada en KEV. En la práctica, esto indica evidencia de explotación en entornos reales y eleva el riesgo para organizaciones con instancias expuestas o con segmentación débil.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de plataforma, el problema no es solo “un CVE más”. n8n suele tener conectores a APIs internas, sistemas de ticketing, secretos, webhooks y bases de datos. Un atacante que logra ejecutar comandos dentro del contexto de n8n puede pivotear hacia activos de mayor valor.
En términos operativos, hay cuatro efectos inmediatos:
- Riesgo de movimiento lateral: desde un nodo de automatización hacia servicios internos.
- Exfiltración de secretos: variables de entorno, tokens y claves de integración.
- Manipulación de pipelines operativos: workflows alterados para persistencia o sabotaje.
- Aumento de superficie de ataque en cloud híbrida: n8n suele estar conectado a múltiples dominios de confianza.
Además, reportes de threat research (Akamai SIRT) describen intentos de explotación asociados a campañas automatizadas, lo que reduce el tiempo entre divulgación y explotación masiva.
Detalles técnicos
El núcleo de la falla está en la evaluación dinámica de expresiones sin aislamiento suficientemente estricto. Este patrón es sensible en herramientas de automatización porque combina tres factores peligrosos: entrada parcialmente controlada por usuario, motor de ejecución flexible y acceso directo a recursos operativos.
Los advisories públicos describen que un usuario autenticado, incluso sin privilegios administrativos elevados, puede construir condiciones para ejecutar código en servidor. Esto abre puertas a:
- lectura/escritura de archivos locales del host o contenedor,
- recolección de secretos y credenciales de integración,
- instalación de persistencia en el runtime,
- uso de la instancia como punto intermedio para ataques internos.
El parche introduce controles adicionales en la evaluación de expresiones y endurece el límite entre lógica de workflow y runtime. Aun así, parchear no elimina por sí solo el riesgo histórico: conviene revisar auditoría de ejecuciones recientes y cambios en workflows desde la ventana de exposición.
Qué deberían hacer los administradores o equipos técnicos
- Actualizar de forma prioritaria a versiones corregidas de n8n en todos los entornos, incluidos staging y nodos secundarios.
- Reducir permisos de edición/creación de workflows a usuarios estrictamente confiables mientras se completa el rollout.
- Aislar runtime: ejecutar n8n con privilegios mínimos, red restringida y separación fuerte respecto de sistemas críticos.
- Rotar secretos potencialmente expuestos (API keys, tokens OAuth, credenciales de DB, webhooks firmados).
- Correlacionar logs de ejecución de workflows con eventos de sistema para detectar comandos anómalos y cambios inesperados.
- Agregar detecciones para picos de llamadas a endpoints de ejecución y creación de workflows fuera de ventanas normales.
- Validar hardening de supply chain: imágenes firmadas, escaneo de dependencias y despliegues reproducibles.
Conclusión
También conviene institucionalizar una revisión de diseño para toda herramienta de automatización que ejecute lógica dinámica. Si un componente puede evaluar expresiones y además tiene acceso a secretos o APIs internas, debería tratarse como activo de alta criticidad, con controles de cambio, telemetría específica y pruebas de abuso en cada release.
CVE-2025-68613 muestra un patrón recurrente en tooling de automatización: cuando la plataforma une ejecución dinámica y acceso a múltiples sistemas, cualquier falla de aislamiento escala rápido a incidente de plataforma. La entrada en KEV consolida ese diagnóstico y vuelve urgente una respuesta operativa, no solo documental.
Para DevOps, SRE y seguridad, la lección es clara: en este tipo de componentes hay que tratar la gestión de expresiones y permisos como parte del perímetro crítico. Parche, hardening y monitoreo continuo deben ir juntos para reducir riesgo real en producción.
Fuentes
- CISA KEV Catalog (CVE-2025-68613)
- NVD – CVE-2025-68613
- GitHub Advisory Database – GHSA-v98v-ff95-f3cp