CVE-2026-65655 in UI Server
Summary
by MITRE • 08/11/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/11/2026
This vulnerability represents a critical security flaw in Temporal UI Server's OAuth authentication implementation that arises from improper handling of cookie security attributes when traffic flows through reverse proxies. The issue occurs specifically when browser-facing TLS termination happens at a reverse proxy while the callback is forwarded to the Temporal UI Server over HTTP connections. This architectural pattern creates a fundamental mismatch in how authentication cookies are configured, as the server derives the Secure attribute for authentication cookies from the underlying HTTP connection between proxy and server rather than from the original HTTPS client connection. This misconfiguration allows the system to issue access-token cookies and refresh-token cookies with the Secure flag set to false, even though users authenticated through HTTPS connections.
The technical flaw stems from a lack of proper TLS termination awareness within the authentication cookie generation process. When OAuth flows are processed through a reverse proxy architecture, the Temporal UI Server should recognize that the original client connection was secured over TLS and maintain appropriate security attributes in issued cookies. However, the system incorrectly evaluates the cookie security properties based on the internal proxy-to-server HTTP connection rather than the external HTTPS boundary where authentication actually occurred. This behavior creates a window of vulnerability where session tokens can be transmitted over unencrypted channels while still maintaining their functional validity.
The operational impact of this vulnerability is significant as it enables credential exposure under specific attack conditions that require coordinated exploitation efforts. An attacker would need to simultaneously control victim browsing behavior and network traffic for the UI hostname, specifically steering traffic through HTTP rather than HTTPS while the victim's credentials remain active. The attack vector requires the victim to visit attacker-controlled content during an active session, with the attacker then manipulating DNS or network routing to redirect traffic for the UI hostname to an HTTP server they control. This scenario demonstrates a sophisticated attack chain that leverages both social engineering and network manipulation techniques.
The vulnerability aligns with CWE-614, which addresses the improper handling of security-sensitive cookies, and reflects patterns found in ATT&CK technique T1566 related to credential harvesting through malicious websites. The attack path requires multiple conditions to succeed including the victim's active session state, attacker control over DNS resolution or network routing for the UI hostname, and the ability to intercept same-site HTTP requests that contain the vulnerable cookies. While a malicious website alone cannot directly access these cookies due to browser SameSite protections, the combination of compromised network routing and active session tokens creates a realistic threat scenario.
Effective mitigations include implementing proper HSTS policies to prevent downgrade attacks, ensuring TLS re-encryption occurs between proxy and Temporal UI Server, and configuring reverse proxies to properly forward security headers including forwarded proto information. Organizations should also implement blocking mechanisms for HTTPS-only warnings and ensure that all connections between reverse proxies and backend servers maintain appropriate TLS encryption. Additionally, the system configuration should be reviewed to ensure that authentication cookies are generated with correct security attributes regardless of proxy architecture, with the Secure flag being determined by the original client connection security rather than internal network transport methods.
The vulnerability demonstrates how modern web architectures involving reverse proxies can introduce subtle security issues when underlying assumptions about connection security aren't properly maintained throughout the authentication flow. This class of vulnerability commonly occurs in microservices and cloud-native deployments where TLS termination happens at multiple layers, requiring careful attention to how security context is preserved and propagated through complex network topologies. Proper implementation requires strict adherence to security best practices including maintaining consistent security boundaries across all architectural components and ensuring that session management logic properly accounts for the actual connection security properties rather than internal transport characteristics.