Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline

CVE-2026-28788 is an IDOR/BOLA-style authorization failure in Open WebUI's POST /api/v1/retrieval/process/files/batch endpoint. In versions <=0.8.5, any authenticated user can overwrite file content by UUID because the route accepts a verified user but does not verify file ownership before updating the record. The vendor advisory says the attacker can first enumerate valid file UUIDs from GET /api/v1/knowledge/{id}/files when they have read access to a shared knowledge base, then replace the file contents that downstream RAG uses.

The vendor's HIGH 7.1 is technically defensible in a lab because exploitation is simple once prerequisites are met, but it overstates enterprise urgency in the real world. This is not unauthenticated internet-edge compromise; it is *post-auth, shared-resource abuse* with impact concentrated on knowledge-base integrity and downstream model responses, not host takeover or tenant-wide compromise. Low EPSS, no KEV listing, and a requirement for authenticated access plus visibility into a shared knowledge base all push this down to MEDIUM.

Why this verdict

• Down from vendor HIGH because it needs post-auth access: the attacker must already hold a valid Open WebUI session, which implies prior compromise, insider access, or a weak identity boundary.
• Further down because it needs shared-knowledge visibility: the exploit chain depends on read access to a shared knowledge base so the attacker can enumerate victim file UUIDs. Private or tightly segmented knowledge bases sharply reduce reachable targets.
• Impact is mostly integrity poisoning, not platform takeover: the bug rewrites RAG content and can manipulate model answers, but the published record does not show direct OS execution, database dump, or admin privilege escalation.
• No current exploit-pressure amplifiers: EPSS is 0.00016, KEV is No, and the reviewed sources do not show active exploitation campaigns.
• Still not LOW: exploitation is straightforward once prerequisites are met, uses ordinary API calls, and can silently corrupt business decision support if Open WebUI is used for shared internal knowledge retrieval.

Why not higher?

This is not unauthenticated remote compromise, not wormable, and not a direct route to system-level code execution from the published advisory. The attack population shrinks at each prerequisite: authenticated user, shared knowledge base access, target file UUID discovery, and actual downstream RAG dependence on the poisoned file.

Why not lower?

Once an attacker has a normal user account and shared knowledge-base visibility, exploitation is low-friction and the integrity impact is meaningful. In organizations using Open WebUI for internal policy, engineering, or support knowledge, poisoned RAG content can create materially bad answers at scale, so dismissing it as mere hygiene would be too relaxed.

1. Put Open WebUI behind a strong identity boundary — Require VPN, zero-trust proxy, or SSO-backed reverse proxy in front of Open WebUI and deploy this within the noisgate remediation window only after patching? No—because this is a MEDIUM, there is no mitigation SLA; use it as a priority hardening step while you work toward remediation within 365 days. This directly attacks the biggest amplifier: authenticated access by the wrong user.
2. Reduce shared knowledge-base exposure — Limit broad read access to shared knowledge bases, especially cross-team repositories, and review who can list files in each space. Do this during the MEDIUM remediation cycle, because the exploit requires discoverable shared targets more than it requires exotic tooling.
3. Audit file ownership and recent content changes — Review file update history, file UUID access patterns, and changes made by low-privilege users to documents they do not own. Run this immediately as a detection control and continue until all instances are upgraded within the 365-day remediation window.
4. Pin and inventory Open WebUI versions — Stop running floating :main or :dev tags in production where possible and map each deployment to an exact image or package version. For this MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but version certainty is what lets you close the issue confidently.

Run this on the target Linux host that runs Open WebUI, ideally with permission to query Docker/Podman or read the local Python environment. Save it as check-openwebui-cve-2026-28788.sh, then run bash check-openwebui-cve-2026-28788.sh or bash check-openwebui-cve-2026-28788.sh /opt/open-webui-venv/bin/python; root is not required, but access to the container runtime socket may be.

#!/usr/bin/env bash
# Check for CVE-2026-28788 exposure in Open WebUI
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_FIXED="0.8.6"
PYTHON_BIN="${1:-python3}"

log() { printf '%s\n' "$*"; }

verlte() {
  # returns 0 if $1 <= $2 using sort -V
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

verlt() {
  [ "$1" != "$2" ] && verlte "$1" "$2"
}

normalize_tag() {
  local v="$1"
  v="${v#v}"
  v="${v%%-*}"
  printf '%s' "$v"
}

check_version() {
  local source="$1"
  local version_raw="$2"
  local version
  version="$(normalize_tag "$version_raw")"

  if [[ ! "$version" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
    log "UNKNOWN - Could not parse semantic version from $source: $version_raw"
    return 2
  fi

  if verlt "$version" "$TARGET_FIXED"; then
    log "VULNERABLE - $source reports Open WebUI version $version (< $TARGET_FIXED)"
    return 1
  else
    log "PATCHED - $source reports Open WebUI version $version (>= $TARGET_FIXED)"
    return 0
  fi
}

# 1) Docker container image tags
if command -v docker >/dev/null 2>&1; then
  while IFS= read -r line; do
    cid="${line%% *}"
    image="${line#* }"
    if [[ "$image" == *"open-webui"* ]]; then
      tag="${image##*:}"
      check_version "Docker image $image" "$tag"
      exit $?
    fi
  done < <(docker ps --format '{{.ID}} {{.Image}}' 2>/dev/null)
fi

# 2) Podman container image tags
if command -v podman >/dev/null 2>&1; then
  while IFS= read -r line; do
    cid="${line%% *}"
    image="${line#* }"
    if [[ "$image" == *"open-webui"* ]]; then
      tag="${image##*:}"
      check_version "Podman image $image" "$tag"
      exit $?
    fi
  done < <(podman ps --format '{{.ID}} {{.Image}}' 2>/dev/null)
fi

# 3) Python package metadata from provided or default interpreter
if command -v "$PYTHON_BIN" >/dev/null 2>&1; then
  PKG_VERSION="$($PYTHON_BIN - <<'PY' 2>/dev/null
import sys
mods = []
try:
    try:
        from importlib.metadata import version, PackageNotFoundError
    except Exception:
        from importlib_metadata import version, PackageNotFoundError
    for name in ("open-webui", "open_webui"):
        try:
            print(version(name))
            raise SystemExit(0)
        except PackageNotFoundError:
            pass
except Exception:
    pass
raise SystemExit(1)
PY
)"
  if [ -n "${PKG_VERSION:-}" ]; then
    check_version "Python package" "$PKG_VERSION"
    exit $?
  fi
fi

# 4) Local filesystem hints for pinned compose/container files
for f in docker-compose.yml docker-compose.yaml compose.yml compose.yaml; do
  if [ -f "$f" ] && grep -qi 'open-webui' "$f"; then
    tag="$(grep -i 'open-webui' "$f" | sed -n 's/.*open-webui:\([^[:space:]]*\).*/\1/p' | head -n1)"
    if [ -n "$tag" ]; then
      check_version "Compose file $f" "$tag"
      exit $?
    fi
  fi
done

log "UNKNOWN - Could not determine an installed Open WebUI version from Docker, Podman, Python metadata, or local compose files"
exit 2

Sources

1. NVD CVE-2026-28788
2. GitHub Security Advisory GHSA-jjp7-g2jw-wh3j
3. OSV entry for CVE-2026-28788
4. OpenCVE entry with EPSS and KEV status
5. Open WebUI release v0.8.6
6. Open WebUI hardening guide
7. Open WebUI quick start
8. B2B Cyber Security summary citing 17k+ Shodan-listed instances