Temporal Server CVE-2026-120091

Preconditions are concrete and layered. (1) Version: Temporal Server 1.31.0-1.31.2 are exposed in a stock deployment because workercontroller.compute_providers.enabled does not deny by default - when unset the allowlist check is skipped and the k8s provider is permitted; on 1.31.3+ and 1.32.0+ the allowlist denies by default and exposure exists only where k8s was explicitly added to that setting, checking both the global value and every namespace-constrained override. The 1.30 line lacks the Worker Controller Instance module and is not vulnerable. (2) The Worker Service must be running, which it is in the default service set. (3) Authorization must be configured with a real authorizer and claim mapper - a deployment with no authorizer already grants unrestricted cross-namespace access and has no boundary for this to cross. (4) The attacker needs an authenticated identity with at least a read role in one namespace, reaching the provider through ValidateWorkerDeploymentVersionComputeConfig; deployments with a custom authorizer should verify it does not permit that operation to callers lacking namespace write access. Limiting factors: exposure is gated by version and the compute-provider allowlist, and the separate workercontroller.enabled per-namespace setting does NOT gate this path on any affected release.

Multiple signals converge on genuine priority despite the absence of exploitation telemetry. The CWE-78 OS command-injection flaw yields code execution on the Worker Service host under the server account, and the input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) with score 8.7 matches the described mechanics: network-reachable, low attacker-supplied complexity, and only a low privilege level. The PR:L is the critical nuance - the ValidateWorkerDeploymentVersionComputeConfig route is registered as a read-only namespace operation, so a caller holding only a read role in a single namespace reaches the provider, which is a far weaker precondition than the write role CreateWorkerDeploymentVersion demands. Blast radius is cluster-wide: the Worker Service holds persistence credentials for every namespace and the cluster TLS material, so impact crosses the caller's namespace boundary even though the input vector marks SC/SI/SA:N. Exposure, however, is version- and configuration-dependent - stock 1.31.0 through 1.31.2 are exposed by default (allowlist skips the check when unset), whereas 1.31.3+/1.32.0+ are exposed only where k8s was explicitly added to workercontroller.compute_providers.enabled, and 1.30 is unaffected entirely. EPSS score is not provided in the input and the CVE is not listed in CISA KEV, so widespread or active exploitation cannot be asserted; the vuln.today decision label is this_week rather than act_now/emergency. Net: a high-severity, low-privilege RCE with cluster-wide consequences that warrants prompt patching, with real-world exposure gated by version and the compute-provider allowlist.

An authenticated user who holds only a read-only role in a single namespace submits a crafted Kubernetes client configuration to the read-only ValidateWorkerDeploymentVersionComputeConfig operation; building that client from the caller-supplied config executes an attacker-chosen command on the Worker Service host during validation, with no pre-existing worker deployment required. Because execution happens under the server process account, the attacker can reach the cluster-wide persistence credentials and TLS material. No public exploit identified at time of analysis; the trigger requires only a single validation request, not any scaling decision or task arrival.