EUVD-2026-56924
GHSA-c7mm-29xf-mmqp
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AC:H reflects the multi-step traffic-steering prerequisite beyond network access; C:L and I:L reflect limited credential exposure within victim's existing permissions.
Primary rating from Vendor (temporal).
CVSS VectorVendor: temporal
Lifecycle Timeline
3DescriptionCVE.org
When OAuth authentication is enabled and browser-facing TLS terminates at a reverse proxy that forwards the callback to Temporal UI Server over HTTP, affected versions derive authentication-cookie Secure attributes from the proxy-to-server connection. Temporal UI Server can therefore issue access-token cookies, and refresh-token cookies when provided by the identity provider, without Secure even though the browser completed login over HTTPS.
A victim who visits attacker-controlled content while a credential remains live may expose that credential only if the attacker can also steer traffic for the UI hostname, prevent the browser's HTTPS connection from succeeding, serve the hostname over HTTP, and read a later same-site plaintext request. A malicious website alone cannot read the cookie, and passive observation of a successful TLS connection is insufficient. Effective HSTS, a blocking HTTPS-only warning, or TLS re-encryption between the proxy and Temporal UI Server prevents the demonstrated disclosure path.
A recovered credential may be replayed within the victim's assigned permissions. Refresh-token replay additionally depends on the identity provider's issuance, expiry, rotation, and reuse-detection behavior.
AnalysisAI
Temporal UI Server versions 2.7.0 through 2.53.1 incorrectly derive the Secure attribute for OAuth authentication cookies from the proxy-to-server connection rather than the browser-facing connection, causing access-token and refresh-token cookies to be issued without Secure when TLS terminates at a reverse proxy forwarding over HTTP. An attacker who can additionally redirect browser traffic for the UI hostname away from HTTPS - beyond merely serving attacker-controlled content - can potentially intercept a live credential transmitted in a plaintext HTTP request. No public exploit code exists and CISA KEV does not list this vulnerability; the SSVC assessment confirms exploitation is currently none and the attack is not automatable, consistent with the very low CVSS 4.0 score of 2.3.
Technical ContextAI
Temporal UI Server is a Go-based web frontend for the Temporal workflow orchestration platform, using the Echo framework and OIDC/OAuth2 for authentication. CWE-614 (Sensitive Cookie in HTTPS Session Without 'Secure' Attribute) is the root cause: the vulnerable code in server/auth/auth.go and server/route/auth.go sets Secure on cookies by evaluating c.Request().TLS != nil at cookie-issuance time. In a reverse-proxy TLS termination pattern - common in Kubernetes and cloud deployments where an ingress controller handles browser-facing HTTPS while forwarding HTTP internally - this field is always nil on the proxy-to-server leg, so Secure is set false. This means the browser may receive cookies without the Secure flag even though the user's session was established over HTTPS. The fix, introduced via commits 7b9ff533 and 821cf598 and released in v2.53.2, replaces the runtime TLS check with a startup-time parse of the configured OIDC callback URL scheme: if the callback URL uses https, Secure is set unconditionally, correctly reflecting the browser-facing transport regardless of the internal proxy-to-server connection.
RemediationAI
Upgrade Temporal UI Server to version 2.53.2 or later, which resolves the issue by deriving the cookie Secure attribute from the configured OIDC callback URL scheme rather than the runtime TLS state of the incoming request. The fix is confirmed via commits 7b9ff533fb51beba75497c0a192c66775c08f279 and 821cf598371353f1b579dfe1e87aeb3638b041d6 and the v2.53.2 release at https://github.com/temporalio/ui-server/releases/tag/v2.53.2. For deployments that cannot upgrade immediately, three compensating controls effectively eliminate the demonstrated disclosure path: (1) Enable HSTS on the reverse proxy or CDN for the UI hostname, which causes browsers to refuse HTTP connections - this is the strongest and lowest-disruption mitigation; (2) Configure TLS re-encryption between the reverse proxy and Temporal UI Server, so c.Request().TLS is non-nil and Secure is set correctly without any code change - this adds TLS overhead on the internal segment; (3) Enable an HTTPS-only browser warning or HSTS preloading for the UI domain, which prevents the plaintext fallback. None of these controls address the root misconfiguration in cookie issuance; they only block the exploitation path. Rotating OAuth credentials after upgrading is advisable if the deployment lacked all three compensating controls during the affected period.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today