# Read-Only Users Can Modify Collaborative Documents via Socket.IO ## Affected Component Socket.IO collaborative document editing handler: - `backend/open_webui/socket/main.py` (lines 667-721, `ydoc:document:update` handler) ## Affected Versions Current main branch and likely all versions with collaborative note editing. ## Description 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. ```python # 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: ```python # 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 | 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 | | 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 | ## 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 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 @hacnho One CVE for the consolidated advisory.
# Read-Only Users Can Modify Collaborative Documents via Socket.IO ## Affected Component Socket.IO collaborative document editing handler: - `backend/open_webui/socket/main.py` (lines 667-721, `ydoc:document:update` handler) ## Affected Versions Current main branch and likely all versions with collaborative note editing. ## Description 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. ```python # 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: ```python # 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 | 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 | | 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 | ## 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 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 @hacnho One CVE for the consolidated advisory.
Update open-webui to 0.9.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanRead-Only Open WebUI Users Can Modify Collaborative Documents via Socket.IO affects open-webui (pip). Severity is medium. # Read-Only Users Can Modify Collaborative Documents via Socket.IO ## Affected Component Socket.IO collaborative document editing handler: - `backend/open_webui/socket/main.py` (lines 667-721, `ydoc:document:update` handler) ## Affected Versions Current main branch and likely all versions with collaborative note editing. ## Description 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. ```python # 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: ```python # 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 | 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 | | 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 | ## 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 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 @hacnho One CVE for the consolidated advisory.
AI coding agents often install or upgrade packages automatically in pip. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| open-webuipip | <=0.8.12 | 0.9.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate open-webui to 0.9.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanRead-Only Open WebUI Users Can Modify Collaborative Documents via Socket.IO affects open-webui (pip). Severity is medium. # Read-Only Users Can Modify Collaborative Documents via Socket.IO ## Affected Component Socket.IO collaborative document editing handler: - `backend/open_webui/socket/main.py` (lines 667-721, `ydoc:document:update` handler) ## Affected Versions Current main branch and likely all versions with collaborative note editing. ## Description 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. ```python # 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: ```python # 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 | 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 | | 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 | ## 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 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 @hacnho One CVE for the consolidated advisory.
AI coding agents often install or upgrade packages automatically in pip. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| open-webuipip | <=0.8.12 | 0.9.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard