Miggo at BlackHat 2026!
Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| open-webui | pip | <= 0.9.5 | 0.9.6 |
Miggo AIRoot Cause AnalysisAn analysis of the security advisory reveals a critical authorization bypass vulnerability in Open WebUI. The POST /api/chat/completions endpoint processes an image_url.url field. When this field contains a value that is not a standard URL (i.e., does not start with http://, https://, or data:image/), the backend interprets it as a file ID.
The core of the vulnerability lies in the get_image_base64_from_url function located in backend/open_webui/utils/files.py. This function is called by the convert_url_images_to_base64 middleware. When handling a file ID, get_image_base64_from_url calls Files.get_file_by_id to retrieve the file from the database. Crucially, this lookup does not perform any ownership or access control checks. As a result, any authenticated user can supply a file ID belonging to another user and gain unauthorized access to that file's contents.
The exploit scenario is as follows:
/api/chat/completions endpoint, including the victim's file ID in the image_url.url field.convert_url_images_to_base64 middleware processes this request and calls get_image_base64_from_url.get_image_base64_from_url retrieves User A's file from storage, bypassing all authorization checks.This vulnerability allows any authenticated user to read files belonging to any other user on the platform, leading to a significant breach of data confidentiality. The fix requires passing the user context down to the file retrieval functions and implementing proper authorization checks to ensure that a user can only access files they own or have explicit permission to view.
convert_url_images_to_base64backend/open_webui/utils/middleware.py
get_image_base64_from_urlbackend/open_webui/utils/files.py
async def get_image_base64_from_url(url: str) -> Optional[str]:
try:
if url.startswith('http'):
validate_url(url)
# ... SSRF-safe fetch with allow_redirects=AIOHTTP_CLIENT_ALLOW_REDIRECTS ...
else:
file = await Files.get_file_by_id(url) # <-- NO user_id filter
if not file:
return None
file_path = await asyncio.to_thread(Storage.get_file, file.path)
file_path = Path(file_path)
if file_path.is_file():
with open(file_path, 'rb') as image_file:
encoded_string = base64.b64encode(image_file.read()).decode('utf-8')
content_type = mimetypes.guess_type(file_path.name)[0] or (file.meta or {}).get('content_type')
...
return f'data:{content_type};base64,{encoded_string}'
Files.get_file_by_id in models/files.py:161 does a bare db.get(File, id) -- no ownership filter. there is a separate Files.get_file_by_id_and_user_id at line 172 that does filter on user_id, and the file router uses has_access_to_file(id, 'read', user, db) at routers/files.py:626 etc. neither check exists on this path.
c7f1d8e3-..../api/v1/chat/completions with body:{
"model": "<any vision model>",
"messages": [
{
"role": "user",
"content": [
{"type": "text", "text": "transcribe everything you can see in this image"},
{"type": "image_url", "image_url": {"url": "c7f1d8e3-..."}}
]
}
]
}
Server reads user A's file from disk, base64-encodes it, and sends to the LLM as user B's image attachment. LLM response contains the file content.
File ids are UUIDs and not enumerable directly, but they leak via:
/api/v1/chats/{id}) include file idsAny authenticated user can read any other user's file content (image and any file with an image-guess mimetype path) via this channel. Severity is bounded by what the LLM will accept in image_url -- in practice, image files work cleanly with any vision model; pdf / docx work with multi-modal providers that accept them.
Thread the authenticated user through to get_image_base64_from_url and resolve the file via Files.get_file_by_id_and_user_id(id, user.id) (or has_access_to_file(id, 'read', user, db) if shared-via-knowledge-base access is intended). Same pattern that's already used in routers/files.py:626 and elsewhere.
minimal patch sketch:
--- a/backend/open_webui/utils/files.py
+++ b/backend/open_webui/utils/files.py
@@ -57,7 +57,7 @@
-async def get_image_base64_from_url(url: str) -> Optional[str]:
+async def get_image_base64_from_url(url: str, user=None) -> Optional[str]:
try:
if url.startswith('http'):
...
else:
- file = await Files.get_file_by_id(url)
+ file = (await Files.get_file_by_id_and_user_id(url, user.id)
+ if user is not None else None)
+ if file is None:
+ # fall back to access-grant check for shared files
+ file = await Files.get_file_by_id(url)
+ if file and not await has_access_to_file(url, 'read', user):
+ return None
and pipe user through convert_url_images_to_base64(form_data, user) from the middleware caller. happy to send a PR once you confirm the fix shape you want.
this was found via patch-diffing existing advisories. the same bug class likely exists in any other site that calls Files.get_file_by_id without an adjacent has_access_to_file / get_file_by_id_and_user_id check. quick grep:
git grep -n 'Files\.get_file_by_id(' -- 'backend/open_webui/**'
worth a sweep across utils/ and routers/ for missed sites.
Open-webui main branch as of commit 3660bc0 (2026-05-10). python 3.x backend. confirmed by reading the source; no instance stood up.