temporal‑proxy versions 0.2.0 through 0.8.0 allow a user authorized for one namespace to decrypt payloads that were encrypted for another namespace. The proxy selects the decryption key solely from an identifier embedded in the ciphertext, ignoring the namespace of the request. As a result, an attacker who can obtain an encrypted payload from namespace A and who has write or request access to namespace B can use the proxy to decrypt the data and read the contents. The vulnerability does not let an attacker modify ciphertext or generate new encrypted data that they could not already retrieve; it only permits reading data that the attacker could already access if they had write privileges in the target namespace.

The affected product is Temporal Technologies, Inc.’s temporal‑proxy component, versions 0.2.0 up to but not including 0.9.0. The issue is present in every release from 0.2.0 through 0.8.0. The vulnerability applies whenever payload encryption is enabled, regardless of whether namespaces share a default key or each has its own key, because a single instance holds every key it is configured to use. Users running these versions on a Temporal cluster that employs multiple namespaces, or that expose the codec server’s /decode endpoint, are at risk.

The CVSS score of 6 indicates a moderate severity, and the EPSS score of < 1% suggests a low likelihood of exploitation at this time. The vulnerability is not listed in CISA’s KEV catalog. The likely attack vector is remote API interaction with the temporal‑proxy service; an attacker must be authenticated to the proxy with permission to access a target namespace and must have a means of obtaining an encrypted payload from another namespace, such as via disclosure or an existing read operation. Once the proxy is configured with permissive mode or the codec server is enabled, the attacker can submit the payload to the /decode endpoint to obtain its plaintext. Mitigation requires upgrading to a fixed release or reconfiguring the environment.