CVE-2026-65655: Temporal UI Server Information Disclosure

CVE-2026-65655 Overview

CVE-2026-65655 affects Temporal UI Server when OAuth authentication is enabled behind a TLS-terminating reverse proxy. The server derives the Secure attribute of authentication cookies from the proxy-to-server connection rather than the browser-facing connection. When the proxy forwards the OAuth callback over plaintext HTTP, Temporal UI Server issues access-token and refresh-token cookies without the Secure flag, even though the user completed login over HTTPS. This weakness maps to [CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute].

Critical Impact
An attacker able to hijack the UI hostname, force a plaintext HTTP fallback, and read a same-site cleartext request may recover a live access or refresh token and replay it within the victim's assigned permissions.

Affected Products

Temporal UI Server versions prior to v2.53.1
Deployments where browser-facing TLS terminates at a reverse proxy forwarding to Temporal UI Server over HTTP
OAuth-enabled Temporal UI Server configurations that rely on the identity provider for refresh tokens

Discovery Timeline

2026-08-11 - CVE-2026-65655 published to NVD
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-65655

Vulnerability Analysis

Temporal UI Server sets authentication cookies during the OAuth callback handler. The Secure attribute is decided using the scheme of the incoming HTTP request received by the UI Server process. In a common deployment topology, a reverse proxy (for example, NGINX, HAProxy, or an ingress controller) terminates TLS at the network edge and forwards decrypted requests to the backend over HTTP.

Under this topology, the UI Server observes http:// on the callback request even though the browser negotiated https:// with the proxy. The cookie writer therefore omits the Secure flag. The browser then treats the access-token cookie, and any refresh-token cookie issued when the identity provider returns one, as eligible for transmission over cleartext HTTP.

Root Cause

The defect resides in the cookie-issuance path invoked from the OAuth callback route. The Secure flag is derived from c.Request().TLS != nil (or equivalent scheme detection) on the connection between the proxy and the UI Server, rather than from the original browser-to-proxy scheme. Standard forwarded-header inspection (X-Forwarded-Proto) is not honored in the decision, so a legitimate HTTPS session results in a non-Secure cookie.

Attack Vector

Exploitation is conditional and requires an active network-position attacker. The attacker must: (1) steer traffic for the UI hostname toward attacker infrastructure, (2) prevent the browser's HTTPS connection from succeeding, (3) serve the same hostname over plaintext HTTP, and (4) induce or observe a later same-site request that carries the non-Secure cookie. A passive observer of a normal TLS session cannot recover the credential, and a malicious third-party site alone cannot read the cookie. HSTS, browser HTTPS-only mode, or TLS re-encryption between the proxy and UI Server each defeat the demonstrated path.

// Patched signature - server/auth/auth.go
// SetUser now accepts an explicit secure flag rather than
// inferring it from the proxy-to-server connection scheme.
func SetUser(c echo.Context, user *User, secure bool) error {
    if user.OAuth2Token == nil {
        return errors.New("no OAuth2Token")
    }
    // ...
}

Source: GitHub ui-server Commit 8876b80

Detection Methods for CVE-2026-65655

Indicators of Compromise

Temporal UI Server responses whose Set-Cookie headers for authentication cookies omit the Secure attribute despite an HTTPS browser session
OAuth callback traffic between the reverse proxy and Temporal UI Server observed on plaintext HTTP
Unexpected reuse of Temporal access or refresh tokens from source IPs or user agents that differ from the original authenticated session

Detection Strategies

Inspect proxy access logs for callback URIs terminating at the UI Server over HTTP rather than HTTPS or mTLS
Enumerate live Temporal UI Server cookies from a browser session and confirm the Secure attribute is present on all authentication cookies
Correlate identity provider token issuance events with UI Server session creation to identify tokens replayed outside the original session context

Monitoring Recommendations

Alert on any Temporal UI Server deployment reachable over http:// from within the trust boundary of the reverse proxy
Track versions of ui-server deployed across environments and flag anything below v2.53.1
Monitor identity provider logs for refresh-token reuse or rotation-family violations tied to Temporal service principals

How to Mitigate CVE-2026-65655

Immediate Actions Required

Upgrade Temporal UI Server to v2.53.1 or v2.53.2, which corrects the cookie Secure derivation
Enable TLS re-encryption between the reverse proxy and Temporal UI Server so the backend observes an HTTPS scheme
Enforce HSTS on the UI hostname with a preload-eligible policy to eliminate plaintext fallback

Patch Information

The fix ships in the Temporal ui-server v2.53.1 release with a follow-up in the v2.53.2 release. Relevant changes include commit 7b9ff53, commit 821cf59, and commit 8876b80. The reference implementation change is tracked in ui Pull Request #3806.

Workarounds

Terminate TLS directly at Temporal UI Server, bypassing the plaintext proxy hop
Configure the reverse proxy to forward the OAuth callback over HTTPS to the UI Server backend
Deploy HSTS with includeSubDomains and preload on the UI hostname to block plaintext downgrade
Restrict browser access to modern clients that honor HTTPS-only warnings for the hostname

bash

# NGINX example - re-encrypt proxy-to-backend traffic so Temporal UI Server
# sees an HTTPS scheme and issues cookies with the Secure attribute.
server {
    listen 443 ssl;
    server_name temporal.example.com;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    location / {
        proxy_pass         https://temporal-ui-backend:8443;
        proxy_ssl_verify   on;
        proxy_set_header   Host              $host;
        proxy_set_header   X-Forwarded-Proto https;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
    }
}