# Open WebUI: Non-admin users can delete admin-owned external knowledge connections via knowledge base deletion

Non-admin with write grant on one external knowledge base deletes it, wiping the shared admin-owned external connection and breaking all other knowledge bases bound to it.

- Payout: Research
- Severity: high
- Program: Open WebUI
- Found by: Bellingham-max
- Disclosed: 2026-09-10
- CVE: CVE-2026-87998
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-2724-6cpj-gf3v
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-2724-6cpj-gf3v
- Tags: area:ai domain:ai domain:web impact:dos impact:integrity kind:research platform:ghsa sev:high tech:python technique:source-review vuln:access-control vuln:auth-bypass vuln:idor

**Target:** Knowledge base delete endpoint (DELETE /api/v1/knowledge/{id}/delete) in backend/open_webui/routers/knowledge.py
**Root cause:** The knowledge base delete handler authorized the caller only against the knowledge base (write grant suffices), then performed a second operation on global connection configuration with no admin-role check and no count of other knowledge bases still bound to the connection.
**Steps:**
1. Admin creates one external connection and two external knowledge bases (KB_A, KB_B) bound to it; grants a plain user write access on KB_A.
2. As that user send `DELETE /api/v1/knowledge/{KB_A}/delete` with `Authorization: Bearer <user token>`.
3. On 0.11.0 response is 200 true; admin connection list returns zero connections.
4. KB_B retains the deleted connection id and retrieval fails with "External knowledge connection not found".
5. On 0.11.1 the connection survives and KB_B is unaffected.
**How found:** Noticed the KB delete handler performed a second, unrelated global-configuration operation in the same request, and compared it to the dedicated connection delete route which already enforced admin role and in-use checks — an outcome admins were blocked from was reachable by non-admins via the KB route.
**Exploitation:** Any authenticated user with a write grant on a single external knowledge base issues the standard KB delete request; the handler tears down the instance-wide connection, disabling every other knowledge base bound to it and destroying the stored credential (not recoverable via API since responses strip credentials).
**Insight:** When a resource-delete handler cascades into shared/global config, diff its authorization against the dedicated admin route for that config; a weaker sibling route often bypasses role and reference-count checks.

## Proof of concept (copied exactly from the original report)

**Non-admin DELETE knowledge base request**

```
DELETE /api/v1/knowledge/{KB_A}/delete
Authorization: Bearer <user token>
```