CVE-2026-59226
Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 before 0.10.0, execute_automation rehydrate
CVSS
3.1
Bajo
EPSS
0.3%
p23
KEV
—
Exploit Today
7
0-100
Publicado: 9 jul 2026 · Última mod.: 10 jul 2026 · CWE-285 · CWE-862 · CWE-863
0.3%EPSS · 30 días0.3%
2026-08-122026-09-09
Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 before 0.10.0, execute_automation rehydrated automation owners without rechecking that they were still active or still had features.automations, and check_model_access only enforced private-model grants for the exact user role, allowing deactivated pending users to continue scheduled model execution. This issue is fixed in version 0.10.0.
- github.comhttps://github.com/open-webui/open-webui/commit/920b655f4689e2118de928fbc936f6ebd4fed396
- github.comhttps://github.com/open-webui/open-webui/pull/26047
- github.comhttps://github.com/open-webui/open-webui/releases/tag/v0.10.0
- github.comhttps://github.com/open-webui/open-webui/security/advisories/GHSA-mvx4-532p-xfm9
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-464603.5 BAJ—
——0Dell PowerScale OneFS, versions 9.5.0.0 through 9.7.1.15, versions 9.8.0.0 through 9.13.1.0, and versions prior to 9.15.0.0, contain an Incorrect Authorization vulnerability. A low privileged adjacent network attacker could potentially exploit this vulnerability, leading to unauthorized modification of system logs.1dCVE-2026-68484——
——0Cash Collect contains an improper authorization vulnerability in the Sage AR Automation API. Administrative functions do not properly verify user privileges, allowing authenticated low-privileged users to create administrator accounts and obtain elevated privileges.1dCVE-2026-867735.4 MED—
——0Snipe-IT through version 8.6.3 fails to perform object-level authorization in the updateLicense, updateConsumable, updateAccessory, and updateModel endpoints and in the storeModel endpoint for Predefined Kits. The existing check authorizes only the parent Predefined Kit (update on PredefinedKit) and not the child object being attached. As a result, an authenticated user holding only the kits.edit permission can attach a License, Consumable, Accessory, or Asset Model that they are otherwise denied (HTTP 403) from reading directly to a Predefined Kit, and the kit relation index then discloses the attached object's name back to that low-privilege user. This is the update-path and storeModel counterpart to CVE-2026-55478, which fixed only the storeLicense, storeConsumable, and storeAccessory methods in 8.6.2. Note that updateModel was code-vulnerable in 8.6.3 but not reachable in practice because a route-name typo bound the route to a nonexistent controller method, causing HTTP 500 responses. The issue is fixed in Snipe-IT 8.7.0.1dCVE-2026-867656.5 MED—
——0Snipe-IT versions before 8.7.0 fail to enforce checkout authorization when assignment fields are submitted to the asset update endpoint. Authenticated users with edit permission but explicitly denied checkout permission can reassign assets, bypass check-in procedures, and alter custody records by submitting assigned_user, assigned_asset, or assigned_location parameters to PATCH /api/v1/hardware/{id}.1dCVE-2026-867646.5 MED—
——0Snipe-IT through 8.6.4 (fixed in 8.7.0) does not enforce the components.view permission on the authenticated endpoint GET /api/v1/hardware/<asset-id>/assigned/components. The endpoint authorizes only assets.view on the parent asset before returning linked component details; the components.view check is applied only to the response's available_actions.view flag and not to the returned data. As a result, an authenticated user holding only assets.view can enumerate component IDs, names, assigned quantities, and notes that are otherwise protected — the direct GET /api/v1/components/<id> endpoint correctly returns 403 Forbidden for such users.1dCVE-2026-867628.1 ALT—
——0Snipe-IT before 8.7.0 does not apply the CheckUserIsActivated middleware to the `api` middleware group in app/Http/Kernel.php, and deactivating a user does not revoke that user's Passport personal access tokens. As a result, although a deactivated account is correctly refused at web login, its existing API token continues to authenticate and to grant read and write access to the REST API (assets, users, licenses, etc.) at the account's prior permission level until the token expires. A deactivated account that retains user-management permissions can re-activate itself through the API, permanently defeating the deactivation control.1d