CVE-2026-44564: Open webui Read-Only Open WebUI Users Can Vulnerability

MODERATE
Advisory Identifier: GHSA-vrfh-rj4q-rmhr
CVSS 5.4
CWE-863
Published
Advisory Summary

CVE-2026-44564 is a MODERATE (CVSS 5.4) read-only open webui users can vulnerability (CWE-863: Incorrect Authorization) affecting Open webui libraries in the PyPI ecosystem. The issue involves read-only open webui users can modify collaborative documents via socket.io. Remediation is available by upgrading affected packages to version 0.9.0.

CVE-2026-44564 at a Glance

CVE Identifier CVE-2026-44564
GHSA Identifier GHSA-vrfh-rj4q-rmhr
Severity MODERATE
CVSS v3.1 Base Score 5.4
CWE Classification CWE-863: Incorrect Authorization
Affected Product Open webui
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 5.4

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity Low (I:L)
Availability Low (A:L)

How to Fix CVE-2026-44564

To remediate this vulnerability, upgrade all affected Open webui dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

open-webui fixed: 0.9.0
pip install open-webui>=0.9.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show open-webui

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-44564, inspect your installed packages using pip:

pip show open-webui

Analyze the terminal output to locate any version of Open webui in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.9.0), your application is affected.

Note: The pip show open-webui command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-863: Incorrect Authorization, where the product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. In Open webui, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

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

CVE-2026-44564 Affected Open webui Versions

1 component(s)
Fixed Versions:
0.9.0
Product / Package Ecosystem Affected Versions Fixed Version
open-webui
PyPI
< 0.9.0
0.9.0

References

Frequently Asked Questions

What is CVE-2026-44564?
CVE-2026-44564 is a security vulnerability in Open webui involving Read-Only Open WebUI Users Can Modify Collaborative Documents via Socket.IO under CWE-863: Incorrect Authorization.
Which Open webui versions are affected?
Affected versions include releases prior to 0.9.0 across affected packages: open-webui.
What version fixes CVE-2026-44564?
Upgrading to 0.9.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is open-webui affected?
Yes, open-webui is affected in releases prior to 0.9.0. Upgrade your dependency to 0.9.0 or later.
What is the CVSS score of CVE-2026-44564?
CVE-2026-44564 has a CVSS v3.1 base score of 5.4 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L.
What CWE is associated with CVE-2026-44564?
CVE-2026-44564 is classified under CWE-863: Incorrect Authorization (The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.).
How can I check PyPI dependencies for CVE-2026-44564?
Run the dependency tree command: 'pip show open-webui'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-vrfh-rj4q-rmhr",
  "modified" : "2026-06-09T11:52:49Z",
  "published" : "2026-05-08T20:00:57Z",
  "aliases" : [ "CVE-2026-44564" ],
  "summary" : "Read-Only Open WebUI Users Can Modify Collaborative Documents via Socket.IO",
  "details" : "# Read-Only Users Can Modify Collaborative Documents via Socket.IO\n\n## Affected Component\n\nSocket.IO collaborative document editing handler:\n- `backend/open_webui/socket/main.py` (lines 667-721, `ydoc:document:update` handler)\n\n## Affected Versions\n\nCurrent main branch and likely all versions with collaborative note editing.\n\n## Description\n\nThe `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.\n\nThe `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.\n\n```python\n# ydoc:document:update handler (line 667) — only checks room membership, not write permission\nasync def on_document_update(sid, data):\n    document_id = normalize_document_id(data.get('document_id', ''))\n    # ...\n    room = f'doc_{document_id}'\n    if room not in sio.rooms(sid):  # Room membership check only\n        return\n    # Applies update to Yjs state and broadcasts to all users\n    YDOC_MANAGER.apply_update(document_id, update)\n    await sio.emit('ydoc:document:update', {...}, room=room, skip_sid=sid)\n```\n\nCompare with `ydoc:document:join` (line 520) which checks permission:\n\n```python\n# Only checks READ permission — so read-only users join the room\nif not has_access(user_id, type, id, 'read', db=db):\n    return\n```\n\n## CVSS 3.1 Breakdown\n\n| Metric | Value | Rationale |\n|--------|-------|-----------|\n| Attack Vector | Network (N) | Exploited remotely via Socket.IO events |\n| Attack Complexity | Low (L) | No special conditions; attacker emits a standard Socket.IO event |\n| Privileges Required | Low (L) | Requires a valid user account with read access to the shared note |\n| User Interaction | None (N) | Modifications appear in real time without victim action; however, persistence requires a write-access user to save |\n| Scope | Unchanged (U) | Impact is within the collaborative document context |\n| Confidentiality | None (N) | No data disclosure beyond what read access already provides |\n| Integrity | Low (L) | In-memory document state is modified and broadcast; persistence is indirect (requires another user to save) |\n| Availability | Low (L) | Collaborative editing session can be disrupted with invalid content |\n\n## Attack Scenario\n\n1. User A creates a note and shares it with User B with **read** permission.\n2. User B opens the note, which triggers `ydoc:document:join` — the server checks read permission and adds User B to the document room.\n3. User B emits `ydoc:document:update` with a crafted Yjs update payload via the Socket.IO connection (bypassing any frontend read-only enforcement).\n4. The server applies the update to the Yjs document state and broadcasts it to all collaborators.\n5. User A sees the injected content appear in their editor in real time.\n6. 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.\n\n## Impact\n\n- Read-only users can inject, modify, or delete content in collaborative documents\n- Modifications are broadcast in real time to all collaborators, causing confusion or disruption\n- If a write-access user saves (including autosave), the tampered content is permanently persisted\n- Undermines the read/write permission model for collaborative editing\n\n## Preconditions\n\n- Attacker must have a valid user account with read access to a shared note\n- 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)\n\n## Consolidation\n\nThis advisory covers read-only users modifying collaborative notes over Socket.IO. Two handlers were affected, both fixed in v0.9.0:\n\n- `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.\n- `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 \n\nOne CVE for the consolidated advisory.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "open-webui"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.9.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 0.8.12"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/open-webui/open-webui/security/advisories/GHSA-vrfh-rj4q-rmhr"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-44564"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/open-webui/open-webui"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-863" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-08T20:00:57Z",
    "nvd_published_at" : "2026-05-15T20:16:48Z"
  }
}