CVE-2026-118759: falla en Kubeflow expone logs cruzados

En pocas palabras: CVE-2026-118759 es una falla de autorización faltante (CWE-862) en Kubeflow Pipelines anterior a la versión 2.18.0, con CVSS 7.5 High. Permite leer logs de pods de otros tenants vía el endpoint de streaming de logs, sin verificar si el pod pertenece al run solicitado. Kubeflow corrigió la falla en la versión 2.18.0.

CVE-2026-118759 es una vulnerabilidad de autorización faltante (CWE-862) en el API server de Kubeflow Pipelines, el orquestador de flujos de machine learning sobre Kubernetes. El fallo vive en el endpoint de streaming de logs de ejecución y permite a un atacante con acceso de red leer logs de pods de otros usuarios usando los permisos del service account del propio API server. Kubeflow publicó el fix en la versión 2.18.0.

¿Qué endpoint de Kubeflow Pipelines está afectado por CVE-2026-118759?

El endpoint vulnerable es GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log, el que usa Kubeflow Pipelines para mostrarte en tiempo real (o desde archivo) la salida de un pod dentro de un run. El handler HTTP tiene dos problemas: no propaga los headers de la request entrante a la metadata de gRPC, y no corre ningún chequeo de autorización contra el run que se está pidiendo, según el reporte técnico de la vulnerabilidad.

En la práctica, esto significa que el servidor confía en que quien pide los logs ya pasó por un control de permisos en otro lado. No lo hizo. Es el clásico patrón de “confused deputy”: el API server actúa en nombre de alguien sin preguntarle si tiene derecho a ver lo que está pidiendo.

¿Por qué un atacante puede leer logs de pods de otros tenants?

Porque el backend toma el parámetro node_id y lo usa directo como nombre de pod de Kubernetes, sin chequear que ese pod realmente pertenezca al run_id indicado en la URL. Si tenés acceso de red al API server y conocés (o adivinás) un run_id válido, podés pedir logs de cualquier pod con contenedor main dentro del namespace de ese run, usando los permisos del service account ml-pipeline-api-server. Te puede servir nuestra cobertura de otro caso donde el scanner marcaba todo limpio.

Ponele que administrás un clúster Kubeflow multi-tenant, con equipos distintos corriendo pipelines en namespaces separados. En teoría, cada equipo solo debería ver sus propios logs. Con esta falla, alguien del equipo A podía terminar leyendo la salida de un pod del equipo B, siempre que estuviera en el mismo namespace de ejecución y tuviera un run_id que apuntara ahí.

El impacto queda acotado a confidencialidad: no hay escritura, no hay afectación de disponibilidad. Pero logs de ejecución de ML suelen tener rutas de datasets, variables de entorno, tokens de servicios externos o fragmentos de datos de entrenamiento. No es poco lo que puede filtrarse en un log que “solo” se lee.

¿Cuál es la severidad y el vector de ataque de CVE-2026-118759?

La severidad es CVSS v3.1 de 7.5, categoría High, con vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N: ataque remoto por red, complejidad baja, sin privilegios ni interacción de usuario, impacto alto en confidencialidad y nulo en integridad y disponibilidad. La clasificación CWE es doble: CWE-862 (Missing Authorization) y CWE-200 (Exposure of Sensitive Information).

El EPSS (probabilidad de explotación) está en 0.34%, percentil 27.01, y la vulnerabilidad no figura en el catálogo CISA KEV de fallas explotadas activamente. No hay exploits públicos conocidos al momento de la publicación. Eso sí: EPSS bajo no significa riesgo bajo en tu caso particular, sobre todo si corrés clústeres multi-tenant expuestos a redes internas poco segmentadas. En el RCE crítico que afectó a Entra ID profundizamos sobre esto.

¿Qué cambió en el código para solucionar la vulnerabilidad?

El equipo de Kubeflow resolvió el problema en el commit be4723e, integrado en el pull request #13684. El cambio agrega un verbo RBAC dedicado llamado readLog en const.go (junto a los ya existentes como readArtifact o reportMetrics) y suma una verificación explícita de ownership pod-a-run mediante chequeo de label en RunLogServer y ResourceManager.

En código: antes de servir cualquier log, el servidor ahora confirma que el caller tenga permiso readLog sobre el run, y además valida que el pod solicitado tenga el label pipelines.kubeflow.org/run_id correspondiente al run pedido. Dos capas donde antes no había ninguna.

¿Cómo actualizar y mitigar CVE-2026-118759 en Kubeflow Pipelines?

La mitigación definitiva es actualizar a Kubeflow Pipelines 2.18.0 o posterior, versión donde se integró el fix completo. Si no podés actualizar de inmediato, hay controles de contención que reducen la exposición mientras lo hacés.

