CVE-2026-59219: Open WebUI JWT Revocation Bypass in Real-Time WebSocket Connections

Technical summary

The vulnerability stems from incomplete token validation logic in Open WebUI's WebSocket authentication layer. When processing Socket.IO connections and channel/note operations, the application uses a decode_token function without invoking the Redis-backed is_valid_token check that would detect revoked tokens. The decode_token function performs cryptographic verification of the JWT signature but does not cross-reference the token identifier against the revocation list stored in Redis. This gap affects multiple event handlers: the initial Socket.IO connection, user-join, join-channels, join-note, and terminal WebSocket first-message operations. Affected versions are 0.9.0 and later minor releases prior to 0.10.0, provided Redis is configured. The fix in 0.10.0 integrates the revocation check into the authentication flow for these handlers.

Business impact

This vulnerability allows former employees or users with revoked credentials to maintain unauthorized access to sensitive AI features, conversations, and platform functionality through WebSocket channels. In multi-tenant or collaborative environments, a revoked user can eavesdrop on or interfere with real-time communications, model queries, and note-sharing features. The impact is compounded if Open WebUI is used for confidential AI-assisted analysis or contains proprietary prompt engineering. Organizations cannot reliably enforce access removal through token revocation alone, requiring alternative measures (IP blocking, session termination at the database level) until patching. This creates operational friction and lingering security exposure.

Affected systems

Open WebUI from version 0.9.0 up to but not including 0.10.0 is affected, contingent on Redis being configured for token revocation tracking. The vulnerability does not affect installations without Redis backing. Deployments on any operating system or hosting platform running these affected versions with Redis enabled are at risk. Self-hosted instances are the primary concern; cloud-hosted or fully managed deployments depend on the operator's version and Redis configuration.

Exploitability

Exploitation requires an attacker to already possess a valid JWT from the target Open WebUI instance—typically acquired through credential compromise, insider access, or social engineering. Once obtained, the attacker can replay or use that token to establish WebSocket connections even after the token should have been revoked by an administrator. No authentication bypass is needed; the attacker leverages the missing revocation check to circumvent token lifecycle management. The attack is low-complexity to execute once a token is in hand but depends on the prerequisite of token acquisition. The CVSS score of 7.1 (HIGH) reflects that the attack requires prior authentication (PR:L) but delivers confidentiality impact and partial integrity risk without user interaction or availability degradation.

Remediation

Upgrade Open WebUI to version 0.10.0 or later. This version integrates the Redis-backed is_valid_token revocation check into all affected Socket.IO handlers, ensuring revoked tokens are rejected. Before patching, administrators should rotate all active tokens or keys as a compensating control and monitor WebSocket connection logs for anomalous user activity. If immediate patching is not possible, consider temporarily disabling real-time features or restricting access to the Open WebUI instance at the network perimeter.

Patch guidance

Update Open WebUI from 0.9.x to 0.10.0 or later. Verify the Redis configuration is active and functional post-upgrade to ensure the revocation mechanism operates correctly. Test token revocation workflows in a staging environment to confirm that revoked tokens are now properly rejected on Socket.IO reconnection attempts. Review release notes for 0.10.0 to identify any other improvements or breaking changes that may affect your deployment. Automated deployment pipelines should be updated to pin the minimum version to 0.10.0.

Detection guidance

Monitor WebSocket (Socket.IO) connection logs for sustained connections using tokens that were previously revoked or belong to deprovisioned users. Check application logs for decode_token calls that succeed without corresponding is_valid_token validations in the Redis layer. Use token introspection tools to list active JWT tokens and cross-reference them against your user directory to identify stale or invalid tokens still in use. In environments with centralized logging, search for repeated Socket.IO 'connect' or 'join-channels' events from revoked user accounts, particularly if timestamps cluster around or after the revocation date. Redis query logs may reveal queries for revocation-list lookups; absence of such queries during token validation is a red flag.

Why prioritize this

This vulnerability merits prompt but not emergency patching. It requires prior authentication and token possession (limiting the attacker pool) but enables effective persistence despite administrative revocation—a serious control bypass. Prioritize patching if your Open WebUI instance stores or processes sensitive data, supports multi-user collaboration, or has a history of insider threats. Organizations with strong network segmentation or those that rarely revoke tokens may deprioritize slightly, but the ease of exploitation once a token is compromised recommends treating this as a standard high-priority patch cycle item.

Risk score, explained

The CVSS 3.1 score of 7.1 reflects a HIGH severity due to the combination of network-accessible authentication bypass (AV:N, AC:L), requirement for valid credentials (PR:L), high confidentiality impact (C:H) from unauthorized access to real-time features and conversations, and minor integrity risk (I:L) if an attacker manipulates note or channel data. The absence of availability impact (A:N) and scope boundary (S:U) moderates the score. The reliance on prior token possession prevents a higher rating but the fundamental flaw—failure to honor revocation—is a significant access control defect.

Frequently asked questions