| Package | Affected versions | Patched versions |
|---|---|---|
| open-webui | < 0.9.6 | 0.9.6 |
| open webui | < 0.9.6 | 0.9.6 |
backend/open_webui/utils/oauth.py::_process_picture_url (v0.9.5, lines 1435-1470) calls validate_url(picture_url) on the initial URL only, then invokes aiohttp.ClientSession.get(picture_url, ...) without allow_redirects=False. aiohttp's default is allow_redirects=True, max_redirects=10; the function does not pass the project's AIOHTTP_CLIENT_ALLOW_REDIRECTS env constant either. An attacker with a valid OAuth IdP identity can therefore submit a public URL that 302-redirects to an internal address and read the internal response body via the attacker's own profile_image_url field.
This is the same redirect-bypass class as CVE-2026-45401 (GHSA-rh5x-h6pp-cjj6), on a 6th call site that the v0.9.5 patch missed. CVE-2026-45401's advisory body enumerates exactly five affected paths — SafeWebBaseLoader._scrape, _fetch, get_content_from_url, load_url_image, get_image_base64_from_url — none in utils/oauth.py.
backend/open_webui/utils/oauth.py, lines 1435-1470:
async def _process_picture_url(self, picture_url: str, access_token: str = None) -> str:
if not picture_url:
return '/user.png'
try:
validate_url(picture_url) # initial URL only
get_kwargs = {}
if access_token:
get_kwargs['headers'] = {'Authorization': f'Bearer {access_token}'}
async with aiohttp.ClientSession(trust_env=True) as session:
async with session.get(picture_url, **get_kwargs,
ssl=AIOHTTP_CLIENT_SESSION_SSL) as resp:
# ^^^^^^^^^^^ no allow_redirects=False
if resp.ok:
picture = await resp.read()
base64_encoded_picture = base64.b64encode(picture).decode('utf-8')
guessed_mime_type = mimetypes.guess_type(picture_url)[0]
if guessed_mime_type is None:
guessed_mime_type = 'image/jpeg'
return f'data:{guessed_mime_type};base64,{base64_encoded_picture}'
...
The function is invoked at oauth.py:1556 (new-user OAuth signup) and oauth.py:1536 (existing-user picture update on login). Neither call site re-validates after redirect-following.
backend/open_webui/retrieval/web/utils.py (v0.9.5) imports the env constant AIOHTTP_CLIENT_ALLOW_REDIRECTS at line 51 and uses it on the five paths patched by CVE-2026-45401. does not import or reference it.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeutils/oauth.pyPreconditions:
ENABLE_OAUTH_SIGNUP=true or OAUTH_UPDATE_PICTURE_ON_LOGIN=true (common in production OAuth-IdP deployments)Steps:
http://attacker.example/r on a public IP. validate_url("http://attacker.example/r") returns True (is_global=True for public IPs).picture claim to http://attacker.example/r._process_picture_url("http://attacker.example/r", ...).validate_url accepts the public URL. session.get("http://attacker.example/r") is invoked.HTTP/1.1 302 Found\r\nLocation: http://127.0.0.1:11434/api/tags. (Or http://169.254.169.254/latest/meta-data/iam/security-credentials/, RFC1918 internal services, etc.)picture, base64-encoded, and stored as profile_image_url = "data:image/jpeg;base64,..." on the attacker's account.GET /api/v1/auths/. Decode the base64 payload to get the full internal response body.Full-read SSRF, identical read-back primitive to CVE-2026-45338:
169.254.169.254, GCP metadata.google.internal, Azure IMDS) → IAM credentials, managed-identity tokens:11434, Redis, Elasticsearch, internal Postgres exporters)| Prior CVE | This finding | Distinguishing fact |
|---|---|---|
| CVE-2026-45338 (GHSA-24c9) | _process_picture_url had no validate_url() call at all | Fixed in v0.9.0 by adding the call. Ours is the call being insufficient because it doesn't loop over redirect targets. Different mechanism, different fix. |
| CVE-2026-45400 (GHSA-8w7q) | validate_url() had urlparse-vs-requests parser disagreement on \@ chars | Fixed in v0.9.5 by char-blocklist. Ours is post-validation redirect-following — orthogonal mechanism. |
| CVE-2026-45401 (GHSA-rh5x) | Five paths in retrieval, routers/images, utils/files, utils/middleware | Parent class. Same CWE-918 redirect-bypass mechanism. utils/oauth.py::_process_picture_url is not among the five paths in the parent advisory's "Affected code paths" section. Same class, missed sink. Direct sibling. |
async with session.get(
picture_url,
**get_kwargs,
ssl=AIOHTTP_CLIENT_SESSION_SSL,
allow_redirects=AIOHTTP_CLIENT_ALLOW_REDIRECTS, # add
) as resp:
Or, if redirects must remain enabled by default, wrap in a manual-follow loop that re-invokes validate_url() on each Location header. This mirrors the fix shape applied to the five paths in CVE-2026-45401.
Vulnerable: <= 0.9.5
Fix: 0.9.6
_process_picture_url SSRF, patched v0.9.0)validate_url parser-disagreement bypass, patched v0.9.5)End-to-end PoC executed against ghcr.io/open-webui/open-webui:v0.9.5 in Docker compose. Three services: attacker (OIDC IdP + 302-redirect endpoint on evil.example.com:9001/redirect), canary (internal target on internal-target.local:9002/sentinel), open-webui v0.9.5.
Fresh-CSPRNG sentinel generated after OAuth state-establishing call (per Gate 5.5 oracle protocol): SSRF-POC-5580111b2a0d7d0c8324bfa92a0d9d09.
Result:
profile_image_url field after OAuth login: data:image/jpeg;base64,U1NSRi1QT0MtNTU4MDExMWIyYTBkN2QwYzgzMjRiZmE5MmEwZDlkMDk=SSRF-POC-5580111b2a0d7d0c8324bfa92a0d9d09 (byte-for-byte sentinel match)!!! SSRF HIT - sentinel servedChain confirmed: OAuth login → IdP returns picture claim evil.example.com:9001/redirect → validate_url() accepts FQDN → aiohttp.ClientSession.get(...) follows 302 to internal-target.local:9002/sentinel server-side without re-validation → response body base64-encoded into attacker's profile_image_url → readable via GET /api/v1/auths/.
PoC artifacts (compose, attacker server, canary, run/verify scripts, full transcript) available on request.
Matteo Panzeri — GitHub: matte1782, contact: [email protected]. Requesting CVE credit as Matteo Panzeri.