Volver al Blog

Kestra, 10 sobre 10: el fallo que no necesita estar en Internet

Cuarto de instalaciones de una oficina: un ordenador de sobremesa apoyado en una estantería metálica junto a un conmutador de red pequeño, latiguillos grapados por la pared, una caja de cartón con cables debajo y material de limpieza en la balda de abajo

El 2 de septiembre CISA añadió siete fallos a su catálogo de vulnerabilidades explotadas. Tres son cajas de perímetro: dos de SonicWall y una centralita de Sangoma. Otras tres son servicios que no compró nadie de compras, sino que levantó alguien del equipo para ir más rápido. Y queda una séptima que no instaló nadie, porque llegó dentro de otra cosa. Dos de las siete puntúan 10,0 sobre 10: una es la caja de SonicWall, que no sorprende a nadie; la otra es un orquestador de flujos de trabajo, y la razón por la que se abre cabe en una línea de código.

Los siete del 2 de septiembre

Descargamos el catálogo KEV entero —el fichero known_exploited_vulnerabilities.json que CISA publica— y miramos qué entró ese día. Esta es la lista completa, sin recortar. Léela por la tercera columna, que es donde está lo interesante.

CVE Producto Dónde vive Plazo CISA
CVE-2026-83548 SonicWall SMA 1000 Perímetro 5 sep
CVE-2026-83549 SonicWall SMA 1000 Perímetro 5 sep
CVE-2026-9586 Sangoma Switchvox Perímetro 5 sep
CVE-2026-82329 JFrog Artifactory Dentro 5 sep
CVE-2026-49869 Kestra OSS Dentro 5 sep
CVE-2026-59822 BerriAI LiteLLM Dentro 16 sep
CVE-2026-48710 Kludex Starlette Dependencia 16 sep

Artifactory es el almacén de artefactos: guarda los paquetes que se despliegan y las credenciales que los suben. Kestra es un orquestador de flujos de trabajo: su oficio literal es ejecutar cosas con permisos. LiteLLM es la pasarela que se pone delante de los modelos de lenguaje para centralizar las claves de OpenAI, Azure o Anthropic. Los tres los levantó alguien de dentro, los tres tienen más privilegio que el cortafuegos y ninguno aparece en un inventario de «equipamiento expuesto».

Starlette merece columna propia y por eso se la hemos puesto. Es el armazón de Python sobre el que se construyen muchas de estas aplicaciones, y llega arrastrado como dependencia de FastAPI: no lo eligió nadie, no escucha en un puerto suyo, no tiene panel ni credenciales ni configuración por defecto que revisar. Su problema es de otra clase y probablemente peor, porque no aparece en la lista de servicios de nadie. Aparece, si acaso, en un fichero de dependencias que revisa una herramienta.

La línea

CVE-2026-49869, el 10,0 de Kestra, tiene una descripción que se lee de una sentada. El filtro de autenticación deja pasar sin credenciales el punto de configuración público, que es razonable. Lo que no es razonable es cómo comprueba que la petición va a ese punto:

request.getPath().endsWith("/configs")

Es una comparación por sufijo, no por ruta exacta. Cualquier camino de la API cuyo último segmento sea configs se salta la autenticación entera. Y hay uno muy interesante que acaba así: el que crea flujos de trabajo. Con eso, un atacante sin credenciales define un flujo, elige el ejecutor de procesos y consigue ejecución de comandos como root dentro del contenedor del trabajador, porque los complementos de ejecución de scripts vienen activados de fábrica. De la comparación de una cadena de texto a root, sin ninguna contraseña por medio.

Ya hemos escrito sobre esta familia de fallos: es el control que falla abriendo. Un control que, cuando no sabe qué hacer, deja pasar. La diferencia entre endsWith y una comparación exacta es la diferencia entre «se parece a la puerta de servicio» y «es la puerta de servicio». Un portero humano no confunde las dos cosas. Un filtro escrito con prisa, sí.

«No está en Internet» ya no ordena la cola

