Read-Only Users Can Modify Collaborative Documents via Socket.IO

Affected Component

• backend/open webui/socket/main.py (lines 667-721, ydoc:document:update handler)

Affected Versions

Description

# 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)

# Only checks READ permission — so read-only users join the room
if not has access(user id, type, id, 'read', db=db):
  return

CVSS 3.1 Breakdown

Attack Scenario

1. User A creates a note and shares it with User B with read permission.
2. User B opens the note, which triggers ydoc:document:join — the server checks read permission and adds User B to the document room.
3. User B emits ydoc:document:update with a crafted Yjs update payload via the Socket.IO connection (bypassing any frontend read-only enforcement).
4. The server applies the update to the Yjs document state and broadcasts it to all collaborators.
5. User A sees the injected content appear in their editor in real time.
6. If User A saves the document (intentionally or via autosave), the tampered content is persisted to the database — User A's save passes the write permission check since User A is the owner.

Impact

• Read-only users can inject, modify, or delete content in collaborative documents
• Modifications are broadcast in real time to all collaborators, causing confusion or disruption
• If a write-access user saves (including autosave), the tampered content is permanently persisted
• Undermines the read/write permission model for collaborative editing

Preconditions

• Attacker must have a valid user account with read access to a shared note
• The note must be open for collaborative editing (at least one other user viewing it, or the attacker can wait for a write-access user to open and save)

Consolidation

• 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 @hacnho