CVE-2026-54022 Overview
CVE-2026-54022 is an authorization bypass vulnerability in Open WebUI, a self-hosted artificial intelligence platform designed to operate entirely offline. The flaw resides in the ydoc:document:join Socket.IO handler, which checks note ownership only when the document_id begins with note: (colon prefix). Because the YdocManager storage layer normalizes all document IDs by replacing colons with underscores, an attacker can join a document room using note_<id> and bypass the ownership check while accessing the same underlying Yjs document. The server returns the full document state, exposing private note contents belonging to other users. The issue is fixed in Open WebUI version 0.8.11.
Critical Impact
An authenticated attacker can read arbitrary users' private notes by exploiting inconsistent document ID normalization between the authorization check and the storage layer.
Affected Products
- Open WebUI versions prior to 0.8.11
- Self-hosted Open WebUI deployments using Socket.IO collaborative document features
- Yjs document collaboration component within Open WebUI
Discovery Timeline
- 2026-06-23 - CVE-2026-54022 published to NVD
- 2026-06-25 - Last updated in NVD database
Technical Details for CVE-2026-54022
Vulnerability Analysis
The vulnerability is an authorization bypass [CWE-706: Use of Incorrectly-Resolved Name or Reference] in Open WebUI's collaborative document handling. Open WebUI exposes a Socket.IO event named ydoc:document:join that allows clients to subscribe to a Yjs document room and receive its synchronized state. The handler enforces ownership validation only when the supplied document_id matches the prefix note:. The storage layer, however, applies a transformation that replaces every colon with an underscore via document_id.replace(":", "_") before resolving the underlying document. This produces two distinct identifiers that map to the same backing object: the canonical note:<id> form and the alternate note_<id> form. An attacker who supplies the underscore form skips the ownership branch entirely while still reaching the same Yjs document, which returns the complete document state to the joining client. The exploitation requires only valid authenticated session access to the Socket.IO endpoint.
Root Cause
The root cause is inconsistent identifier normalization between the authorization layer and the storage layer. The authorization check operates on raw input, while the storage layer canonicalizes input by replacing colons with underscores. Multiple distinct inputs therefore resolve to the same protected resource without passing through the same access gate.
Attack Vector
The attack vector is network-based and requires low privileges. An authenticated user connects to the Open WebUI Socket.IO endpoint and emits a ydoc:document:join event with a payload of the form note_<target_document_id>. Because the handler only validates ownership when the identifier starts with note:, the underscore-prefixed identifier bypasses the check. The server resolves the document, joins the attacker to the room, and emits the full Yjs document state, leaking private note contents.
No verified public exploit code is available. See the GitHub Security Advisory GHSA-8788-j68r-3cgh for the official technical write-up.
Detection Methods for CVE-2026-54022
Indicators of Compromise
- Socket.IO ydoc:document:join events containing document_id values that begin with note_ instead of the canonical note: prefix.
- Document room joins by user accounts that do not own the referenced note.
- Unexpected outbound Yjs document state payloads to clients not previously associated with a given document.
Detection Strategies
- Inspect application logs for ydoc:document:join handler invocations and correlate the supplied document_id against the authenticated user's note ownership records.
- Add server-side logging that records both the raw document_id and its normalized form, then alert on mismatches that result in successful joins.
- Review historical Socket.IO traffic for the pattern note_ followed by a hexadecimal or UUID-style identifier originating from non-owner sessions.
Monitoring Recommendations
- Monitor authentication and session activity on the Open WebUI Socket.IO endpoint for clients joining many distinct document rooms in quick succession.
- Track anomalous read volumes on the Yjs document store, especially document fetches that are not preceded by a UI-driven open action.
- Generate alerts when a single account joins documents owned by multiple unrelated users within a short window.
How to Mitigate CVE-2026-54022
Immediate Actions Required
- Upgrade Open WebUI to version 0.8.11 or later, which contains the official fix.
- Restrict network access to the Open WebUI Socket.IO endpoint to trusted users until the upgrade is complete.
- Audit existing notes for sensitive content and rotate any secrets that may have been stored in shared or private notes.
Patch Information
The vendor fixed CVE-2026-54022 in Open WebUI 0.8.11. The fix normalizes document_id consistently before performing the ownership check, eliminating the divergence between the authorization layer and the YdocManager storage layer. Full details are documented in the Open WebUI Security Advisory GHSA-8788-j68r-3cgh.
Workarounds
- If upgrading is not immediately possible, place Open WebUI behind a reverse proxy that filters Socket.IO payloads containing document_id values starting with note_.
- Disable the collaborative notes feature or revoke Socket.IO access for untrusted authenticated users until the patched version is deployed.
- Restrict Open WebUI to trusted internal networks and enforce strong session controls to limit the population of users able to reach the vulnerable handler.
# Upgrade Open WebUI to the patched release
pip install --upgrade open-webui==0.8.11
# Or, for Docker deployments
docker pull ghcr.io/open-webui/open-webui:0.8.11
docker stop open-webui && docker rm open-webui
docker run -d --name open-webui \
-p 3000:8080 \
-v open-webui:/app/backend/data \
ghcr.io/open-webui/open-webui:0.8.11
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

