Skip to content

GHSA-45m8-cpm2-3v65 CVE-2026-44553 PYSEC-2026-2697

Open WebUI: Stale Admin Role in Socket.IO Session Pool Enables Post-Demotion Cross-User Note Access

High PyPI
Severity
8.1 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.28%
Chance of exploitation in the next 30 days. Higher than 20.32% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-384 Session Fixation
CWE-613 Insufficient Session Expiration
CWE-863 Incorrect Authorization
Fix
0.9.0
Upgrade open-webui to this version or later

Description

Stale Admin Role in Socket.IO Session Pool Enables Post-Demotion Cross-User Note Access

Affected Component

Socket.IO session state and role-check callsites:

  • backend/open_webui/socket/main.py (lines 330-351, connect handler — role snapshotted into SESSION_POOL)
  • backend/open_webui/socket/main.py (lines 393-398, heartbeat handler — does not refresh role)
  • backend/open_webui/socket/main.py (line 538, ydoc:document:join — uses cached role for admin check)
  • backend/open_webui/socket/main.py (line 611, document_save_handler — uses cached role for admin check)
  • backend/open_webui/routers/users.py (lines 557-633, role update — does not invalidate SESSION_POOL)
  • backend/open_webui/routers/users.py (line 641, user delete — does not invalidate SESSION_POOL)

Affected Versions

Current main branch (commit 6fdd19bf1) and likely all versions with the collaborative document (Yjs) Socket.IO handlers.

Description

When a user connects via Socket.IO, the connect handler authenticates them via JWT and stores their user record (including role) in the in-memory SESSION_POOL dictionary keyed by session ID. The heartbeat handler keeps the session alive indefinitely but only refreshes the last_seen_at timestamp — never the role.

Role checks in the Yjs collaborative document handlers (ydoc:document:join, document_save_handler) consult the cached SESSION_POOL role rather than the database. Meanwhile, administrative role changes and user deletions do not iterate SESSION_POOL to disconnect affected sessions. As a result, a user whose admin role has been revoked retains admin privileges within their existing Socket.IO session for as long as they keep the connection alive (via automatic heartbeats).

HTTP endpoints are not affected — get_current_user at utils/auth.py refetches the user record from the database on every request. The gap is exclusive to the Socket.IO session cache.

# socket/main.py:330-351 — role snapshotted at connect time
async def connect(sid, environ, auth):
    user = None
    if auth and 'token' in auth:
        data = decode_token(auth['token'])
        if data is not None and 'id' in data:
            user = Users.get_user_by_id(data['id'])
        if user:
            SESSION_POOL[sid] = {
                'id': user.id,
                'role': user.role,   # ← snapshotted, never refreshed
                ...
            }

# socket/main.py:393-398 — heartbeat refreshes last_seen_at only
async def heartbeat(sid, data):
    user = SESSION_POOL.get(sid)
    if user:
        SESSION_POOL[sid] = {**user, 'last_seen_at': int(time.time())}
        # role is carried forward unchanged

# socket/main.py:538 — admin check against cached role
if user.get('role') != 'admin' and not has_access(user_id, 'note', note_id, 'read', db=db):
    return

Attack Scenario

  1. User B is an admin and has an active browser session with a live Socket.IO connection. SESSION_POOL[sid] records role='admin'.
  2. Admin A demotes User B to a regular user via POST /api/v1/users/{B_id}/update. The DB user.role becomes 'user'.
  3. No Socket.IO disconnect, no SESSION_POOL update, no token revocation event is triggered by the role change.
  4. User B's client continues sending heartbeat events every few seconds; these are accepted and only refresh last_seen_at.
  5. User B emits ydoc:document:join with document_id = 'note:<victim_note_id>' for any note they do not own.
  6. The handler at line 538 evaluates user.get('role') != 'admin' — returns False because SESSION_POOL still holds the stale admin role. Access check is bypassed, User B joins the document room, receives full document state and live updates.
  7. User B emits ydoc:document:update for the same note. The handler at line 611 performs the same cached-admin check, bypasses authorization, and persists attacker-controlled content to the victim's note via Notes.update_note_by_id.

The same bypass occurs if the user is deleted entirely (delete_user_by_id) — the deleted user retains admin privileges on their live socket until disconnection.

Impact

  • Read access to any user's notes after admin privileges have been revoked
  • Write access (content injection, overwrite) to any user's notes under the same conditions
  • The stale privilege is bounded only by the attacker's willingness to keep the Socket.IO connection alive; heartbeats extend the session indefinitely
  • Official admin demotion or user deletion gives a false sense of security — HTTP access is correctly revoked, but real-time collaborative access silently continues

Preconditions

  • Attacker must have an active Socket.IO connection established while they held admin role
  • Attacker must retain the Socket.IO session after demotion/deletion (trivial — just don't close the browser)

Affected versions

PyPI

PackageVulnerableFixed in
open-webui
< 0.9.0
0.9.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

open-webui PyPI → 0.9.0

pip
pip install --upgrade "open-webui>=0.9.0"
poetry
poetry add "open-webui>=0.9.0"
uv
uv add "open-webui>=0.9.0"

Severity breakdown

CVSS 3.1 8.1

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

Weakness

CWE-384: Session Fixation

Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.

How to prevent it
  • Architecture and Design: Invalidate any existing session identifiers prior to authorizing a new user session.
  • Architecture and Design: For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again.
  • Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

CWE-613: Insufficient Session Expiration

According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."

How to prevent it
  • Implementation: Set sessions/credentials expiration date.

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 to prevent it
  • Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
  • Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
  • System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-wvm9-9g5j-623f
Open WebUI: Users denied by the OAuth role policy can still sign in via token exchange
Medium Also affects open-webui
GHSA-4qg5-cxx4-g927
Open WebUI: Users denied by the OAuth domain allowlist or role policy can still sign in via token exchange
Medium Also affects open-webui
GHSA-jqhh-cjmq-vmv6
Open WebUI: Any authenticated user can hang the server via a cyclic chat message history
Medium Also affects open-webui
GHSA-5x7x-4c3c-qf5w
Open WebUI: Server-side fetches reach blocked and internal hosts via unvalidated HTTP redirect targets
Medium Also affects open-webui
GHSA-3cgp-3cqx-j8w2
Open WebUI: Any authenticated user can hang the server via message deletion in a cyclic chat tree
Medium Also affects open-webui
GHSA-34r3-9m95-vq73
Open WebUI: Any authenticated user can reach the Azure platform channel via server-side web fetch
High Also affects open-webui
GHSA-2724-6cpj-gf3v
Open WebUI: Non-admin users can delete admin-owned external knowledge connections via knowledge base deletion
High Also affects open-webui
GHSA-3pf7-q2g3-wj28
Open WebUI: Any authenticated user can inject chats into another user's folder via chat completions
Medium Also affects open-webui
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor