Bajada: La inclusión de CVE-2025-68613 en el catálogo KEV confirma explotación activa sobre n8n. Qué cambia para equipos SysAdmin y DevOps que operan automatizaciones en producción.
Introducción
n8n se consolidó como una pieza habitual en muchos equipos de infraestructura y automatización: integra APIs, mueve datos entre sistemas, ejecuta tareas operativas y, en varios entornos, termina conectando servicios críticos con credenciales de alto valor. Por eso, cuando una vulnerabilidad de n8n entra en el catálogo Known Exploited Vulnerabilities (KEV) de CISA, deja de ser un tema de seguimiento para pasar a ser un riesgo operativo inmediato.
El 11 de marzo de 2026, CISA agregó CVE-2025-68613 al KEV por evidencia de explotación activa. La vulnerabilidad afecta el motor de evaluación de expresiones de n8n y puede derivar en ejecución remota de código bajo condiciones realistas de operación. En términos prácticos, no estamos ante una falla teórica: hay señales públicas de uso en campañas reales.
Qué ocurrió
CISA publicó una actualización del KEV incorporando CVE-2025-68613, descrita como una debilidad de Improper Control of Dynamically-Managed Code Resources en n8n. El registro en NVD detalla que versiones desde 0.211.0 hasta antes de 1.120.4/1.121.1/1.122.0 pueden evaluar expresiones de usuarios autenticados en un contexto insuficientemente aislado.
Ese comportamiento permite que un atacante autenticado ejecute código arbitrario con los privilegios del proceso n8n. Además, fuentes de inteligencia como Akamai documentaron actividad de explotación en 2026 y uso de la vulnerabilidad en campañas de malware automatizado, lo que refuerza el criterio de priorización aplicado por CISA.
Impacto para SysAdmin / DevOps
En muchas organizaciones, n8n no vive en un rincón. Suele estar conectado con bases de datos, SaaS corporativos, colas de mensajería, repositorios y sistemas de tickets. Si una instancia vulnerable es comprometida, el impacto puede ir mucho más allá del servidor donde corre:
- Exfiltración de secretos: tokens API, credenciales de integraciones y variables de entorno.
- Manipulación de flujos: alteración silenciosa de workflows que ejecutan tareas de negocio o de plataforma.
- Movimiento lateral: pivote desde una herramienta de automatización hacia otros servicios internos.
- Riesgo en CI/CD y operaciones: si n8n interactúa con runners, repos o despliegues, el atacante puede escalar impacto.
Para equipos DevOps, esto implica tratar n8n como componente de infraestructura crítica y no como aplicación auxiliar. La exposición aumenta cuando hay webhooks públicos, permisos amplios para usuarios no administradores o ejecución con privilegios de sistema innecesarios.
Detalles técnicos
La falla se vincula con el aislamiento insuficiente durante la evaluación de expresiones en workflows. En escenarios vulnerables, una expresión maliciosa definida por un usuario autenticado puede escapar del contexto esperado y ejecutar comandos en el runtime del servidor.
Los efectos posibles incluyen lectura/escritura de archivos locales, acceso a información sensible del host y ejecución de operaciones del sistema con los permisos del proceso n8n. El advisory también señala que los parches fueron incorporados en las versiones 1.120.4, 1.121.1 y 1.122.0, con salvaguardas adicionales para la evaluación de expresiones.
Un punto importante para operación: el vector requiere autenticación, pero eso no reduce necesariamente el riesgo en despliegues colaborativos. En entornos con múltiples usuarios, cuentas compartidas o controles débiles de RBAC, el camino a explotación puede ser corto. Además, reportes de PoC públicos incrementan la presión temporal sobre las ventanas de parcheo.
La inclusión en KEV también agrega una señal de prioridad para entornos regulados: cuando una CVE entra en ese catálogo, suele acelerar requerimientos de remediación, auditorías y controles compensatorios. Para organizaciones con n8n expuesto a Internet o integrado con activos críticos, la ventana de tolerancia se reduce de forma notable.
Qué deberían hacer los administradores
- Priorizar actualización inmediata a ramas corregidas (1.120.4/1.121.1/1.122.0 o superiores mantenidas por el vendor).
- Inventariar instancias n8n (producción, staging, laboratorios olvidados y despliegues shadow IT).
- Reducir superficie pública: restringir webhooks/form endpoints expuestos a internet hasta completar parcheo.
- Aplicar mínimo privilegio al proceso n8n (usuario no privilegiado, filesystem acotado, sin acceso root).
- Revisar credenciales y secretos almacenados en la instancia; rotar tokens de alto impacto tras parchear.
- Fortalecer segmentación: separar n8n de redes críticas y limitar egress para dificultar descarga de payloads.
- Monitorear IoC y telemetría en endpoints de ejecución de workflows, comandos inesperados y cambios no autorizados.
- Formalizar playbook de respuesta para herramientas de automatización: contención, evidencias y recuperación.
Si la actualización no puede aplicarse en el corto plazo, las mitigaciones compensatorias deben asumirse como temporales: ayudan a reducir exposición, pero no reemplazan el parche.
Conclusión
La entrada de CVE-2025-68613 al KEV de CISA confirma un patrón que los equipos de operaciones ya ven en campo: las plataformas de automatización pasaron a ser objetivo directo. En 2026, el riesgo no está solo en servidores tradicionales, sino también en piezas de orquestación que concentran permisos e integraciones.
Para SysAdmin y DevOps, la respuesta efectiva combina velocidad y disciplina: parcheo priorizado, reducción de privilegios, control de exposición y observabilidad enfocada en abuso de workflows. Tratar n8n como infraestructura crítica no es exageración; es una medida básica de resiliencia operativa.
Fuentes
- CISA: CISA Adds One Known Exploited Vulnerability to Catalog
- NVD: CVE-2025-68613
- Akamai SIRT: Zerobot Malware Targets n8n