Temporal Server: k8s compute provider builds a client from caller input, running commands on the Worker Service host

Impact

The k8s compute provider in Temporal's Worker Controller Instance module built its Kubernetes client from the client configuration supplied in the caller's request, and building that client could execute a command of the caller's choosing on the Worker Service host as the server's user. ValidateWorkerDeploymentVersionComputeConfig is registered as a read-only namespace operation, so an authenticated caller with only a read role in a single namespace reaches the provider, and no worker deployment needs to exist. Because the Worker Service process holds the persistence credentials for every namespace plus the cluster's TLS material, the blast radius is the whole Temporal cluster, not the caller's namespace - on a GPU fleet that is the scheduler/orchestration plane for training and batch jobs across tenants. On 1.31.0 through 1.31.2 the compute-provider allowlist does not deny by default, so a stock deployment of those releases is exposed; on 1.31.3+ and 1.32.0+ it denies by default and only deployments that added k8s to workercontroller.compute_providers.enabled are exposed. The 1.30 line does not ship the module.

Who can reach it

Any authenticated Temporal caller holding a read role in any single namespace, over the frontend API. Deployments running with no authorizer at all already grant everyone everything, so this crosses a boundary only where authorization is configured. 1.30 is unaffected.

What to do

Upgrade to Temporal Server 1.31.5 or 1.32.2 (or later in those lines) and restart the frontend/worker services - a rolling restart of the Temporal deployment, no node reboot. If you cannot upgrade immediately, set the dynamic config workercontroller.compute_providers.enabled explicitly so it does not contain k8s, and check every namespace-constrained override as well as the global value, since an override can re-add k8s for one namespace. Verify the deployed version, that the Worker Service is running (it is in the default service set), the effective allowlist value, and whether a custom authorizer lets read-only callers invoke ValidateWorkerDeploymentVersionComputeConfig.

References

Related entries

• GitLab CE/EE: stored XSS in analytics dashboard pagination controlsCVE-2026-15216 · GitLab CE/EE (analytics dashboard pagination controls)High
• GitLab CE/EE: stored XSS in analytics dashboard table cell renderingCVE-2026-15217 · GitLab CE/EE (analytics dashboard table cell rendering)High
• Sigstore Fulcio: OIDC discovery follows cross-host redirects and leaks ServiceAccount tokensCVE-2026-49478 · Sigstore Fulcio (OIDC discovery HTTP client, cross-host redirects)High
• Kestra: fast SHA-512 admin password hash allows offline cracking and cluster token theftCVE-2026-55069 · Kestra OSS (BasicAuth password hashing)High
• Loytec L-INX, L-GATE, L-ROC, L-IOB, L-DALI, L-VIS, L-PAD and LIP-ME201C (through 8.4.18, LINX-A64): An out-of-boundsCVE-2026-55732 · Loytec L-INX, L-GATE, L-ROC, L-IOB, L-DALI, L-VIS, L-PAD and LIP-ME201C (through 8.4.18, LINX-A64)High
• Netty: OpenSSL client path silently skips TLS hostname verification on Java 25+CVE-2026-62243 · Netty io.netty:netty-handler (SslProvider.OPENSSL client-side hostname verification)High