CVE-2026-59227 is a medium-severity (CVSS 4.3) CWE-862 vulnerability in open-webui. A fix is available for open-webui — see the affected versions and patch details below.
Open WebUI: POST /api/v1/images/edit bypasses the global image-edit switch and the per-user image-generation permission
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-59227.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-59227 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 395,249 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
open-webuiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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=Falseadministrator control; - bypass a denied per-user/group
features.image_generationpermission; - 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_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/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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | open-webui | ≥ 0.8.11&&< 0.10.0 | 0.10.0pip install --upgrade 'open-webui==0.10.0' |
Affected Products
open webuiopenwebuiDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for open-webui, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update open-webui to 0.10.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-59227 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is CVE-2026-59227 in your dependencies?
Find it across PyPI, including transitive dependencies.