CVE-2026-59227: Open WebUI: image-edit API bypasses admin permission gate

GHSA-rqj7-6wrp-6g2g MEDIUM PoC AVAILABLE CISA: TRACK*
Published July 9, 2026
CISO Take

Open WebUI's image-edit endpoint (POST /api/v1/images/edit) checked only that the caller had a verified account, ignoring both the global switch meant to disable image editing and the per-user permission meant to gate who can generate images. In practice, any authenticated non-admin user — including a freshly self-registered account — could invoke server-side image editing using the administrator's configured provider credentials, whether or not that feature was supposed to be off or restricted for that user. There's no CISA KEV listing, no public exploit, and no Nuclei template, and EPSS sits at a low 0.26%, so this isn't being actively hunted; the CVSS vector (C:N/I:N/A:L) also confirms this is a resource/authorization failure rather than a data-exposure bug. The real exposure is cost and abuse: any signed-up user in a shared or multi-tenant Open WebUI deployment could burn an org's paid image-generation quota or misuse the provider account for unintended content, and this package already carries 130 other recorded CVEs, underscoring a broad attack surface. Patch to 0.10.0 now; until then, disable the image-edit provider integration or lock down signups/permissions so untrusted accounts can't reach it, and audit logs for POST /api/v1/images/edit calls from non-admin users.

Sources: NVD GitHub Advisory EPSS ATLAS

What is the risk?

Medium severity (CVSS 4.3) driven by low attack complexity and no user interaction required, offset by the fact that impact is confined to availability/resource abuse (A:L) with no confidentiality or integrity loss, and exploitation requires at least a verified low-privilege account (PR:L) rather than being fully unauthenticated. No active exploitation signals exist (not in CISA KEV, no SSVC decision, no public exploit or Nuclei template), and EPSS is low (0.26%), so this is a real but not urgent risk — the exposure is proportional to how many untrusted or self-registered users can reach a given Open WebUI instance and how sensitive/costly the configured image-generation provider credentials are.

How does the attack unfold?

Initial Access
Attacker obtains or self-registers a low-privilege, verified account on a public or multi-tenant Open WebUI instance.
AML.T0012
Exploitation
Attacker sends a direct POST request to /api/v1/images/edit, bypassing the global image-edit switch and per-user permission check that the UI would otherwise enforce.
AML.T0049
Impact
The server executes the image edit using the administrator's configured provider credentials, consuming paid quota and enabling unauthorized use of the AI image-generation service.
AML.T0034

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Open WebUI pip >= 0.8.11, < 0.10.0 0.10.0
149.6K 4 dependents Pushed 3d ago 81% patched ~6d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1
4.3 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 17% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
CISA SSVC: Public PoC
Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C None
I None
A Low

What should I do?

1 step
  1. Upgrade to Open WebUI 0.10.0 or later, where the fix (PR #26009, commit e038bab) properly enforces the global image-edit switch and per-user permission on POST /api/v1/images/edit. Until patched, disable the image generation/editing feature entirely at the admin config level if it isn't required for all users, or restrict new-account signups/verification so only trusted users hold accounts. Rotate and scope down the provider API credentials configured for image editing to limit blast radius, and review provider usage/billing logs for anomalous spikes. Post-patch, audit application logs for POST /api/v1/images/edit requests originating from non-admin accounts prior to the upgrade to check for prior abuse.

What does CISA's SSVC say?

Decision Track*
Exploitation poc
Automatable No
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.9 - Operational planning and control / access control for AI system resources
NIST AI RMF
GOVERN 1.5 - Access and authorization policies for AI system components
OWASP LLM Top 10
LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-59227?

Open WebUI's image-edit endpoint (POST /api/v1/images/edit) checked only that the caller had a verified account, ignoring both the global switch meant to disable image editing and the per-user permission meant to gate who can generate images. In practice, any authenticated non-admin user — including a freshly self-registered account — could invoke server-side image editing using the administrator's configured provider credentials, whether or not that feature was supposed to be off or restricted for that user. There's no CISA KEV listing, no public exploit, and no Nuclei template, and EPSS sits at a low 0.26%, so this isn't being actively hunted; the CVSS vector (C:N/I:N/A:L) also confirms this is a resource/authorization failure rather than a data-exposure bug. The real exposure is cost and abuse: any signed-up user in a shared or multi-tenant Open WebUI deployment could burn an org's paid image-generation quota or misuse the provider account for unintended content, and this package already carries 130 other recorded CVEs, underscoring a broad attack surface. Patch to 0.10.0 now; until then, disable the image-edit provider integration or lock down signups/permissions so untrusted accounts can't reach it, and audit logs for POST /api/v1/images/edit calls from non-admin users.

Is CVE-2026-59227 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-59227, increasing the risk of exploitation.

How to fix CVE-2026-59227?

Upgrade to Open WebUI 0.10.0 or later, where the fix (PR #26009, commit e038bab) properly enforces the global image-edit switch and per-user permission on POST /api/v1/images/edit. Until patched, disable the image generation/editing feature entirely at the admin config level if it isn't required for all users, or restrict new-account signups/verification so only trusted users hold accounts. Rotate and scope down the provider API credentials configured for image editing to limit blast radius, and review provider usage/billing logs for anomalous spikes. Post-patch, audit application logs for POST /api/v1/images/edit requests originating from non-admin accounts prior to the upgrade to check for prior abuse.

What systems are affected by CVE-2026-59227?

This vulnerability affects the following AI/ML architecture patterns: model serving, self-hosted AI web UIs, multi-tenant AI platforms.

What is the CVSS score for CVE-2026-59227?

CVE-2026-59227 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.26%.

What is the AI security impact?

Affected AI Architectures

model servingself-hosted AI web UIsmulti-tenant AI platforms

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0034 Cost Harvesting
AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.9
NIST AI RMF: GOVERN 1.5
OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.8.11 before 0.10.0, POST /api/v1/images/edit required only a verified account and did not enforce the global image-edit switch or the per-user image-generation permission, allowing a non-admin user to invoke server-side image editing with administrator-configured provider credentials. This issue is fixed in version 0.10.0.

Exploitation Scenario

An attacker with (or who creates) a low-privilege, verified account on a public-facing or multi-tenant Open WebUI instance simply sends a direct POST request to /api/v1/images/edit with image data, without ever checking whether the UI exposes that feature to them. Because the server-side check only verifies account status and not the global feature flag or the user's image-generation permission, the request succeeds and the server executes the edit using the admin-configured provider credentials — consuming the organization's paid API quota, potentially generating policy-violating content under the org's provider account, or serving as a low-cost resource-abuse vector against the victim's AI service budget.

Weaknesses (CWE)

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

  • [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

Timeline

Published
July 9, 2026
Last Modified
July 24, 2026
First Seen
July 9, 2026

Related Vulnerabilities