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.
References
jagstack Reporter
Classic298 Remediation developer
Summary
POST /api/v1/images/editperformed 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/generationsroute, the built-inedit_imagetool, 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:
ENABLE_IMAGE_EDIT=Falseadministrator control;features.image_generationpermission;IMAGES_EDIT_OPENAI_API_KEYfor 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/editroute was introduced in 0.8.11 and was ungated from the outset). Fixed in v0.10.0.Details
/api/v1/images/generationsenforcesENABLE_IMAGE_GENERATION(403 if globally disabled) andfeatures.image_generation(403 for non-admins without the permission). Theedit_imagebuilt-in tool and the chat image-edit middleware likewise gate onENABLE_IMAGE_EDITandfeatures.image_generation. The directPOST /api/v1/images/editroute ran onDepends(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) orfeatures.image_generationdenied for the user: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/editroute now enforcesENABLE_IMAGE_EDITand the per-userfeatures.image_generationpermission before delegating to the sharedimage_edits()implementation. The internal callers (theedit_imagetool and the chat middleware) call the implementation directly and already gate themselves, so they are unaffected.References