PyPI · open-webui
Open WebUI: POST /api/v1/images/edit bypasses the global image-edit switch and the per-user image-generation permission
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.
An authenticated, non-admin user can:
ENABLE_IMAGE_EDIT=False administrator control;features.image_generation permission;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.
>= 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.
/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.
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.
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.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.