Stay up to date on Tachyon.
OpenWebUI, or How Not To Do Vulnerability Disclosure
A case study in poor vulnerability disclosure practices: how OpenWebUI silently patched a high-severity SSRF without crediting the researchers or notifying users.
About a month ago, we submitted this GHSA to OpenWebUI. As you can see, if you tried clicking on that link, it's not public.
This was a high-severity issue. It was an SSRF that allowed any authenticated user to make the server fetch arbitrary internal URLs, including cloud metadata endpoints, and exfiltrate the responses.
But it has barely been interacted with at all. After we reported the vulnerability, we had radio silence for almost three weeks.
We then emailed hello@openwebui.com to draw the maintainers' attention to the issue.
Two days later, the maintainer closed the issue without comment. This confused us, and we immediately went back and tried to reproduce the vulnerability.
But this time, the issue was blocked. We went back to the repo and found this commit: https://github.com/open-webui/open-webui/commit/665f95eda396e857784bdadf5381c29f982db501
A commit with the title "refac" implemented the exact fix we suggested in the advisory.
This was made about 3 days after our report was submitted.
The commit did not credit our report, nor mention the salience of the fix. It was just blended into a stack of ten other commits, all titled "refac," all merged around the same time.
And unfortunately, the fix isn't even complete. The maintainer followed some of the guidance in our report, but not all of it. They implemented a coarse blocklist of URLs, but they didn't handle redirects or DNS rebinding - two obvious SSRF bypasses.
Then, we also found that their blocklist was incomplete. They blocked basic private IPs and the IP address of the AWS metadata service, which are the exact examples we gave in our report. But they blocked almost nothing else. Their filter is denylist-based, so even the easiest bypass will trigger an SSRF. And, if the owner enables local RAG, then even the private-IP filter is disabled.
We sent them a followup email describing the issues with the mitigation. They haven't responded to that either. And as of 02/19/2026, there isn't a new "refac" commit with another fix.
Why This Matters
This is, quite frankly, an awful way to handle vulnerability disclosure. First, security researchers should be credited for their efforts. We need to create good incentives to ensure responsible disclosure. Public credit is the baseline incentive that keeps researchers reporting through proper channels instead of dumping zero-days on Twitter, or worse: selling them to blackhats.
But the larger issue is that burying the fix hurts your users. The central point of responsible disclosure is to inform users and encourage faster adoption of security patches. When you sneak a critical security fix into a commit labeled "refac," you sidestep that process entirely.
Because this wasn't handled as a security issue, it won't show up in any SCA scanners. Users of OpenWebUI won't know the importance of the latest update. Any motivated hacker - or motivated user of Claude Code — could scan the repo, see this suspicious commit, and then search for non-updated versions of OpenWebUI via shodan.io and exploit each one.
Take this post as your disclosure notice instead. If you're running OpenWebUI, upgrade to 0.8.0 as soon as is convenient.