| Package | Affected versions | Patched versions |
|---|---|---|
| open-webui | < 0.9.0 | 0.9.0 |
| open webui | < 0.9.0 | 0.9.0 |
Socket.IO collaborative document editing handler:
backend/open_webui/socket/main.py (lines 667-721, ydoc:document:update handler)Current main branch and likely all versions with collaborative note editing.
The ydoc:document:update Socket.IO event handler checks whether the sender is a member of the document's Socket.IO room (line 678) but does not verify that the sender has write permission. Users with read-only access join the document room via ydoc:document:join, which only requires read permission (line 520). Once in the room, the user can emit ydoc:document:update events that modify the in-memory Yjs document state and are broadcast to all other collaborators in real time.
The document_save_handler (line 600) correctly checks write permission before persisting to the database, so the attacker cannot directly save changes. However, the tampered content is visible to all collaborators, and if any user with write access saves the document, the injected content is persisted.
# ydoc:document:update handler (line 667) — only checks room membership, not write permission
async def on_document_update(sid, data):
document_id = normalize_document_id(data.get('document_id', ''))
# ...
room = f'doc_{document_id}'
if room not in sio.rooms(sid): # Room membership check only
return
# Applies update to Yjs state and broadcasts to all users
YDOC_MANAGER.apply_update(document_id, update)
await sio.emit('ydoc:document:update', {...}, room=room, skip_sid=sid)
Compare with ydoc:document:join (line 520) which checks permission:
# Only checks READ permission — so read-only users join the room
if not has_access(user_id, type, id, 'read', db=db):
return
| Metric | Value | Rationale |
|---|---|---|
| Attack Vector | Network (N) | Exploited remotely via Socket.IO events |
| Attack Complexity | Low (L) | No special conditions; attacker emits a standard Socket.IO event |
| Privileges Required | Low (L) | Requires a valid user account with read access to the shared note |
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free| User Interaction | None (N) | Modifications appear in real time without victim action; however, persistence requires a write-access user to save |
| Scope | Unchanged (U) | Impact is within the collaborative document context |
| Confidentiality | None (N) | No data disclosure beyond what read access already provides |
| Integrity | Low (L) | In-memory document state is modified and broadcast; persistence is indirect (requires another user to save) |
| Availability | Low (L) | Collaborative editing session can be disrupted with invalid content |
ydoc:document:join — the server checks read permission and adds User B to the document room.ydoc:document:update with a crafted Yjs update payload via the Socket.IO connection (bypassing any frontend read-only enforcement).This advisory covers read-only users modifying collaborative notes over Socket.IO. Two handlers were affected, both fixed in v0.9.0:
ydoc:document:update — checked only room membership, not write permission, so a read-only collaborator could inject in-memory document updates broadcast to other collaborators (persistence indirect). @Classic298.document_save_handler — checked permission='read' while persisting via Notes.update_note_by_id, so a read-only collaborator could persist note changes directly. Reported by @hacnhoOne CVE for the consolidated advisory.