El aviso de Kestra dice, con todas las letras, que la instancia no necesita estar expuesta a Internet: basta con tener acceso de red a su puerto, el 8080 por defecto. Y el modo de autenticación afectado —el básico— es el que trae Kestra OSS de serie.

Ahora pon eso al lado de cómo se decide hoy qué se parchea antes. La directiva con la que CISA ordena a las agencias federales, la BOD 26-04 de junio de 2026, jubiló el régimen anterior —dos semanas para los CVE de 2021 en adelante, seis meses para los más viejos— y lo cambió por un modelo de cuatro factores. El primero de los cuatro es si el activo está expuesto. Los otros tres son estar en el catálogo, si el fallo se puede automatizar y qué impacto técnico tiene. De ahí salen los dos plazos de la tabla: tres días para cinco de las entradas, catorce para LiteLLM y Starlette. Para lo que la directiva considera no expuesto, el plazo puede estirarse hasta «arréglalo cuando toque actualizar».

El modelo es sensato y mejor que el anterior. Lo que falla es cómo lo aplicamos los demás, porque «expuesto» se ha convertido en una etiqueta que pegamos a un activo comprobando si tiene una IP pública, y esa comprobación se queda muy corta. La exposición no es una propiedad de la máquina: es una propiedad del camino que llega hasta ella. Ese orquestador que no publica nada al exterior está a un salto del corredor de integración continua, del portátil que entra por una VPN que da la red entera, y de cualquier otro contenedor del mismo anfitrión. Si algo de eso se puede comprometer, tu orquestador está expuesto. Lo que pasa es que en la hoja de cálculo pone que no.

Los cuatro de dentro fallan por lo mismo

Puestas las cuatro fichas en fila, lo que las une es de qué van. Ninguna es un desbordamiento de memoria ni un fallo de corrupción exótico: las cuatro tocan el código que decide quién entra.

  • Artifactory — la ficha de CISA dice que en la configuración por defecto un atacante sin autenticar con acceso de red puede obtener privilegios de administrador. Por defecto.
  • Kestra — la comparación por sufijo de arriba. Modo de autenticación por defecto.
  • LiteLLM — en el camino alternativo del gestor de autenticación MCP, una validación de clave fallida se podía sustituir por un objeto de autorización vacío. Traducido: presentas un Bearer inventado y te abre una sesión autenticada, con la que se listan y se invocan las herramientas conectadas. Arreglado en la 1.84.0.
  • Starlette — contrabando de peticiones que permite inyectar rutas en la parte del anfitrión y, cuando la autenticación depende de la ruta reconstruida, saltársela. Es el caso más condicional de los cuatro, y la propia ficha de CISA avisa de que se puede encadenar con CVE-2026-42271.

Cuatro productos distintos, cuatro equipos distintos, la misma clase de error. Y en dos de los cuatro está escrito con esas palabras en la ficha: por defecto. Es una consecuencia previsible de cómo se despliegan estas herramientas: se levantan con un docker compose up para probar una tarde, se quedan, y nadie vuelve a mirar la parte del arranque que decide la autenticación porque «está en la red interna». El fichero de arranque de un servicio que lleva año y medio corriendo es un documento histórico que casi nadie relee.

92 días

La versión con el arreglo, la 1.3.21, salió el 2 de junio de 2026, y sus notas ya mencionan «una posible omisión de autenticación en el filtro de autenticación». El aviso de seguridad se publicó al día siguiente. CISA lo metió en el catálogo el 2 de septiembre: noventa y dos días. La ficha pública del CVE, por cierto, no apareció hasta el 26 de junio, veinticuatro días después de que el parche ya estuviera descargable.

CISA no ha hecho nada mal: el catálogo admite una entrada cuando hay constancia de explotación, y ese es exactamente su criterio declarado. El problema aparece cuando alguien lo usa como sistema de aviso temprano, algo que el catálogo nunca ha dicho ser. Si tu cola de parcheo la ordena el KEV, para el software que instalas tú vas por detrás por diseño, y aquí el margen fueron tres meses en los que el arreglo estaba publicado y descargable.

