CVE-2026-44558Medium· 5.4▾ SunlitOpen WebUI's Channel Access Grants Bypass filter_allowed_access_grants
▾ Sunlit zone — Low / medium · no exploitation signal
impact 29.7 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 13.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
0.2%
Channel creation and update endpoints:
backend/open_webui/routers/channels.py (lines 291-340, create_new_channel)backend/open_webui/routers/channels.py (lines 617-638, update_channel_by_id)backend/open_webui/models/channels.py (lines 825-826, set_access_grants call without filtering)Current main branch (commit 6fdd19bf1) and likely all versions supporting user-created group channels with access grants.
All resource routers in Open WebUI (knowledge, models, notes, prompts, tools, skills) call filter_allowed_access_grants() before persisting access grants. This function strips principal_id: "*" wildcard grants from users who lack the relevant sharing.public_* permission, and strips individual user grants from users who lack access_grants.allow_users permission.
The channel router does not call filter_allowed_access_grants on either create or update paths. A non-admin user who can create group channels (or who owns a channel) can submit arbitrary access grants — including public wildcard grants — and those grants are stored verbatim, bypassing the admin's permission framework.
# channels.py — access_grants from form data flow directly into persistence
# No call to filter_allowed_access_grants() anywhere in these paths.
# Compare with knowledge.py / models.py / notes.py / prompts.py / tools.py / skills.py,
# all of which do:
# form_data.access_grants = filter_allowed_access_grants(user, form_data.access_grants)
# before creating or updating.
sharing.public_channels — public sharing of channels is intended to be admin-only.POST /api/v1/channels/
{
"name": "public-channel",
"type": "group",
"access_control": {
"access_grants": [
{"principal_type": "user", "principal_id": "*", "permission": "read"}
]
}
}
set_access_grants is called directly without filter_allowed_access_grants — the wildcard grant is persisted.The same attack works via POST /api/v1/channels/{id}/update for any channel the attacker owns.
sharing.public_channels permission and make channels publicly accessibleaccess_grants.allow_users to grant individual-user access in environments where only group-based sharing is intendedopen-webui < 0.9.0Upgrade to a patched release:
open-webui 0.9.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-56400High· 8.3Open WebUI has a CORS misconfiguration and session validation issue
CVE-2026-56398High· 7.3Open WebUI vulnerable to stored XSS via OAuth picture claim stored as SVG data URI in profile_image_url
CVE-2026-45666Medium· 6.5Open WebUI has an Indirect Object Reference (IDOR) in user notes
CVE-2026-45385Medium· 4.3Open WebUI has an IDOR vulnerability in the update_message_by_id API endpoint
CVE-2026-29071Low· 3.1Open WebUI's Insecure Direct Object Reference (IDOR) allows access to other users' memories
CVE-2026-28786Medium· 4.3Open WebUI vulnerable to Path Traversal in `POST /api/v1/audio/transcriptions`