AI and data stack advisories

Severe, 6 weeks1496Projects326

1496 severe, 6 weeks · 326 projects

Open WebUIGHSA-8jjp-r2w2-4v22

Open WebUI: missing authorization

Open WebUI

CVE-2026-45399 · Published May 14, 2026 · updated Jul 13, 2026

High7.1
Fix: upgrade to 0.9.0 or later
GitHub advisory

Summary

Any authenticated user with low privileges can enumerate active background tasks across the system and stop tasks belonging to other users via the GET /api/tasks and POST /api/tasks/stop/{task_id} methods. This allows a casual user to disrupt system-wide chat usage by continuously canceling other users' active tasks. This is a real authorization vulnerability affecting integrity and usability in multi-user deployments.

Details

Open WebUI exposes GET /api/tasks and POST /api/tasks/stop/{task_id} to any verified user. These endpoints operate on a global task namespace and accept raw task_id values without checking whether the task belongs to the current caller.

As a result, a normal authenticated user can enumerate active global task IDs and stop tasks belonging to other users.

Root cause:

1. Route authorization is too weak.

In backend/open_webui/main.py, both endpoints only require get_verified_user:

```python

@app.post('/api/tasks/stop/{task_id}')

async def stop_task_endpoint(request: Request, task_id: str, user=Depends(get_verified_user)):

result = await stop_task(request.app.state.redis, task_id)

@app.get('/api/tasks')

async def list_tasks_endpoint(request: Request, user=Depends(get_verified_user)):

return {'tasks': await list_tasks(request.app.state.redis)}

`

get_verified_user accepts both user and admin roles in...

Affected versions

PackageAffectedFixed in
open-webui
PyPI
< 0.9.00.9.0
Details and references

### Summary Any authenticated user with low privileges can enumerate active background tasks across the system and stop tasks belonging to other users via the GET /api/tasks and POST /api/tasks/stop/{task_id} methods. This allows a casual user to disrupt system-wide chat usage by continuously canceling other users' active tasks. This is a real authorization vulnerability affecting integrity and usability in multi-user deployments. ### Details Open WebUI exposes `GET /api/tasks` and `POST /api/tasks/stop/{task_id}` to any verified user. These endpoints operate on a global task namespace and accept raw `task_id` values without checking whether the task belongs to the current caller. As a result, a normal authenticated user can enumerate active global task IDs and stop tasks belonging to other users. Root cause: 1. Route authorization is too weak. In `backend/open_webui/main.py`, both endpoints only require `get_verified_user`: ```python @app.post('/api/tasks/stop/{task_id}') async def stop_task_endpoint(request: Request, task_id: str, user=Depends(get_verified_user)): result = await stop_task(request.app.state.redis, task_id) @app.get('/api/tasks') async def list_tasks_endpoint(request: Request, user=Depends(get_verified_user)): return {'tasks': await list_tasks(request.app.state.redis)} ``` `get_verified_user` accepts both `user` and `admin` roles in `backend/open_webui/utils/auth.py`. 2. The helper operates on a global namespace. In `backend/open_webui/tasks.py`, task listing is global: ```python async def list_tasks(redis): if redis: return await redis_list_tasks(redis) return list(tasks.keys()) ``` In `backend/open_webui/tasks.py`, task stopping is by raw `task_id`: ```python async def stop_task(redis, task_id: str): if redis: item_id = await redis.hget(REDIS_TASKS_KEY, task_id) await redis_send_command(redis, {'action': 'stop', 'task_id': task_id}) await redis_cleanup_task(redis, task_id, item_id or None) ``` There is no owner check, no `user_id` check, and no mapping from `task_id` back to the current caller before stop or cleanup. This also appears unintended because the codebase already has a scoped route, `GET /api/tasks/chat/{chat_id}`, which checks whether the chat belongs to the current user before returning task IDs. Relevant code references: - `backend/open_webui/main.py:1975` - `backend/open_webui/main.py:1984` - `backend/open_webui/main.py:1989` - `backend/open_webui/tasks.py:127` - `backend/open_webui/tasks.py:145` - `backend/open_webui/utils/auth.py:415` Suggested remediation: - Store task ownership metadata such as `user_id` and `chat_id`, then enforce owner-only access for non-admin users - Suggested implementation locations: - `backend/open_webui/main.py`: add authentication checks for `/api/tasks` and `/api/tasks/stop/{task_id}` - `backend/open_webui/tasks.py`: add support for storing/querying task ownership metadata such as `user_id` and `chat_id`, and support owner-scoped listing/stopping ### PoC Preconditions: - Default `main` branch deployment - Authentication enabled - Two normal user accounts, or any multi-user deployment where the attacker has one authenticated non-admin account - At least one task actively running for another user This does not require any weakened security settings. PoC objective: 1. Show that a non-admin user can see global active task IDs that are not their own 2. Show that the same user can stop another user's active task Reproduction steps: #### Step 1. Victim starts a long-running task Using the UI, User A starts a long response generation or another background task and leaves it running. Expected security model: User B should not be able to see or control User A's task. #### Step 2. Attacker enumerates global task IDs Using User B's authenticated token: ```bash curl -i -H "Authorization: Bearer <USER_B_TOKEN>" http://<open-webui-host>/api/tasks ``` Expected result: - only User B's own ta

CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H
Severity from
GitHub (reviewed advisory)
Weakness
CWE-862
Also known as
CVE-2026-45399, PYSEC-2026-2714

More Open WebUI advisories

All Open WebUI