What is the redirect-based SSRF protection?

Before 0.9.5, an outbound HTTP request from the instance could follow a 3xx redirect to a non-public network address, which is the shape of a redirect-based SSRF: a public URL that silently redirects to an RFC 1918, loopback, or cloud-metadata address. In 0.9.5, all outbound requests block 3xx redirects by default via a new AIOHTTP_CLIENT_ALLOW_REDIRECTS environment variable. The affected call sites include web fetch, image loading, OAuth discovery, tool server execution, and code interpreter login.

What did the permission-enforcement fixes close?

Several gaps where one user could reach another user's data or act outside their grant. Creating or updating skills now filters access grants through a sharing.public_skills permission so a non-admin cannot make skills public without it. Calendars got an equivalent sharing.public_calendars permission. Submitting evaluation feedback can no longer forge the user_id through mass-assignment. The process_file and process_files_batch endpoints now enforce collection write-access checks before embedding content. Updating a tool's Python source code now requires workspace.tools or workspace.tools_import. And channel messages require ownership to update or delete, and pinning requires write permission.

Is the SSRF protection on by default?

Yes, the default is to block 3xx redirects on outbound requests, which is the safe posture. An administrator who has a legitimate need to follow redirects on a specific path can set AIOHTTP_CLIENT_ALLOW_REDIRECTS, but the default is the protective one. For most deployments the right move is to leave the default in place and only relax it for a specific, understood case.

Open WebUI 0.9.5: SSRF Protection and Permission Enforcement

Short answer: Open WebUI 0.9.5 is a security-hardening release. The headline additions are redirect-based SSRF protection, where all outbound HTTP requests now block 3xx redirects by default through a new AIOHTTP_CLIENT_ALLOW_REDIRECTS setting, and an iframe content-security policy that an administrator can configure for srcdoc iframes through a new IFRAME_CSP setting. Around those, the release closes a substantial set of permission-enforcement gaps: skill and calendar public-sharing now go through sharing permissions, feedback user attribution can no longer be spoofed, image-URL redirects are no longer followed to non-public network addresses, file collection write access is enforced on processing, tool source-code updates require the right permission, and channel message ownership and pin permissions are enforced. For an operator running a multi-user instance, the theme is that the release tightens the paths by which one user could reach another user's data or execute code, which is exactly the surface that matters when more than one person shares the instance.

Redirect-based SSRF is the reachable variant

The SSRF fix targets the most reachable variant of the vulnerability, because it requires no special permissions and no feature flags. A redirect-based SSRF works like this: a user-supplied or content-derived URL points at a public host, and that host responds with a redirect to a non-public network address. If the application follows the redirect, it fetches the non-public address on the user's behalf, which is the SSRF. The classic image-URL case was the most exposed, because a chat message containing an image URL triggers a fetch with no elevated permission.

The fix is to stop following 3xx redirects on outbound requests by default. That closes the redirect variant across all the call sites, not just the image path. The operator relevance is that this is the difference between an instance that can be used to probe or reach non-public network addresses and one that cannot, and the default-protective posture means the protection is active the moment you upgrade, without any configuration to enable it.

The permission fixes are the multi-user story

The permission-enforcement fixes are the part that matters most on a shared instance, because they close the paths by which one user could act outside their grant. The common thread is authorization: a user with a write access to one thing should not be able to overwrite executable tool code, a user who can read a channel should not be able to pin or delete other members' messages, and a user who can create a skill should not be able to make it publicly shared without the sharing permission. Before 0.9.5, several of these paths did not enforce the check, which is the kind of gap that is easy to miss until someone finds it.

The feedback attribution fix is worth a sentence on its own, because it is the clearest example of the mass-assignment class of bug: a user submitting evaluation feedback could forge the user_id field, which let them attribute ratings to other users and corrupt the Elo leaderboard and the admin feedback exports. That is not a data-leak in the classic sense; it is a data-integrity issue where one user's input could corrupt a shared ranking. The fix stops the user_id from being mass-assignable on that path.

The iframe content-security policy

The second headline addition is the IFRAME_CSP setting, which lets an administrator configure a Content-Security-Policy for all srcdoc iframes, including artifacts, tool embeds, file previews, and citation modals. The purpose is to restrict what LLM-generated or user-uploaded HTML can load and execute inside those preview surfaces. A preview that renders HTML from a model or an upload is a place where a restricted policy is the difference between a sandboxed preview and one that can load scripts from the origin.

The operator takeaway is that 0.9.5 gives you a knob for that surface. If your instance renders model-generated or uploaded HTML in previews, configuring IFRAME_CSP is a straightforward hardening step that reduces what that HTML can do. The fix and the CSP setting together mean the preview path is both protected against redirect-based SSRF and constrained by a content policy, which is the two-layer posture you want on a surface that renders untrusted content.

Because 0.9.5 is a security-hardening release, the upgrade is worth taking even if you do not change any configuration. The default posture, blocking outbound redirects and enforcing the permission checks, is the safe state, and the upgrade activates it. The verification is to confirm the instance starts cleanly, that legitimate outbound fetches that do not need redirects still work, and that the specific permission paths you rely on still behave as your access model intends.

Limitations

A release note is not a deployment audit. It does not inspect your operating system, network policy, credentials, storage, backups, or administrative process.
Version numbers and documentation change. Pin the exact artifacts you test, record the date, and re-check upstream material before a production change.
A feature that exists in a package or command does not automatically fit your threat model. Authentication, authorization, logging, patching, recovery, and abuse controls remain operator responsibilities.
This article contains no benchmark, uptime promise, adoption statistic, cost saving, or client result. Measure those claims in your environment; the release record can only describe what shipped.

Related infrastructure context

For the physical layer around a systems deployment, TismTek provides fiber and network infrastructure work near Aurora. The team also documents on-premises compute and private AI systems. For a site discussion, call (720) 694-1976. See the Open WebUI self-hosted upgrade risk checklist for recovery planning and the Open WebUI private model stack for the broader on-premises context.

Sources

Open WebUI v0.9.5 release notes — consulted September 15, 2026.
Open WebUI v0.9.4 prior release — consulted September 15, 2026.
Open WebUI documentation — consulted September 15, 2026.