OPEN-WEBUI · CVE-2026-109294 · AI agents & MCP
FIX → 0.11.4
Open WebUI fetches image URLs in chat messages without limiting decompressed size, so a small compressed response can expand to hundreds of megabytes in server memory. An authenticated user can repeat this to make the server run out of memory and deny service to other users.
first public Sep 27, 2026 · 2 sources
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Any Open WebUI instance running a version from 0.6.42 through 0.11.3 is exposed, because the image fetch runs on every chat request with a URL in the image field. Exposure needs a verified account with access to a model and a public URL the server can reach; the private-address filter still blocks internal targets. Instances that cannot be reached by such users, or that are already on 0.11.4 or later, can skip it.
Not affected if auth-required, private-address-only
Who cares open-webui, python, self-hosted
pip show open-webui; versions from >= 0.6.42 and < 0.11.4 are affected.Upgrade to 0.11.4
An ordinary account can put any URL in the image field of a chat message. The server fetches that URL and inlines the bytes into the request it sends on to the model provider. The fetch had no ceiling on how much it would read, and HTTP content encoding lets the sender decide how much the receiver materialises, so a few hundred kilobytes crossing the network turn into hundreds of megabytes held in the server process. Nothing on that path limited the size, the compression ratio, or how often it could be repeated.
Availability, against every other user of the instance. Measured against a real instance: a single request from an ordinary account, with about 261 KB leaving the attacker's host, drove the server process from 731 MB to 2.16 GB resident and returned HTTP 200. That figure is a setting rather than a ceiling, because the size is chosen by the attacker's host and the request can be repeated. There is no confidentiality or integrity effect, and no data is read or altered.
Fixed in 0.11.4 by #29623. The image fetch now reads the response incrementally, asks for an unencoded body, and refuses any response that still arrives compressed, so the sender can no longer pick the decoded size. An image that arrives compressed is not inlined and the message is sent on without it. Upgrading is sufficient, there is nothing an operator has to configure.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
open-webui0.11.4backend/open_webui/utils/files.py, get_image_base64_from_url: read the whole response body into memory before encoding it.backend/open_webui/utils/middleware.py, convert_url_images_to_base64: the caller, which runs on every chat request and holds each encoded image for the life of that request.The helper was written to fetch a small image and treats a response as something that arrives whole. The announced length was never the constraint that mattered, because content encoding decides how much the receiver has to materialise. The HTTP client library decompresses transparently, so a small compressed body expands to an attacker-chosen decoded size in the server process before any size check applies. The same unbounded read is present in both implementations of the helper, the one using the synchronous HTTP client before 0.9.0 and the asynchronous one after it.
Against a real instance, as an account with the default user role:
Measured on that run: 260,934 bytes left the attacker's host, the server decoded 268,435,456 bytes, and the process grew from 730,980,352 to 2,163,429,376 bytes resident over 2.6 seconds.
@y4rvin, for the finding.
This page as .md · .json · CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.