Las versiones, para que no haya que buscarlas: Kestra está arreglado en 1.0.45 y 1.3.21; afecta a todo lo anterior a 1.0.45 y a la rama 1.1.0–1.3.20. LiteLLM, en 1.84.0.

Qué se hizo con el acceso, según Microsoft

El 26 de agosto, una semana antes de que CISA publicara la tanda, Microsoft describió tres compromisos reales en cargas de trabajo de IA: LiteLLM, RAGFlow y Kestra. Merece la pena leer qué hicieron los atacantes en cada uno, porque desmonta la idea de que un orquestador comprometido es «un servidor menos».

  • En Kestra: ejecución de intérprete de comandos a través del motor de flujos, reconocimiento del entorno de contenedores por el zócalo de Docker, un minero de criptomonedas y recolección de datos a través del almacén de clave-valor de la propia aplicación.
  • En LiteLLM: recolección de credenciales del entorno del proceso de la pasarela, binarios disfrazados, minero con la CPU ajustada para no cantar, acceso a la base de datos PostgreSQL de detrás y persistencia con claves SSH y entradas de cron.
  • En RAGFlow: un enganche de Python inyectado en el arranque de la aplicación para interceptar las claves de los proveedores mientras se configuraban, y sacarlas. Claves de OpenAI, Azure, Anthropic y Gemini.

La frase con la que Microsoft lo resume vale el clic: pasarelas, plataformas de recuperación, servicios de orquestación y tiempos de ejecución en contenedor «concentran credenciales, acceso a datos, conectividad con modelos y privilegios de ejecución, lo que los convierte en algunos de los componentes más poderosos de la pila de IA». Cambia «pila de IA» por «tu red» y sigue siendo verdad, porque un orquestador no necesita hablar con un modelo para tener las llaves de todo.

Y conviene decir la parte incómoda: el objetivo de casi todo esto era minar criptomonedas con tu factura eléctrica y llevarse claves de API. No hubo cifrado ni nota de rescate. Es exactamente el tipo de incidente que no te enteras de que has tenido, que es peor.

Lo que haríamos el lunes

Nosotros tenemos n8n autoalojado para tareas internas, así que esto lo escribimos con la casa por delante y no desde fuera. Lo tratamos como un servicio de producción: inventariado, con dueño y con ventana de actualización. Estas son las siete cosas que miraríamos, en este orden:

  • Haz la lista. Qué software autoalojado corre en tu red que no compró nadie: orquestadores, repositorios de artefactos, paneles, pasarelas, cosas de IA, el runner de la integración continua. Si sale de la memoria de dos personas y no de un inventario, ese es el primer hallazgo.
  • Ponle dueño y ventana. Un nombre por servicio y un día al mes en el que se actualiza. Sin eso, el resto de la lista se hace una vez y no se vuelve a hacer.
  • Prueba a llegar al puerto desde sitios raros. Desde la red de invitados. Desde el portátil que entra por VPN. Desde otro contenedor del mismo anfitrión. La lista de sitios desde los que se llega es tu exposición real, y suele ser más larga de lo que dice el diagrama.
  • Mira el zócalo de Docker. Si el contenedor lo tiene montado, comprometerlo es comprometer el anfitrión. En Kestra fue justo el camino del reconocimiento. Quítalo si no lo necesitas de verdad.
  • Apunta qué credenciales guarda cada uno, a qué llegan esas credenciales y qué pasaría si alguien las leyera todas de golpe. En una pasarela de modelos con las claves de cuatro proveedores dentro, eso se traduce en una factura además de en un incidente.
  • Si estabas en versión vulnerable, no basta con actualizar. Rota lo que vivía dentro y busca lo que Microsoft describe: procesos de minería, claves SSH que no pusiste, entradas de cron nuevas, salidas a fondos de minería.
  • Que la alerta llegue. Un minero se ve en la CPU y en el tráfico saliente mucho antes de que se note en otra cosa. Si nadie mira ese gráfico, da igual que exista.

