Temporal Server includes a Worker Controller Instance module that registers a compute provider named subprocess, which launches workers by executing commands on the host machine. The program name and arguments are taken directly from the caller's configuration rather than operator-controlled settings. An authenticated caller with write role in any namespace can configure a worker deployment version to run arbitrary commands immediately on the Worker Service host under the server process's account. Because this process holds cluster-wide persistence credentials and TLS material, the impact extends beyond the caller's namespace. The subprocess provider is included in official binaries and container images for affected versions. The vulnerability is exploitable if the per-namespace dynamic configuration setting workercontroller.compute_providers.enabled is unset (default) or includes subprocess, as the allowlist check is skipped or permits subprocess. The affected Temporal Server versions are >=1.31.0 and <1.31.3. Authorization must be enabled for the namespace boundary to be meaningful; deployments without authorization grant unrestricted access and thus are not affected in the same way. The setting workercontroller.enabled does not mitigate this vulnerability and defaults to false, so it does not prevent exploitation.

An authenticated user with write permissions in a single namespace can execute arbitrary OS commands on the host running the Worker Service. Since the Worker Service process holds cluster-wide persistence credentials and TLS materials, this can lead to compromise of the entire cluster beyond the user's namespace. The execution is immediate and does not require special request sequences or scaling events. This vulnerability can lead to full cluster compromise under the server process's privileges.

No official patch or fix is currently documented. To mitigate, ensure that the per-namespace dynamic configuration setting workercontroller.compute_providers.enabled is set to a denylist or explicitly excludes the subprocess compute provider, as the default unset value permits it. Deployments without authorization configured are not affected in the same way but lack namespace boundaries. Monitor and audit worker deployment versions for any use of the subprocess compute provider. Consider restricting or disabling the subprocess provider until a fix is available. Check vendor advisories regularly for updates or official patches.