temporal-proxy payload decryption is not bound to the request namespace
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 0.9.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
temporal-proxy 0.2.0 through 0.8.0 does not bind encrypted payloads to the namespace they were encrypted for. When payload encryption is enabled, the proxy chooses the decryption key by an identifier stored in the payload rather than by the namespace of the request, and nothing in the ciphertext records that namespace. A caller whom the proxy authorizes only for namespace B, and who has obtained an encrypted payload from namespace A, can therefore have the proxy decrypt it. In 0.8.0, the caller can submit the payload to the codec server's /decode endpoint. In every affected version, a caller who can also write to namespace B on the Temporal server directly can place the payload there and read it back through the proxy. This holds whether namespaces share the default key or each has its own, because a single proxy holds every key it is configured with. The issue does not give the attacker encrypted payloads they could not already obtain, and does not allow encrypted payloads to be modified.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- github.com/temporalio/temporal-proxy
From 0.2.0 · fixed in 0.9.0