CVE-2026-59219: Session Revocation Bypass in Open WebUI Real-Time Endpoints

Open WebUI is an extensible, self-hosted AI interface designed to interact with various large language models. The platform exposes standard REST HTTP routes alongside asynchronous communication layers, such as Socket.IO and WebSocket terminal interfaces, to handle real-time collaboration, chat streams, and shell executions. The exposure of administrative shell interfaces and interactive workspaces makes real-time channels high-value targets.

This architecture exposes a session-management vulnerability classified as CWE-613 (Insufficient Session Expiration). While standard HTTP requests validate user sessions against a central stateful blacklist, real-time protocols fail to perform the same validation. This security gap leaves active connections open to exploitation by session reuse.

The core of the vulnerability lies in the transport-protocol discrepancy. Because the real-time endpoints do not verify token state, an attacker possessing a revoked JWT can connect and operate within the context of a logged-out user. The failure to invalidate these connections undermines the platform's security boundaries and neutralizes user-initiated signouts.

To understand the vulnerability, it is necessary to examine how session revocation works in Open WebUI. The application uses JSON Web Tokens (JWT) for authentication. When configured with a Redis backend, the platform supports stateful session revocation. A user sign-out or OIDC back-channel logout records a token identifier blacklist or a user-specific revocation timestamp directly into the Redis database.

Standard HTTP endpoints enforce these revocation entries during routing. Each request executes a dependency function named get_current_user inside backend/open_webui/utils/auth.py. This function decodes the token, extracts the unique token identifier (jti) and user ID, and checks Redis via the is_valid_token helper. If Redis contains a matching revocation record, the application terminates the HTTP connection and returns a 401 Unauthorized status.

In contrast, the asynchronous WebSocket and Socket.IO routers handle connections using separate handshakes. These pathways historically omitted the stateful verification check. Instead of calling is_valid_token, they only called decode_token, which performs offline cryptographic signature and expiration verification. Because the real-time routes never consulted the Redis database, the stateful revocation entries were ignored entirely, allowing revoked tokens to authenticate successfully.

The architectural flaw stems from how dependencies were resolved in asynchronous layers. The original is_valid_token helper function depended on receiving an HTTP Request object to locate the application state and reference the Redis client. WebSocket and Socket.IO handshakes do not process standard HTTP Request wrappers, rendering the original validator incompatible with these communication contexts.

The vulnerable execution flow inside backend/open_webui/socket/main.py verified incoming connections strictly through decode_token:

# Vulnerable handshake logic
data = decode_token(auth['token'])
if data is not None and 'id' in data:
    user = await Users.get_user_by_id(data['id'])

To address this limitation, the patch refactored is_valid_token to accept an optional, direct redis client instance rather than requiring the HTTP request object. The updated validator can now run in non-HTTP routing contexts, retrieving the database connection from the ASGI scope structure:

# Patched authentication logic
scope = (environ or {}).get('asgi.scope') or {}
fastapi_app = scope.get('app')
redis = getattr(getattr(fastapi_app, 'state', None), 'redis', None) or REDIS
data = decode_token(auth['token'])
if data is not None and 'id' in data and await is_valid_token(data, redis):
    user = await Users.get_user_by_id(data['id'])

This design allows the Socket.IO handler to access the application's shared Redis instance via FastAPI application state, enabling consistent revocation checks across both HTTP and WebSocket interfaces.

Exploitation of this vulnerability requires an attacker to obtain a valid JWT belonging to the target user. An attacker may extract this token from browser local storage, proxy server logs, or compromised network infrastructure. The session remains usable even after the legitimate user logs out of the platform or resets their password.

After the target user initiates a sign-out, the server registers the revocation in Redis. However, the attacker can initiate a Socket.IO connection at /ws/socket.io or open a terminal WebSocket at /ws/terminals/{server_id}. Because the backend checks only the token signature and the hardcoded expiration claim, the handshake completes successfully, bypassing the security controls.

Once the connection is established, the attacker can execute real-time operations, join collaborative notes workspaces, and interact directly with system shell environments via the terminal proxy. The following diagram illustrates the different handling of HTTP and WebSocket authentication requests:

The security impact of CVE-2026-59219 is classified as high, with a CVSS v3.1 base score of 7.1. The attack vector is Network, attack complexity is Low, privileges required are Low, and user interaction is None. While the vulnerability requires the attacker to hold an authenticated token, the inability of the system to invalidate sessions significantly extends the post-revocation attack surface.

An unauthorized actor maintains full read access to real-time chat operations, model integrations, and workspace updates. If the platform is configured with terminal proxy services, the attacker can run commands directly on the host system, potentially resulting in complete compromise of the underlying container or host infrastructure.

The vulnerability is not currently cataloged in the CISA Known Exploited Vulnerabilities registry, and there is no evidence of active exploitation in the wild. The EPSS score is recorded at 0.00305, representing a low immediate statistical likelihood of exploitation, though systems exposed to untrusted networks face ongoing risk.

To remediate CVE-2026-59219, deploy Open WebUI version 0.10.0 or higher. This version implements consistent verification by injecting is_valid_token checks across standard handshakes and WebSocket routers. Update existing container deployments by pulling the updated images from the official container registry.

If immediate deployment of the patch is not possible, apply temporary mitigations to limit the exposure window. Reduce the token lifetime by lowering the value of the JWT_EXPIRY environment variable. This action shortens the maximum validity period of the token, ensuring that any hijacked sessions expire quickly after a user logout.

Additionally, turn off the terminal application service within the Open WebUI settings interface if host terminal proxy capability is not strictly required. Restricting administrative WebSocket connections reduces the severity of the exploit paths, ensuring that a compromised token cannot be used to perform host-level command execution.