atlasvector/kestra-cve-2026-53576Reproducción de extremo a extremo y detección multicapa de CVE-2026-53576, el RCE no autenticado en Kestra — llevado más allá del PoC base para mostrar cómo una mala configuración común del socket de Docker convierte el root del contenedor en un compromiso total del host.
Kestra, una plataforma de orquestación de flujos de trabajo de código abierto, distribuyó un filtro de autenticación que decidía si una solicitud necesitaba credenciales comprobando si la URL terminaba con /configs - una comprobación destinada a exponer un único endpoint público inofensivo.
Debido a que la comprobación solo miraba el final de la cadena, cualquier solicitud cuya URL terminara de esa forma omitía por completo la autenticación, incluidos los endpoints que crean y ejecutan código arbitrario. El resultado: cualquiera que pueda alcanzar una instancia vulnerable de Kestra a través de la red puede ejecutar comandos como root sin credenciales, sin phishing, sin adivinar contraseñas y sin necesidad de ningún paso de escalada de privilegios.
En este ejercicio, esa única brecha se llevó de principio a fin contra una instancia de laboratorio autoalojada:
Cada etapa se capturó contra telemetría defensiva (IDS de red, seguridad en tiempo de ejecución del host, auditoría de Linux y registros del sistema).
Impacto empresarial si no se parchea: compromiso total del host que ejecuta Kestra, no solo de la aplicación, y por extensión de cualquier otra cosa alcanzable desde ese host.
Solución: actualizar a Kestra 1.0.45 / 1.3.21 o posterior (el parche por sí solo cierra la vulnerabilidad principal; las etapas de escalada y persistencia requieren una corrección separada e independiente: no montar el socket de Docker en contenedores de aplicaciones, véase la Sección 8).
Este informe documenta CVE-2026-53576, una vulnerabilidad de ejecución remota de código no autenticada con CVSS 10.0 en Kestra ≤1.3.20, causada por un bypass de autenticación por sufijo de ruta (AuthenticationFilter.java, endsWith("/configs")).
Un atacante que nombre el namespace y el ID de un flujo de trabajo como configs puede crear y ejecutar comandos de shell arbitrarios sin credenciales, como root, dentro del contenedor de Kestra. Corregido en 1.0.45 y 1.3.21. El mismo fallo también se reportó de forma independiente bajo CVE-2026-49869, que es el número incluido en el catálogo KEV de CISA vinculado a explotación real en el mundo real. Ambos deben citarse juntos, ya que las fuentes públicas y los escáneres pueden hacer referencia a cualquiera de los dos.
| Vulnerable | Kestra ≤ 1.3.20 (y anteriores a 1.0.45 en la línea 1.0.x) |
| Corregida | 1.0.45 / 1.3.21+ |
| CVE | CVE-2026-53576 |
| Aviso gemelo | CVE-2026-49869 - mismo fallo, incluido en KEV de CISA (en el mundo real) |
| Fecha | Evento |
|---|---|
| 2026-06-02 | Se publica Kestra 1.3.21; el changelog menciona un "posible bypass de autenticación en el filtro de autenticación" |
| 2026-06-03 | Se publica Kestra 1.0.45 en la línea 1.0.x |
| 2026-09-02 | CVE-2026-49869 (el aviso gemelo) se añade al catálogo KEV de CISA |
Homelab autoalojado:
- Host Debian (nombre de host docker, kernel 6.12.107+deb13-amd64),
- Docker Engine 29.8.1.
- Kestra desplegado como la imagen oficial kestra/kestra:v1.3.20, accesible a través de un proxy inverso Caddy en kestra.int.atlasvec.com.
- Pila de telemetría bajo prueba: Falco (runtime/eBPF, a nivel de host),
- Suricata 8.0.3 IDS (espejo SPAN pasivo), reenviando hacia Splunk.
Antes de tocar nada, confirmé que el objetivo era realmente vulnerable y que la pila de telemetría estaba activa. También tomé una instantánea del estado previo al ataque para poder revertir una vez terminado.
Kestra ejecutando la versión vulnerable:
El propio contenedor, activo y accesible:
Las unidades de Falco cargadas en el host:
Falco emitiendo eventos activamente (modo eBPF moderno):
El servicio de Suricata activo:
Y su eve.json escribiendo eventos en vivo:
Aquí se alinean dos errores, no uno.
En primer lugar, el filtro de autenticación decide si una solicitud puede omitir la autenticación haciendo coincidir el final de la ruta de la solicitud:```java // AuthenticationFilter.java — the vulnerable check, confirmed against the self-hosted v1.3.20 source if (path.endsWith("/configs")) { // treated as a public, unauthenticated path }
Esa comprobación existe para exponer un único endpoint inofensivo, la configuración de la instancia pública. Como `endsWith` solo lee la cola de la cadena, no puede distinguir una ruta segura de cualquier otra ruta que termine de la misma manera.
En segundo lugar, el enrutador de Kestra sigue enviando esas rutas similares a sus manejadores reales y sensibles. `/api/v1/main/flows/configs` llega al manejador de creación de flujos. `/api/v1/main/executions/configs/configs` llega al manejador de ejecuciones. El filtro deja pasar ambas como públicas, y el enrutador las ejecuta de todos modos. Nombra el namespace y el ID de un flujo como `configs`, y un endpoint que ejecuta código ahora termina en `/configs`, por lo que hereda el pase libre de la ruta pública.
El par de solicitudes capturado lo muestra claramente. `GET /api/v1/main/flows/search` sin credenciales devuelve `401`. `POST /api/v1/main/flows/configs` con el mismo encabezado de autenticación vacío devuelve `200` y almacena el flujo (ver §5.1).
## 5. Simulación de ataque
> Cada paso a continuación está capturado con su propia captura de pantalla. Todo se ejecuta dentro de mi propio homelab aislado contra una instancia de Kestra autoalojada detrás del proxy inverso.
### 5.1 Etapa 1 - bypass de autenticación -> root dentro del contenedor de Kestra
**Control :** `GET /api/v1/main/flows/search` sin credenciales → `401 Unauthorized`.
Confirma que la autenticación se aplica en una ruta normal.
_____
**Plant :** Enviando `POST /api/v1/main/flows/configs` sin encabezado de autenticación. El cuerpo es un YAML de flujo cuyo `namespace` y `flow id` son ambos `configs`, y contiene una tarea Commands que usa el task runner Process. El servidor devuelve `200 OK` y almacena el flujo. El sufijo `/configs` en una ruta por lo demás protegida es lo que desencadena el bypass **(ver Sección 4).**
**Listen & Wait** : Iniciando un listener simple usando nc con fines de prueba, para capturar la reverse shell.
**Trigger / Execution** `POST /api/v1/main/executions/configs/configs`, sin encabezado de autenticación → `200 OK`, nueva ejecución creada.
**BaaaaM :** Hemos obtenido la shell, pero recuerda - estamos "aislados", `root` **PERO** dentro del contenedor Docker de Kestra, así que "no deberíamos" poder escapar de aquí. "**bueno, eso es lo que pensaba**"
El comando de la tarea se ejecuta como hijo directo del proceso JVM de Kestra, confirmado mediante el árbol de procesos del lado del host, y se completa con éxito según el propio registro de ejecución de Kestra.
**Panel de registros de Kestra**
**Árbol de procesos de Kestra**
**Resultado:** ejecución remota de código no autenticada como root, dentro del contenedor de Kestra. Esta es la prueba completa y autocontenida de **CVE-2026-53576**.
### 5.2 Etapa 2 - escalada mediante socket de Docker expuesto (específico del homelab, no forma parte del propio CVE)
Desde la shell de la Etapa 1, se encontró `/var/run/docker.sock` montado en el contenedor - un patrón Docker-outside-of-Docker (DooD), común cuando el propio task runner `Docker` de Kestra está configurado, ya que necesita un daemon con el que comunicarse.
Alcanzar ese socket es equivalente a **root** en el host: la API de Docker permite a un cliente configurar montajes bind arbitrarios del host y namespaces de PID/red del host para los contenedores que genera, y el daemon detrás del socket ya se ejecuta como root en el host.
Esto no es un exploit de kernel ni de escape de contenedor - es la API de Docker haciendo lo que está diseñada para hacer, alcanzada desde un lugar desde el que no debería haber sido alcanzable.
Usando el socket, creé un contenedor hermano con el sistema de archivos del host montado y los namespaces de PID y red del host, y luego lo inicié.
**Nota:** una segunda variante más silenciosa también surgió durante las pruebas, aunque no la capturé por separado. En lugar de crear siempre un nuevo contenedor hermano, el mismo acceso al socket te permite ejecutar `POST /containers/{id}/exec` contra un contenedor que ya está en ejecución, por lo que no hay ningún evento de creación de contenedor. En este host Docker tengo tanto Kestra como Portainer, cualquiera de los cuales podría usar para el mismo escape. Eso importa para la detección: cualquier regla centrada en la creación de un nuevo contenedor privilegiado pasa por alto esta variante.
Confirmando root y encontrando el socket ahí, sin restricción alguna:
Comprobando que el daemon de Docker es realmente accesible a través del socket:
Listando qué imágenes ya están locales, para no necesitar descargar nada:
Primer intento: un contenedor privilegiado con el sistema de archivos del host montado:
Segundo intento, esta vez añadiendo los namespaces de PID y red del host:
Tercer intento, haciendo chroot directamente en el sistema de archivos del host montado:
Listener activo y esperando en el puerto al que llamará la shell de escape:
Iniciando el contenedor:
**Root, pero esta vez es el host, no el contenedor:**
Versión del kernel que coincide con el host real, no con la vista aislada de un contenedor:
Actualizando a una shell interactiva adecuada para el resto de la sesión:
### 5.3 Etapa 3 - persistencia, confirmada en ejecución
Desde la shell con root en el host configuré dos mecanismos de persistencia independientes,
**Primero**, una clave SSH. Comprobé quién ya tenía acceso :
Luego revisé la propia configuración de sshd por si algo bloquearía una nueva clave:
Generé un par de claves en la máquina atacante:
Confirmé que sshd estaba realmente escuchando:
Coloqué la clave pública en el `authorized_keys` de root:
Y accedí con la clave privada correspondiente:
**PD:** Eso es acceso root independiente de la cadena de RCE original. Aunque Kestra se parchee, esta clave sigue funcionando.
**Segundo**, un beacon de cron. Coloqué una llamada de retorno a nivel de root programada para ejecutarse a intervalos, y luego probé con un listener nuevo para ver si realmente se disparaba según lo previsto:
**Se disparó. Un segundo punto de apoyo en el host, independiente tanto del RCE como de la clave SSH.**
### 5.4 Cronología verificada de la kill-chain.
La cronología a continuación es diferente: está reconstruida enteramente a partir de telemetría independiente del lado del defensor (IDS de red + seguridad en tiempo de ejecución del host), extraída y validada en vivo contra datos reales de Splunk.
**RCE principal - la red detecta la entrega, el host confirma la ejecución, con 103 segundos de diferencia:**
| Hora (EDT) | Capa | Evento |
| ------------ | ------------------ | -------------------------------------------------------------------------------------------- |
| 02:46:09.778 | Red (Suricata) | Se dispara la firma pública ET para este CVE exacto |
| 02:47:52.277 | Host (Falco) | Reverse shell confirmada dentro del contenedor de Kestra, con el comando exacto y el ID del contenedor capturados |
**Escalada - la red y el host corroboran cada uno de forma independiente una parte distinta del mismo evento:**
| Hora (EDT) | Capa | Evento |
| ------------ | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| 03:48:55.503 | Host (Falco) | Reverse shell desde el contenedor de escalada |
| 03:51:57.360 | Red (Suricata) | Flujo TCP **y** una alerta basada en contenido - la cadena literal `uid=0(root)` se vio saliendo del host en texto plano cuando se ejecutó `id` |
## 6. Ingeniería de detección
Construí las detecciones contra telemetría real capturada, y luego probé cada una contra una repetición. La matriz muestra dónde existía cobertura antes de empezar y dónde no.
### 6.0 Matriz de cobertura de detección
| Etapa | Red (Suricata) | Host (Falco) | Host (auditd/journald) | Estado |
| --- | --- | --- | --- | --- |
| Solicitud de exploit inicial | Se dispara la firma pública ET | Sin visibilidad de capa de aplicación | - | Cubierto (preexistente) |
| Ejecución de RCE | - | Regla nativa, etiquetada T1059 | - | Cubierto (preexistente) |
| Escalada por socket de Docker (la técnica) | - | Brecha: solo captura la shell resultante, no las llamadas a la API de abuso del socket | Los registros EXECVE capturan las llamadas exactas `curl --unix-socket` | Brecha encontrada, cerrada con auditd + una regla Falco personalizada |
| Confirmación del impacto de la escalada | Alerta de contenido sobre la salida filtrada de `id` | La misma regla genérica de shell | - | Cubierto (preexistente, entre capas) |
| Persistencia por SSH | - | - | journald: ciclo de vida completo de PAM más la huella de la clave | Cubierto (solo host) |
| Persistencia por cron | - | - | journald y linux_audit, dos fuentes, cadencia exacta de 5 min | Cubierto (solo host) |
La brecha es la escalada por socket de Docker. Las reglas predeterminadas de Falco capturan la shell que genera un contenedor comprometido, pero nada en el conjunto predeterminado estable marca un proceso que alcanza `/var/run/docker.sock` para manejar directamente la API de Docker. Las reglas que tocarían lanzamientos de contenedores privilegiados, `Launch Privileged Container` y `Launch Sensitive Mount Container`, se distribuyen con madurez `incubating` y `sandbox`, por lo que el conjunto de reglas predeterminado tampoco las carga. Cerré la brecha con una búsqueda de correlación de auditd (Detección 03) y una regla Falco personalizada (§6.3).
### 6.1 Splunk - cinco búsquedas de correlación, desplegadas y programadas
Las cinco se ejecutan en vivo en Splunk (`*/5 * * * *`, seguimiento de alertas habilitado, limitación por campo), no solo escritas y dejadas como texto. El SPL completo, las notas exactas de FP, la severidad, las etiquetas MITRE y los runbooks de respuesta para cada una están en `detections/splunk/*.spl`. La tabla de estado a continuación es el resultado probado en vivo para cada una, incluido un bug real que encontré y corregí.
| # | Detección | MITRE | Estado |
| --- | ---------------------------------------------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| 01 | Firma de exploit de red (consume la alerta ET de Suricata) | T1190 | **Disparada** - repetición histórica confirmada, sin nuevos eventos desde entonces (fuera del lookback actual) |
| 02 | Ejecución de RCE en host (regla Falco de redirección a red) | T1059 | **Disparada** - repetición histórica confirmada |
| 03 | Abuso de socket de Docker (auditd, la que cierra la brecha) | T1610, T1611 | **Disparada en el propio programador en vivo** - `triggered_alert_count: 1` confirmado en la ejecución real `*/5 * * * *`, no solo en una prueba manual |
| 04 | Persistencia de inicio de sesión root por SSH | T1098.004, T1021.004 | **Disparada** - repetición histórica confirmada |
| 05 | Persistencia por beacon de cron | T1053.003 | **Desplegada con un bug que encontré y corregí en vivo.** La ventana de despacho `-10m` contenía solo dos de los tres intervalos de 5 minutos que necesita el umbral `distinct_intervals >= 3`, por lo que nunca podía dispararse a pesar de que el beacon seguía ejecutándose en datos reales. La amplié a `-30m` y la redesplegué - y el programador la ha disparado 53 veces desde entonces, así que la corrección se mantiene. |
La división del trabajo de la Detección 03 es deliberada: en lugar de reimplementar la propia lógica de firma de Suricata en SPL, o intentar que Falco capture una técnica a nivel de socket para la que no fue construido, la capa SIEM aquí consume el registro EXECVE de auditd de las llamadas exactas `curl --unix-socket` - la fuente de telemetría que se demostró más fiable para esta técnica específica.
1. **Detección 01** - Disparo de la firma ET (alerta `suricata:eve`):```spl
index=main sourcetype=suricata:eve event_type=alert
alert.signature="ET WEB_SPECIFIC_APPS Kestra Unauthenticated Remote Code Execution (CVE-2026-53576)"
| stats count min(_time) as first_seen max(_time) as last_seen
values(src_ip) as source_ips
by dest_ip dest_port
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S")
| eval last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
Detección 02 - la regla de redirección a red de Falco, desglosada por contenedor. La IP de origen cambia de la dirección de bridge del contenedor de Kestra (172.17.0.3, RCE principal en el puerto 4489) al propio host (172.66.66.67, escalada en el puerto 4491) - la escalada de contenedor a host hecha visible - mientras que el destino permanece constante: el listener del atacante en 172.66.66.125:
Detección 03 - registros EXECVE de auditd de curl --unix-socket docker.sock:
Detección 04 - inicio de sesión SSH de root en journald, huella de clave capturada:
Detección 05 - el beacon cron de archivo oculto con punto (/usr/local/bin/.sysmon) ejecutándose como root con una cadencia exacta de 5 minutos: 79 intervalos distintos a lo largo de ~6,5 horas (04:30-11:00 EDT). El umbral distinct_intervals >= 3 es lo que separa un beacon periódico de un trabajo cron puntual:
Las cinco desplegadas como búsquedas guardadas programadas (*/5 * * * *):
Prueba de que el programador de cron realmente las ejecuta, no solo de que existen: las cinco se ejecutaron 54 veces. La Detección 03 se disparó una vez (el abuso del docker-socket, 06:35 EDT) y la Detección 05 se disparó 53 veces (el beacon cron aún activo). Las Detecciones 01/02/04 muestran 0 disparos, ya que son eventos históricos puntuales (solicitud de exploit, RCE, inicio de sesión SSH) que han quedado fuera de la ventana de búsqueda de -10m, mientras que una instancia activa o recurrente seguiría alertando:
El patrón de reverse-shell /dev/tcp/ - usado tanto en el RCE principal como en el callback de escalada. SigmaHQ incluye una regla para ello: "Suspicious Reverse Shell Command Line" (id 738d9bcf-6999-4fdb-b4ac-3033037db8ab, de Florian Roth en Nextron Systems), y una de sus palabras clave es bash -i >& /dev/tcp/ - exactamente lo que apareció en nuestra captura.
Así que tomé esa regla sin cambios (detections/sigma/lnx_shell_susp_rev_shells.yml) y verifiqué su palabra clave contra el mismo evento de Falco que la Detección 02 ya había capturado. Sigma no "se dispara" por sí sola - es una firma portátil, no un motor en ejecución - pero puedo mostrar su palabra clave incidiendo sobre telemetría real de esta ejecución en lugar de un ejemplo de manual.
Regla pública de SigmaHQ "Suspicious Reverse Shell Command Line" - su palabra clave bash -i >& /dev/tcp/ contra el mismo evento real que la Detección 02:
detections/falco/docker_socket_abuse.yaml - desplegada en la instancia activa de Falco y confirmada disparándose en una repetición real, 2026-09-24T10:27:29Z.
El conjunto de reglas predeterminado de Falco no cubre esto. Detectar un proceso que accede a /var/run/docker.sock no es una idea nueva - los propios ejemplos de Falco de Sysdig lo hacen vigilando open_write sobre la ruta del socket - pero no existe tal regla en el conjunto incluido/predeterminado (el proyecto tiene una solicitud abierta para una, falcosecurity/falco #2940), y la única regla predeterminada adyacente solo captura los CLI docker/kubectl, no un curl --unix-socket en crudo.
El problema: ese enfoque estándar de open_write sobre el socket no se disparó en esta configuración - con modern_bpf y un espejo pasivo, se accede al socket mediante connect(), no open(). Así que en su lugar hago coincidir la línea de comandos del proceso en el momento del spawn (spawned_process + proc.cmdline contains "docker.sock"), la misma clase de evento que Falco ya maneja de forma fiable aquí. Se dispara dos veces por llamada - el wrapper de shell y la hoja curl - con contexto completo:```
priority=Critical, container_id=d417e027d444, image=kestra/kestra:v1.3.20, user=root, cmdline="curl -s --unix-socket /var/run/docker.sock http://localhost/version", tags=[T1610, T1611]
Regla personalizada de Falco disparada - "Unexpected Process Accessing Docker Socket" (T1610/T1611):
Reglas de Falco estándar que se dispararon - el conjunto por defecto no tiene una regla para el socket de Docker, que es la brecha:
### 6.4 Suricata - cobertura pública existente, regla personalizada diferida
La capa de red para el exploit principal ya está cubierta por una firma pública de Emerging Threats, `ET WEB_SPECIFIC_APPS Kestra Unauthenticated Remote Code Execution (CVE-2026-53576)`, que se disparó sobre tráfico real durante la Fase 2.
A continuación se muestra el mismo bypass visto en la capa de red, y construí la consulta a partir del patrón de la vulnerabilidad. Cada petición cuya ruta terminaba en `/configs` sobre un endpoint `flows` o `executions` devolvió `200`, mientras que una ruta normal (`/flows/search`) devolvió el `401` esperado.
La columna `Attacker IP (XFF)` es el origen HTTP real, leído del encabezado `X-Forwarded-For`: `10.10.10.106`, mi Mac ejecutando Burp. El propio `src_ip` de Suricata solo ve el salto del proxy inverso (`172.66.66.1`). Esa es una máquina distinta de la caja Kali `172.66.66.125` que después recibió las reverse shells e hizo el inicio de sesión SSH, por lo que el exploit HTTP y los callbacks provinieron de hosts separados.
### 6.5 Dashboard
`cve_2026_53576_kill_chain` está desplegado en Splunk y contiene: KPIs destacados (capas de detección, técnicas de ATT&CK, detecciones desplegadas, mecanismos de persistencia), un gráfico de columnas de la línea de tiempo del ataque coloreado por capa de telemetría, un mapa de la kill-chain de MITRE ATT&CK con un recuento de evidencia en vivo por etapa, la línea de tiempo correlacionada de red y host de la §5.4, la cobertura de detección por búsqueda guardada programada, el desglose de la técnica del socket de Docker, y una tabla de indicadores de compromiso extraída en vivo de los logs.
- KPIs, el gráfico de la línea de tiempo del ataque, y el inicio del mapa de ATT&CK:
- El resto del mapa de ATT&CK, la kill-chain correlacionada, la cobertura de detección junto al desglose del socket de Docker, y la tabla de IOC:
## 7. Mapeo de ATT&CK
| Táctica | Técnica | Evidencia |
| -------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Acceso Inicial | T1190 - Exploit Public-Facing Application | Peticiones de control/plant/execute (§5.1); disparo de firma ET de Suricata, §5.4 |
| Ejecución | T1059.004 - Command and Scripting Interpreter: Unix Shell | Tarea `Commands` de Kestra, árbol de procesos del host (`07-kestra-process-tree.png`); regla de Falco, §6.1 Detección 02 |
| Comando y Control | T1095 - Non-Application Layer Protocol | Reverse shell TCP cruda vía `/dev/tcp/` - sin uso de framing C2 de capa de aplicación |
| Descubrimiento | T1613 - Container and Resource Discovery | Enumeración de imágenes Docker a través del socket (`10-docker-images-enum.png`) |
| Escalada de Privilegios | T1610 - Deploy Container | Creación/inicio de contenedor hermano vía la API de Docker (`11`–`15`); registros EXECVE de auditd, §6.1 Detección 03 |
| Escalada de Privilegios | T1611 - Escape to Host | Confirmación de root en el host, coincidencia de hostname/kernel (`16`, `17`) |
| Persistencia | T1098.004 - Account Manipulation: SSH Authorized Keys | Implante de clave en `/root/.ssh/authorized_keys` (`23`) |
| Movimiento Lateral | T1021.004 - Remote Services: SSH | Inicio de sesión root exitoso basado en clave (`24`); journald, §6.1 Detección 04 |
| Persistencia | T1053.003 - Scheduled Task/Job: Cron | Baliza de cron, confirmada disparándose según lo programado (`25`); §6.1 Detección 05 |
## 8. Remediación y Endurecimiento
**Corrección principal.** Actualizar a Kestra 1.0.45 (línea 1.0.x) o 1.3.21+ (línea 1.3.x). Esto por sí solo cierra el bypass de autenticación - la Etapa 1 de este ejercicio - y es
la única corrección que no requiere controles compensatorios adicionales una vez aplicada. Ver [GHSA-2q47-568g-9h4f](https://github.com/kestra-io/kestra/security/advisories/GHSA-2q47-568g-9h4f).
**Si el parcheo inmediato no es posible**, controles compensatorios, en orden de impacto:
1. **Aplicación en el proxy inverso** - dado que el filtro vulnerable solo falla con el sufijo de ruta crudo, un proxy inverso delante de Kestra (Caddy, en este laboratorio) puede aplicar de forma independiente la autenticación en cualquier ruta que coincida con `/api/v1/*/(flows|executions)/.*` sin importar en qué termine, cerrando el bypass en una capa que el bug de la aplicación no puede alcanzar.
2. **Restringir el montaje del socket de Docker** - esto cierra las Etapas 2–3 por completo, independientemente del parche de Kestra. No montes con bind `/var/run/docker.sock` dentro del contenedor de Kestra. Si el ejecutor de tareas `Docker` es genuinamente necesario, usa un proxy de socket con alcance limitado (p. ej. `docker-socket-proxy`) que permita en lista blanca llamadas específicas a la API en lugar de otorgar acceso completo al daemon - el acceso completo al socket equivale a root en el host, como se demostró en la §5.2.
3. **Endurecimiento de SSH** - el primer mecanismo de la cadena de persistencia dependía de que root fuera alcanzable vía SSH basado en clave. `PermitRootLogin no` (o requerir un bastión/MFA para root) habría bloqueado esa ruta de persistencia específica independientemente del RCE inicial - vale la pena hacerlo con independencia de este CVE.
4. **Cobertura de detección provisional** - las búsquedas de correlación de Splunk y la regla personalizada de Falco, todas desplegadas y verificadas durante este ejercicio, proporcionan la cobertura provisional para las etapas de esta cadena específica mientras se programa el parcheo.
**Higiene post-incidente**, si este patrón se encuentra ya explotado: trátalo como un compromiso total del host, no solo de la aplicación - rota cada credencial y secreto a los que la instancia de Kestra tenía acceso (entradas del almacén KV, credenciales de conexión para sistemas posteriores), no solo el propio acceso de Kestra.
**Estado en el mundo real.** `CVE-2026-49869`, el aviso gemelo para este mismo bug, está listado en el catálogo KEV de CISA y vinculado a campañas observadas de criptominería y robo de credenciales en la nube. `CVE-2026-53576` (este informe) no tiene su propia entrada en KEV, pero es la misma vulnerabilidad. Las herramientas de gestión de vulnerabilidades que rastrean solo uno de los dos números CVE pueden subreportar la exposición.
## 9. Referencias
- Aviso de Seguridad de Kestra - [GHSA-2q47-568g-9h4f](https://github.com/kestra-io/kestra/security/advisories/GHSA-2q47-568g-9h4f) (CVE-2026-53576, fuente principal de este informe)
- Aviso gemelo - [GHSA-5vc5-wxxq-3fjx](https://github.com/kestra-io/kestra/security/advisories/GHSA-5vc5-wxxq-3fjx) (CVE-2026-49869, bug idéntico, listado en KEV de CISA)
- CVE.org - [CVE-2026-53576](https://www.cve.org/CVERecord?id=CVE-2026-53576), [CVE-2026-49869](https://www.cve.org/CVERecord?id=CVE-2026-49869)
- Catálogo de Vulnerabilidades Explotadas Conocidas de CISA - https://www.cisa.gov/known-exploited-vulnerabilities-catalog (entrada de CVE-2026-49869, añadida el 2026-09-02)
- Versiones corregidas, ambas confirmadas como existentes y etiquetadas - [v1.3.21](https://github.com/kestra-io/kestra/releases/tag/v1.3.21) (2026-06-02, el changelog referencia explícitamente "potential authentication bypass in the authentication filter"), [v1.0.45](https://github.com/kestra-io/kestra/releases/tag/v1.0.45) (2026-06-03)
- Técnica de escalada del socket de Docker (§5.2) - [HackTricks: Docker Breakout / Privilege Escalation](https://hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/index.html), [Trail of Bits: Understanding Docker Container Escapes](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/), [MindPatch: Docker Escape](https://www.mindpatch.net/posts/docker-escape/)
- Regla de Sigma (§6.2) - la regla pública que usé en lugar de escribir la mía propia: [SigmaHQ "Suspicious Reverse Shell Command Line"](https://github.com/SigmaHQ/sigma/blob/master/rules/linux/builtin/lnx_shell_susp_rev_shells.yml) (id `738d9bcf-6999-4fdb-b4ac-3033037db8ab`, Florian Roth / Nextron Systems), usada bajo la [Detection Rule License 1.1](https://github.com/SigmaHQ/sigma/blob/master/LICENSE.Detection.Rules.md)
- Regla de Falco (§6.3) - la brecha del socket de Docker es una solicitud abierta upstream ([falcosecurity/falco #2940](https://github.com/falcosecurity/falco/issues/2940)); la regla personalizada sigue el patrón de [los ejemplos de Docker + Falco de Sysdig](https://www.sysdig.com/blog/docker-falco-security)
| 2026-09-22 a 09-24 |
| Esta reproducción en laboratorio, construcción de detección y validación entre capas |