CVE-2026-87013

## Summary Any authenticated user can move one of their own folders under itself, leaving a loop in their folder tree. The re-parent endpoint performed no check that the new parent was not the folder itself or one of its own subfolders, and the folder tree walks did not track which folders they had already visited. A single request against a folder in a loop therefore never finishes. ## Preconditions Folders must be enabled (`ENABLE_FOLDERS`, default true) and the acting user's role must hold the folders feature permission (`USER_PERMISSIONS_FEATURES_FOLDERS`, default true). Both are on in a default install. Any authenticated account is sufficient: no administrator, no second user, no shared folder and no victim interaction. Deployments that disable folders, or withhold the folders feature permission from non-admin roles, are not affected. ## Impact A single request that never returns. It keeps running after the client disconnects, holds a CPU core and grows its in-memory folder list at roughly 0.6 GB per hour until the process is restarted. The folder stays in the looping state in the database, so any later request touching that folder starts the loop again. The instance stays responsive while this happens. Each step of the walk waits on a database query, so other users continue to be served normally; measured on a default install, two concurrent instances of this request left unrelated users unaffected, and roughly 900 concurrent requests were needed before anyone else saw a slowdown. Nothing is denied to any other party at the time of the attack, and an unattended instance degrades over hours rather than immediately. No user data is exposed and no data belonging to another user is modified. ## Fix Fixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/28748. Moving a folder into itself or into one of its own subfolders is now rejected with a 400, every folder tree walk skips ids it has already visited, and a folder whose parent chain loops is returned to the root the next time the folder list is requested. An instance that already holds folders in this state recovers on upgrade with no operator action. ## Root cause Affected components: the folder re-parent handler `POST /api/v1/folders/{id}/update/parent`, the subtree walk in the folder model that expands a folder into its descendants, and the two endpoints that call it, `DELETE /api/v1/folders/{id}` and `POST /api/v1/folders/{id}/read`. Affected setup: the subtree walk was introduced in 0.10.0, so no earlier release carries the code. The folder hierarchy is stored as a plain parent reference per folder, with the acyclic property assumed rather than enforced. The write path never validated that assumption, and the read paths were written as if it always held, so nothing on either side would notice or stop a loop. ## Proof of concept Reproduced against a default 0.11.0 install. As an ordinary authenticated user: 1. Create a folder and note its id. 2. `POST /api/v1/folders/{id}/update/parent` with `parent_id` set to that same id. The request is accepted. 3. `DELETE /api/v1/folders/{id}` (or `POST /api/v1/folders/{id}/read`). The request never returns, and the worker continues running after the client disconnects. No data was seeded directly into the database. Every step ran through the public API. ## Credits @luida-ikura, who reported the folder parent cycle and the non-terminating subtree walk it reaches.

## Summary Any authenticated user can move one of their own folders under itself, leaving a loop in their folder tree. The re-parent endpoint performed no check that the new parent was not the folder itself or one of its own subfolders, and the folder tree walks did not track which folders they had already visited. A single request against a folder in a loop therefore never finishes. ## Preconditions Folders must be enabled (`ENABLE_FOLDERS`, default true) and the acting user's role must hold the folders feature permission (`USER_PERMISSIONS_FEATURES_FOLDERS`, default true). Both are on in a default install. Any authenticated account is sufficient: no administrator, no second user, no shared folder and no victim interaction. Deployments that disable folders, or withhold the folders feature permission from non-admin roles, are not affected. ## Impact A single request that never returns. It keeps running after the client disconnects, holds a CPU core and grows its in-memory folder list at roughly 0.6 GB per hour until the process is restarted. The folder stays in the looping state in the database, so any later request touching that folder starts the loop again. The instance stays responsive while this happens. Each step of the walk waits on a database query, so other users continue to be served normally; measured on a default install, two concurrent instances of this request left unrelated users unaffected, and roughly 900 concurrent requests were needed before anyone else saw a slowdown. Nothing is denied to any other party at the time of the attack, and an unattended instance degrades over hours rather than immediately. No user data is exposed and no data belonging to another user is modified. ## Fix Fixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/28748. Moving a folder into itself or into one of its own subfolders is now rejected with a 400, every folder tree walk skips ids it has already visited, and a folder whose parent chain loops is returned to the root the next time the folder list is requested. An instance that already holds folders in this state recovers on upgrade with no operator action. ## Root cause Affected components: the folder re-parent handler `POST /api/v1/folders/{id}/update/parent`, the subtree walk in the folder model that expands a folder into its descendants, and the two endpoints that call it, `DELETE /api/v1/folders/{id}` and `POST /api/v1/folders/{id}/read`. Affected setup: the subtree walk was introduced in 0.10.0, so no earlier release carries the code. The folder hierarchy is stored as a plain parent reference per folder, with the acyclic property assumed rather than enforced. The write path never validated that assumption, and the read paths were written as if it always held, so nothing on either side would notice or stop a loop. ## Proof of concept Reproduced against a default 0.11.0 install. As an ordinary authenticated user: 1. Create a folder and note its id. 2. `POST /api/v1/folders/{id}/update/parent` with `parent_id` set to that same id. The request is accepted. 3. `DELETE /api/v1/folders/{id}` (or `POST /api/v1/folders/{id}/read`). The request never returns, and the worker continues running after the client disconnects. No data was seeded directly into the database. Every step ran through the public API. ## Credits @luida-ikura, who reported the folder parent cycle and the non-terminating subtree walk it reaches.