CVE-2026-45399

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.0, 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. This vulnerability is fixed in 0.9.0.

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.0, 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. This vulnerability is fixed in 0.9.0.

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:

@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:

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:

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:

curl -i -H "Authorization: Bearer <USER_B_TOKEN>" http://<open-webui-host>/api/tasks

Expected result:

• only User B's own…

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.0, 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. This vulnerability is fixed in 0.9.0.

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.0, 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. This vulnerability is fixed in 0.9.0.

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:

@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:

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:

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:

curl -i -H "Authorization: Bearer <USER_B_TOKEN>" http://<open-webui-host>/api/tasks

Expected result:

• only User B's own…

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:

@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:

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:

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:

curl -i -H "Authorization: Bearer <USER_B_TOKEN>" http://<open-webui-host>/api/tasks

Expected result:

• only User B's own…