• Actualizá el API server y el SDK: llevá el contenedor de la API y los componentes del SDK a la release 2.18.0.
• Aplicá los manifests RBAC actualizados: el archivo Kustomize manifests/kustomize/base/installs/multi-user/view-edit-cluster-roles.yaml necesita incluir el nuevo verbo readLog en los roles legítimos sobre el recurso runs.
• Restringí la red al puerto 8888: NetworkPolicies de Kubernetes que limiten el acceso directo pod-a-servicio contra el API server de ml-pipeline.
• Sumá una capa de gateway: Istio AuthorizationPolicy o reglas de API gateway que bloqueen o acoten el acceso a /apis/v1alpha1/runs/*/nodes/*/log.
• Acotá el service account: limitá los permisos de ml-pipeline-api-server para que no pueda leer logs de pods en namespaces administrativos que no sean de pipelines.
• Auditá logs históricos: revisá el audit log del API server de Kubernetes buscando requests pods/log emitidos por system:serviceaccount:kubeflow:ml-pipeline-api-server contra pods sin el label pipelines.kubeflow.org/run_id.

Un criterio práctico para verificar si tu entorno ya está protegido: hacé una request manual con GET a /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log usando un run_id válido pero un node_id de un pod que no pertenezca a ese run. Si la respuesta es distinta de 403 Forbidden, todavía estás expuesto. Esto es una propuesta de verificación propia, no algo que la fuente original haya probado ni documentado como test oficial. Relacionado: la falla crítica detectada en SonicWall SMA1000.

Errores comunes al tratar con esta vulnerabilidad

Primero, asumir que “no hay exploit público” equivale a “no hay riesgo”. El EPSS bajo describe probabilidad de explotación masiva, no el riesgo puntual en tu clúster si corrés multi-tenancy real con namespaces mal segmentados.

Segundo, actualizar la imagen del API server sin aplicar los manifests Kustomize con el verbo readLog. Si subís el contenedor a 2.18.0 pero dejás los roles RBAC viejos, los usuarios legítimos van a chocar contra permisos faltantes al pedir logs de sus propios runs, y vas a terminar relajando RBAC de forma apurada para “que funcione”, reabriendo el problema por otro lado.

Tercero, confiar en que una NetworkPolicy alcanza como mitigación permanente. Sirve como parche temporal, pero no reemplaza el fix de autorización en el código. Si el API server sigue corriendo versiones viejas, cualquier acceso de red interno sigue siendo un vector válido. Lo complementamos en la falla que permitía robar cuentas admin.

Preguntas Frecuentes

¿Qué es CVE-2026-118759?

Es una vulnerabilidad de autorización faltante en el API server de Kubeflow Pipelines que permite leer logs de ejecución de pods ajenos sin el permiso correspondiente. Tiene CVSS 7.5 (High) y afecta a todas las versiones previas a la 2.18.0.

¿Cómo afecta CVE-2026-118759 a Kubeflow Pipelines?

Permite que un atacante con acceso de red y un run_id válido lea logs en vivo o archivados de cualquier pod con contenedor main dentro del namespace de ese run, usando los permisos del service account del API server. El impacto es solo de confidencialidad, no afecta integridad ni disponibilidad. Ampliamos el tema en este RCE crítico en un plugin de WordPress.

¿Qué versión de Kubeflow Pipelines soluciona esta vulnerabilidad?

La versión 2.18.0 incluye el fix completo, aplicado en el commit be4723e. El cambio agrega el verbo RBAC readLog y una verificación de ownership pod-a-run mediante label.

¿Hay exploits conocidos de CVE-2026-118759?

No, según el reporte técnico no hay exploits públicos conocidos en circulación y la vulnerabilidad no figura en el catálogo CISA KEV de fallas explotadas activamente. El EPSS está en 0.34%, percentil 27.01.

¿Cómo mitigar CVE-2026-118759 si no puedo actualizar de inmediato?

Restringí el acceso de red al puerto 8888 del API server con NetworkPolicies, sumá una AuthorizationPolicy de Istio o reglas de gateway sobre el endpoint de logs, y acotá los permisos del service account ml-pipeline-api-server. Ninguna de estas medidas reemplaza la actualización a 2.18.0, pero reducen la ventana de exposición.

Conclusión

CVE-2026-118759 expone un problema de diseño clásico en arquitecturas multi-tenant sobre Kubernetes: un servicio que actúa con permisos elevados en nombre del usuario, sin verificar que ese usuario tenga derecho sobre el recurso puntual que pide. Si administrás un clúster Kubeflow Pipelines con varios equipos o proyectos corriendo en paralelo, la acción concreta es actualizar a 2.18.0 y aplicar los manifests RBAC actualizados antes de relajar ningún otro control. Mientras no lo hagas, tratá el endpoint de logs como una superficie expuesta y limitá quién puede llegar a él por red.

Fuentes

• Reporte técnico de CVE-2026-118759 – Cross-Tenant Pod Log Exposure via Authorization Bypass in Kubeflow Pipelines