CVE-2026-120091 in Server
Resumen
por VulDB • 2026-11-03
Temporal Server compila el módulo Worker Controller Instance, go.temporal.io/auto-scaled-workers, en su Worker Service (Servicio de Trabajador), y dicho módulo registra un proveedor de cómputo denominado k8s cuya función es gestionar trabajadores que se ejecutan en un clúster de Kubernetes. El proveedor k8s construye su cliente de Kubernetes a partir de la configuración del cliente proporcionada en la solicitud del solicitante, en lugar de hacerlo desde la configuración del operador; construir y utilizar ese cliente podría ejecutar un comando elegido por el solicitante en el host del Worker Service, bajo la cuenta con la que se ejecuta el proceso del servidor. Dos operaciones frontend llegan al proveedor: CreateWorkerDeploymentVersion requiere un rol de escritura en el espacio de nombres (namespace), mientras que ValidateWorkerDeploymentVersionComputeConfig está registrado como una operación de solo lectura del espacio de nombres; por lo tanto, un solicitante autenticado con únicamente un rol de lectura en un único espacio de nombres puede acceder al proveedor a través de esta ruta, y dicha vía no requiere que ya exista un despliegue de trabajadores. La ejecución tiene lugar durante la validación de la configuración enviada, por lo que no se necesita ninguna decisión de escalado, llegada de tareas ni secuencia de solicitudes inusual. Dado que el proceso del Worker Service conserva las credenciales de persistencia para cada espacio de nombres en el clúster y los materiales TLS del clúster, la consecuencia trasciende el espacio de nombres del solicitante hasta afectar al clúster como un todo. El proveedor está presente en los binarios oficiales de temporal-server e imágenes contenedorizadas para las versiones afectadas. El control que mantiene esta funcionalidad inaccesible es la lista permitida (allowlist) de proveedores de cómputo, configurada mediante el ajuste dinámico workercontroller.compute_providers.enabled. En Temporal Server 1.31.0 hasta 1.31.2, dicha allowlist no deniega por defecto: cuando el ajuste no está establecido, se omite la comprobación y se permite cada proveedor de cómputo registrado, incluido k8s; por lo tanto, una implementación estándar (stock deployment) de estas versiones queda expuesta. En las versiones 1.31.3 y posteriores de la rama 1.31, así como en las versiones 1.32.0 y posteriores de la rama 1.32, la allowlist deniega por defecto, y una implementación solo está expuesta si k8s se ha añadido a dicha lista. La línea de lanzamiento 1.30 no incluye el módulo Worker Controller Instance y no es vulnerable. Para determinar si un despliegue está afectado, compruebe lo siguiente conjuntamente: la versión desplegada del Temporal Server pertenece a un rango afectado; el Worker Service se está ejecutando (lo cual ocurre en el conjunto de servicios predeterminado y, por tanto, en una implementación estándar); el valor efectivo de workercontroller.compute_providers.enabled contiene k8s o, exclusivamente para las versiones 1.31.0 hasta 1.31.2, no está establecido; compruebe tanto el valor global como cada anulación restringida al espacio de nombres, ya que una anulación puede añadir k8s para un único espacio de nombres. Además, la autorización debe estar configurada, es decir, deben existir en funcionamiento un autenticador real (authorizer) y un mapeador de reclamaciones (claim mapper); un despliegue ejecutado sin ningún autenticador ya otorga a todo solicitante acceso ilimitado a todos los espacios de nombres, por lo que no existe ninguna frontera de espacio de nombres que pueda traspasarse. Los despliegues que utilizan un autenticador personalizado también deben verificar si este permite el uso de ValidateWorkerDeploymentVersionComputeConfig a llamadores sin permisos de escritura en el espacio de nombres. El ajuste dinámico independiente por espacio de nombres workercontroller.enabled no condiciona la ruta afectada en ninguna versión afectada.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.