CVE-2026-28788: Open WebUI Privilege Escalation Flaw

CVE-2026-28788 Overview

CVE-2026-28788 is an Insecure Direct Object Reference (IDOR) vulnerability in Open WebUI, a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to version 0.8.6, any authenticated user can overwrite any file's content by ID through the POST /api/v1/retrieval/process/files/batch endpoint. The endpoint performs no ownership check, enabling a regular user with read access to a shared knowledge base to obtain file UUIDs via GET /api/v1/knowledge/{id}/files and subsequently overwrite those files, escalating from read to write access.

Critical Impact

Attackers can control what the LLM tells other users by poisoning the RAG (Retrieval-Augmented Generation) data source, potentially leading to misinformation, social engineering attacks, or manipulation of AI-generated responses across the platform.

Affected Products

• Open WebUI versions prior to 0.8.6
• openwebui open_webui

Discovery Timeline

• 2026-03-27 - CVE CVE-2026-28788 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-28788

Vulnerability Analysis

This vulnerability is classified as CWE-639 (Authorization Bypass Through User-Controlled Key), commonly known as an Insecure Direct Object Reference (IDOR). The flaw exists in the file processing batch endpoint where authenticated users can manipulate file references without proper authorization validation.

The attack chain is straightforward: an attacker with basic read access to a shared knowledge base can enumerate file UUIDs through the knowledge files API endpoint. Once file identifiers are obtained, the attacker exploits the missing ownership validation in the batch processing endpoint to overwrite arbitrary files.

What makes this vulnerability particularly dangerous is its impact on the RAG pipeline. Since overwritten content is served directly to the Large Language Model for generating responses, attackers effectively gain control over the AI's knowledge source. This means malicious content injected through this vulnerability will be treated as authoritative by the LLM and presented to all users who query related topics.

Root Cause

The root cause is a missing authorization check in the POST /api/v1/retrieval/process/files/batch endpoint. The application fails to verify whether the requesting user has ownership or write permissions for the files being processed. This allows any authenticated user to reference and modify files by UUID, regardless of whether they created or own those files. The endpoint trusts the file identifiers provided in the request without validating the user's relationship to those resources.

Attack Vector

The attack requires network access and low-privilege authentication. An attacker must first authenticate to the Open WebUI platform with any valid user account. The exploitation workflow involves:

1. Identifying a shared knowledge base that the attacker has read access to
2. Querying GET /api/v1/knowledge/{id}/files to enumerate file UUIDs within that knowledge base
3. Crafting a malicious payload with arbitrary content to inject into the RAG system
4. Sending a POST request to /api/v1/retrieval/process/files/batch with the target file UUID and malicious content
5. The file content is overwritten without authorization checks, and subsequent RAG queries will serve the poisoned data to the LLM

The vulnerability mechanism centers on the batch file processing endpoint accepting file identifiers without validating ownership. When a request is received, the application directly processes the provided file UUIDs and overwrites their content. For detailed technical information, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-28788

Indicators of Compromise

• Unexpected file modifications in knowledge bases, particularly by users who only have read access
• Audit log entries showing POST /api/v1/retrieval/process/files/batch requests from users accessing files outside their ownership scope
• Changes to RAG content that don't match legitimate user activities or expected workflows
• User reports of unusual or suspicious LLM responses that don't align with expected knowledge base content

Detection Strategies

• Implement API request logging for the /api/v1/retrieval/process/files/batch endpoint with correlation to file ownership records
• Monitor for cross-user file access patterns where the requesting user ID differs from the file owner ID
• Create alerts for bulk file modification requests from accounts with limited permissions
• Review knowledge base file modification timestamps and compare against authorized change windows

Monitoring Recommendations

• Enable detailed audit logging for all file manipulation API endpoints in Open WebUI
• Deploy web application firewall (WAF) rules to flag unusual patterns in batch processing requests
• Establish baseline metrics for file modification frequency per user and alert on anomalies
• Implement integrity monitoring for critical knowledge base files used in production RAG workflows

How to Mitigate CVE-2026-28788

Immediate Actions Required

• Upgrade Open WebUI to version 0.8.6 or later immediately to patch the authorization bypass
• Audit knowledge base files for unauthorized modifications, comparing current content against known-good backups
• Review access logs for the /api/v1/retrieval/process/files/batch endpoint to identify potential exploitation attempts
• Consider temporarily restricting knowledge base sharing until the patch is applied

Patch Information

The vulnerability is patched in Open WebUI version 0.8.6. Organizations should upgrade to this version or later as soon as possible. For complete patch details and security advisory information, see the GitHub Security Advisory GHSA-jjp7-g2jw-wh3j.

Workarounds

• Restrict user registration and limit authenticated accounts to trusted individuals until patching is complete
• Temporarily disable knowledge base sharing features to prevent cross-user file access
• Implement network-level access controls to limit API endpoint exposure
• Deploy a reverse proxy with custom rules to block requests to the vulnerable batch processing endpoint

# Example: Restrict access to vulnerable endpoint via nginx until patched
# Add to server block configuration
location /api/v1/retrieval/process/files/batch {
    # Deny all access to vulnerable endpoint
    deny all;
    return 403;
}