CVE-2026-59227: Open WebUI: POST /api/v1/images/edit bypasses the global image-edit switch and the per-user image-generation permission

The route was added in 0.8.11 and was never gated. It runs on Depends(get_verified_user) alone and goes straight to provider dispatch. Every other image surface checks the controls: /api/v1/images/generations returns 403 when ENABLE_IMAGE_GENERATION is off or features.image_generation is denied, and the edit_image built-in tool and chat image-edit middleware check ENABLE_IMAGE_EDIT and the same permission.

A non-admin user sends a JSON body with a base64 image, a prompt and a model such as gpt-image-1. The server forwards it to the configured OpenAI-compatible, Gemini or ComfyUI provider and returns the edited image, even when the admin set ENABLE_IMAGE_EDIT=False or denied the user the permission. The UI exposes image editing only to admins (Playground), so this reaches an admin-only capability.

The damage is limited. No other user's data is exposed, and the provider keys, such as IMAGES_EDIT_OPENAI_API_KEY, are never returned. What the attacker gets is the bypass of the control and provider spend charged to the admin. The CVSS score is 4.3, with low availability impact.

The open-webui pip package, versions >= 0.8.11, < 0.10.0. The advisory says the route was ungated from its introduction. Instances matter most when an image-edit provider is configured with paid credentials and the instance has users beyond admins.

pip show open-webui

For Docker, check the image tag.

Upgrade to open-webui 0.10.0.

pip install --upgrade open-webui==0.10.0

The fix is pull request 26009. A thin /edit route now enforces ENABLE_IMAGE_EDIT and the per-user features.image_generation permission, then calls the shared image_edits() implementation. The tool and the chat middleware call the implementation directly, so they are unchanged. The advisory gives no workaround. If you cannot upgrade, block POST /api/v1/images/edit at the reverse proxy for non-admin users, and set a spend cap with the provider.

Search access logs for POST /api/v1/images/edit from non-admin accounts, and especially any that succeeded while ENABLE_IMAGE_EDIT is False. Compare image-edit usage and spend at the provider (OpenAI, Gemini or ComfyUI) with the users who are allowed to edit images.

Summary

POST /api/v1/images/edit performed no authorization beyond requiring a verified account. Every other image-editing surface in Open WebUI enforces the global image-edit switch and the per-user image-generation permission — the /api/v1/images/generations route, the built-in edit_image tool, and the chat image-edit middleware — but the direct edit route enforced neither. A verified non-admin user could therefore invoke server-side image editing, reaching the configured image-edit provider with the administrator's credentials, even when the administrator had globally disabled image editing (ENABLE_IMAGE_EDIT=False) or denied that user image-generation permission. The image-editing UI is surfaced only to administrators (Playground), so the route additionally exposed an admin-only capability to any verified user.

Impact

An authenticated, non-admin user can:

• bypass the global ENABLE_IMAGE_EDIT=False administrator control;
• bypass a denied per-user/group features.image_generation permission;
• cause the server to send billable image-edit requests to the configured provider (OpenAI-compatible, Gemini, or ComfyUI) using administrator-configured credentials (IMAGES_EDIT_OPENAI_API_KEY for the OpenAI engine).

No cross-user data is exposed and the provider credentials are never returned to the caller; the impact is the control/permission bypass and the associated billable resource consumption.

Affected Versions

>= 0.8.11, < 0.10.0 (the /api/v1/images/edit route was introduced in 0.8.11 and was ungated from the outset). Fixed in v0.10.0.

Details

/api/v1/images/generations enforces ENABLE_IMAGE_GENERATION (403 if globally disabled) and features.image_generation (403 for non-admins without the permission). The edit_image built-in tool and the chat image-edit middleware likewise gate on ENABLE_IMAGE_EDIT and features.image_generation. The direct POST /api/v1/images/edit route ran on Depends(get_verified_user) alone and proceeded straight to provider dispatch, applying none of these controls.

Proof of Concept

As a verified non-admin user, with image editing globally disabled (ENABLE_IMAGE_EDIT=False) or features.image_generation denied for the user:

POST /api/v1/images/edit
Authorization: Bearer <non_admin_user_token>
Content-Type: application/json

{"image":"data:image/png;base64,<png>","prompt":"edit","model":"gpt-image-1"}

The request reaches the configured image-edit provider and returns an edited image despite the disabled control/permission.

Patch

The direct route is split from its shared implementation (mirroring generate_images/image_generations): a thin /edit route now enforces ENABLE_IMAGE_EDIT and the per-user features.image_generation permission before delegating to the shared image_edits() implementation. The internal callers (the edit_image tool and the chat middleware) call the implementation directly and already gate themselves, so they are unaffected.