PT-2026-59377 · Pypi · Open-Webui

Published

2026-07-13

·

Updated

2026-07-13

CVSS v3.1

5.0

Medium

VectorAV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N

Mass Assignment via Pydantic extra='allow' Allows Creating Folders in Other Users' Accounts

Affected Component

Folder creation endpoint and form model:
  • backend/open webui/models/folders.py (lines 72-77, FolderForm with extra='allow')
  • backend/open webui/models/folders.py (lines 95-106, insert new folder dict construction)
  • backend/open webui/routers/folders.py (line 119, create folder endpoint)

Affected Versions

Current main branch (commit 6fdd19bf1) and likely all versions since FolderForm adopted extra='allow'.

Description

FolderForm uses model config = ConfigDict(extra='allow'), which permits arbitrary fields to pass through Pydantic validation and be included in model dump(exclude unset=True). In insert new folder, the server-assigned user id is placed at the start of the dict and then overwritten by the spread of form data:
python
# models/folders.py:95-106
folder = FolderModel(
  **{
    'id': id,                       # server
    'user id': user id,                  # server — overwritten below
    **(form data.model dump(exclude unset=True) or {}),  # user-controlled (extra='allow')
    'parent id': parent id,
    'created at': int(time.time()),
    'updated at': int(time.time()),
  }
)
Because FolderModel declares user id: str as a real field (not just a form extra), any attacker-supplied user id in the POST body is accepted by the model and persisted on the Folder row.

Attack Scenario

  1. Attacker discovers a victim's user ID. User UUIDs commonly leak via the user search endpoint (GET /api/v1/users/search, intentionally accessible to verified users for sharing UI), shared chat metadata, or channel member lists.
  2. Attacker sends:
POST /api/v1/folders/
{
 "name": "Important: Click here",
 "user id": "<victim user id>",
 "meta": {"icon": "warning"},
 "data": {...}
}
  1. Pydantic accepts the extra user id field (allowed by extra='allow').
  2. insert new folder spreads the form data over the server-set 'user id': user id, overwriting it with the attacker's value.
  3. The Folder row is persisted with user id = <victim user id>.
  4. The victim sees the attacker-planted folder in their UI on next load because GET /api/v1/folders/ filters by the viewer's own user id.
The attacker can repeat this to plant multiple folders, use crafted name values for phishing ("Click here to recover account" / "Security alert"), and abuse the meta and data fields to add visual elements that further mimic legitimate content.

Impact

  • Unauthorized write into victim's folder tree
  • Phishing surface: attacker-controlled name, meta, and data render in the victim's UI in a trusted context
  • DoS / spam: attacker can flood a victim with arbitrary folders; victim must manually delete each one
  • Attacker cannot read the folder back — all read paths filter by the caller's own user id — so confidentiality is preserved, but integrity and trust are compromised

Preconditions

  • Attacker must have an authenticated account with features.folders permission (default for all users)
  • Attacker must know or guess the victim's user UUID (obtainable through various non-sensitive endpoints)

Fix

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Related Identifiers

PYSEC-2026-2735

Affected Products

Open-Webui