Los dos primeros puntos son los que de verdad cambian algo, y son los más aburridos. Sobre el mismo problema visto por otro lado hemos escrito dos veces: cuando la cadena de despliegue guarda las llaves de producción y cuando el piloto de IA que nadie apagó se convierte en infraestructura sin que nadie lo decida.

Cuándo esto no va contigo

Si no tienes ninguna de estas cuatro piezas, no las instales por leer esto. Una asesoría de doce personas con Microsoft 365 y un NAS no tiene un orquestador de flujos y no lo necesita; su versión del mismo problema es el servidor de impresión, el grabador de las cámaras o el NAS que también hace de servidor de copias, y la pregunta útil sigue siendo la tercera de la lista: quién llega a ese puerto.

Y tampoco vamos a estirar una tanda de siete entradas hasta convertirla en una tendencia. Aunque, ya puestos, la honestidad va en las dos direcciones: en el mes de agosto el catálogo se pasó metiendo Langflow, TeamCity, Metabase, Ray, MLflow, Gitea, ownCloud, PaperCut y ya una vez Artifactory, junto a los cortafuegos y los sistemas operativos de siempre. Eso apoya nuestra tesis más de lo que la apoyaba el 2 de septiembre. Aun así son cinco semanas de datos, y con cinco semanas no se declara una tendencia; júzgalo tú. Lo que sí sostenemos sin recuento de por medio es lo otro: el aviso de Kestra dice que no hace falta estar en Internet, y eso es incompatible con ordenar la cola mirando si el activo tiene IP pública.

La pregunta que dejamos, que se responde en diez minutos y no requiere comprar nada: coge el orquestador, el repositorio o el panel más útil que tengas montado. ¿Desde cuántos sitios de tu red se llega a su puerto? Si la respuesta es «desde todos», la puntuación del próximo CVE que le salga ya no importa mucho.

Fuentes: la lista de las siete entradas del 2 de septiembre de 2026, sus productos, fechas de adición y plazos salen del catálogo KEV de CISA descargado el 6 de septiembre de 2026 (versión 2026.09.04) desde el catálogo público; de ahí sale también, literal, la descripción de CVE-2026-82329 sobre la configuración por defecto de Artifactory. Los detalles técnicos de CVE-2026-49869 (la comparación por sufijo en el filtro de autenticación, la ejecución como root en el contenedor del trabajador, las versiones 1.0.45 y 1.3.21, la puntuación 10,0 y que no hace falta exposición a Internet) proceden del aviso de seguridad de Kestra, publicado el 3 de junio de 2026. La fecha y la frase citada del lanzamiento de la 1.3.21 (2 de junio de 2026) salen de sus notas de versión; la fecha del 26 de junio es la del registro público del CVE, no la del aviso. Los de CVE-2026-59822 (el objeto de autorización vacío en el camino alternativo y la versión 1.84.0), del aviso de LiteLLM. El modelo de cuatro factores y los plazos, de la directiva BOD 26-04, de junio de 2026. Los tres compromisos y la frase citada, de «When AI infrastructure becomes the target», Microsoft Security Blog, 26 de agosto de 2026. Lo que no afirmamos: no decimos cuántas empresas españolas tienen estas piezas montadas, porque no lo sabemos; no atribuimos los compromisos a ningún grupo concreto; la clasificación «perímetro / dentro / dependencia» de la tabla es nuestra y no viene de CISA; y la lectura de que la tanda del 2 de septiembre señala un cambio de superficie es una lectura de un solo día, dicha con la reserva que eso merece.

¿Sabes qué corre en tu red que no compró nadie?

Montamos automatización con dueño, ventana de actualización y la red partida de forma que un contenedor comprometido no llegue a todo. Nosotros operamos las nuestras igual: si te decimos que lo inventaríes, es porque nos toca hacerlo a nosotros primero.

Automatización e IA Ciberseguridad Hablar con nosotros

Etiquetas:

Compartir:

Suscríbete a nuestra newsletter

Para recibir historias del mundo IT, novedades de everyWAN y ofertas exclusivas para suscriptores, date de alta a nuestra lista de correo

everyWAN
everyWAN