How severe is GHSA-rqj7-6wrp-6g2g?

GHSA-rqj7-6wrp-6g2g has a CVSS score of 4.3/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-rqj7-6wrp-6g2g?

GHSA-rqj7-6wrp-6g2g affects the following packages: open-webui (PyPI). Ecosystems affected: PyPI.

How do I fix GHSA-rqj7-6wrp-6g2g?

Update open-webui to 0.10.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rqj7-6wrp-6g2g is resolved across your whole dependency graph.

How do I detect GHSA-rqj7-6wrp-6g2g in my PyPI dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for open-webui. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-rqj7-6wrp-6g2g if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-rqj7-6wrp-6g2g?

O3 pinpoints whether GHSA-rqj7-6wrp-6g2g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-rqj7-6wrp-6g2g actively exploited in the wild?

No public exploit code has been indexed for GHSA-rqj7-6wrp-6g2g yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What type of vulnerability is GHSA-rqj7-6wrp-6g2g?

GHSA-rqj7-6wrp-6g2g is classified as CWE-862 (CWE-862), CWE-863 (CWE-863). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-rqj7-6wrp-6g2g published, and has it been updated?

GHSA-rqj7-6wrp-6g2g was published on July 24, 2026 and was last updated on July 24, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐍 PyPI

GHSA-rqj7-6wrp-6g2g

MEDIUM

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

Also known asCVE-2026-59227

Published

Jul 24, 2026

Updated

Jul 24, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🐍open-webui

Real-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=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.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐍PyPI	`open-webui`	≥ 0.8.11&&< 0.10.0	0.10.0

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for open-webui. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update open-webui to 0.10.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rqj7-6wrp-6g2g is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-rqj7-6wrp-6g2g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-rqj7-6wrp-6g2g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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 ima

O3 Security · Impact-Aware SCA

Is GHSA-rqj7-6wrp-6g2g in your dependencies?

O3 detects GHSA-rqj7-6wrp-6g2g across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works