Un fallo crítico en Kestra OSS permite ejecutar código sin autenticarse

CVE-2026-49869 es un bypass de autenticación en Kestra OSS que escala a ejecución remota de código sin credenciales. La puntuación CVSS 3.1 es de 10,0, y CISA la añadió a su catálogo de vulnerabilidades explotadas el 2 de septiembre de 2026. Las versiones afectadas llegan hasta la 1.3.20 inclusive (los datos del CVE también lo expresan como < 1.0.45 y >= 1.1.0, < 1.3.21), y la corrección está en la 1.0.45 y la 1.3.21.

El fallo está en el AuthenticationFilter. Cualquier ruta de petición terminada en /configs se saltaba la autenticación básica. Y como "configs" puede aparecer como identificador de recurso controlado por quien llama en otras rutas de la API, se podía alcanzar endpoints protegidos sin credenciales. Kestra trae plugins de ejecución de scripts activados por defecto, así que un llamante anónimo que consiga crear un workflow y dispararlo ejecuta comandos dentro del worker. No hace falta una vulnerabilidad de inyección de comandos aparte: la capacidad legítima de ejecución del orquestador se convierte en la primitiva del atacante.

Qué se puede medir desde fuera

Dos consultas en ZoomEye del 16 de septiembre, con scope all, dan 119 activos para app="Kestra" y 231 para title="Kestra". Las consultas app="Kestra OSS" y vul.cve="CVE-2026-49869" devolvieron cero, pero eso no significa nada bueno: la primera indica que esa cadena no es una huella de producto válida en el índice, y la segunda refleja el retraso habitual en la indexación de CVE. Ninguna de las dos es prueba de que alguien haya parcheado.

Los dos números positivos miden el mismo producto por señales distintas —una huella de aplicación según el escáner, un título HTML en el otro caso— y se solapan, así que sumarlos está mal. Tampoco son la población definitiva de instancias expuestas. Lo que no dicen es qué versión corre cada una, si es alcanzable más allá del puerto escaneado, si hay una capa de autenticación por delante que frene el bypass antes de llegar al filtro, ni si alguien ha entrado ya. Una huella pública dice que el producto está ahí; solo su dueño sabe la versión y la configuración.

Del recuento a la acción

El arreglo del fabricante normaliza la ruta y compara el endpoint público de configuración exactamente como /api/v1/configs, además de añadir pruebas de regresión que confirman que otras rutas terminadas en /configs devuelven 401 Unauthorized.

Para quien opera Kestra, el orden útil es: cotejar los recuentos públicos contra el inventario propio, porque estos orquestadores suelen desplegarlos equipos de plataforma o de datos y no siempre están en el registro central; ver qué instancias son alcanzables desde redes no confiables —una instancia que no mira a internet puede explotarla alguien que ya está en la red de oficina, desarrollo o del clúster—; subir a 1.0.45, 1.3.21 o posterior; y, hasta que eso ocurra, restringir la API en la capa de red y exigir autenticación en el proxy de delante en lugar de fiarse del filtro de la aplicación.

Ser root dentro del contenedor del worker no es ser root en el host: escapar depende de montajes, capabilities, sockets expuestos, cuentas de servicio y configuración del runtime. Que CISA confirme explotación no implica que todas las instancias expuestas estén comprometidas.

Lo llamativo es lo poco llamativo del número. Uno o dos centenares de instancias con huella pública es una población pequeña, y encaja con un componente que tiende a desplegarse en redes internas y detrás de controles de acceso, que es donde debería estar. Donde una plataforma puede ejecutar código y alcanzar credenciales, el recuento de exposición sirve para verificar la configuración, no para sustituirla.