CVE-2026-44561: Open WebUI: Deactivated Channel Members Retain Full Access to Group/DM Channels
Deactivated Channel Members Retain Full Access to Group/DM Channels Affected Component Channel membership authorization check: - backend/openwebui/models/channels.py (lines 663-673, isuserchannelmember) - Used at 15 locations in backend/openwebui/routers/channels.py Affected Versions Current main branch (commit 6fdd19bf1) and likely all versions with the group/DM channel feature.
Published May 8, 2026 · Updated May 15, 2026
Affected packages
open-webui
- Ecosystem
- PyPI
- Affected
- <= 0.8.12
- Fixed in
- 0.9.0
- Check
pip show open-webui
Advisory details
From the GitHub Advisory Database (CC BY 4.0).
Deactivated Channel Members Retain Full Access to Group/DM Channels
Affected Component
Channel membership authorization check:
backend/open_webui/models/channels.py(lines 663-673,is_user_channel_member)- Used at 15 locations in
backend/open_webui/routers/channels.py
Affected Versions
Current main branch (commit 6fdd19bf1) and likely all versions with the group/DM channel feature.
Description
The is_user_channel_member function checks whether a ChannelMember row exists but does not check the is_active field. When a user is deactivated from a group or DM channel (removed by the channel owner, or leaves voluntarily), their membership row persists with is_active=False and status='left'. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls.
The channel correctly disappears from the deactivated user's channel list (the listing query at get_channels_by_user_id properly filters on is_active), but all 15 message-level endpoints in the router rely on is_user_channel_member for authorization, which does not filter on is_active.
# models/channels.py:663 — missing is_active check
def is_user_channel_member(self, channel_id, user_id, db=None):
membership = db.query(ChannelMember).filter(
ChannelMember.channel_id == channel_id,
ChannelMember.user_id == user_id,
).first()
return membership is not None # True even when is_active=FalseCompare with get_channel_by_id_and_user_id (line 778) which correctly checks ChannelMember.is_active.is_(True).
CVSS 3.1 Breakdown
| Metric | Value | Rationale | | Attack Vector | Network (N) | Exploited remotely via API calls | | Attack Complexity | Low (L) | No special conditions beyond knowing the channel ID (which the user had as a former member) | | Privileges Required | Low (L) | Requires a valid user account and prior channel membership | | User Interaction | None (N) | No victim interaction required | | Scope | Unchanged (U) | Impact is within the same authorization boundary (the channel) | | Confidentiality | Low (L) | Can read messages in a channel the user should no longer access | | Integrity | Low (L) | Can post, edit, and delete messages in the channel | | Availability | None (N) | No denial of service |
Attack Scenario
- User A and User B are members of a private group channel.
- The channel owner removes User B (or User B leaves). User B's membership is set to
is_active=False, status='left'. - The channel disappears from User B's UI — but User B noted the channel ID while they were a member.
- User B calls the API directly:
GET /api/v1/channels/{channel_id}/messages— reads all messages, including those posted after deactivationPOST /api/v1/channels/{channel_id}/messages/post— posts new messagesPOST /api/v1/channels/{channel_id}/messages/{id}/update— edits messagesDELETE /api/v1/channels/{channel_id}/messages/{id}/delete— deletes messages- All requests succeed because
is_user_channel_memberreturnsTrue.
Impact
- Deactivated users can continue reading all new messages posted after their removal (confidentiality breach)
- Deactivated users can post, edit, and delete messages (integrity breach)
- The deactivation mechanism provides a false sense of security — channel owners believe removed users have lost access
Preconditions
- Channels feature must be enabled (disabled by default)
- Attacker must have a valid user account
- Attacker must have been a member of the channel at some point (and thus knows the channel ID)
Recommended Fix
Add is_active filtering to is_user_channel_member:
def is_user_channel_member(self, channel_id, user_id, db=None):
membership = db.query(ChannelMember).filter(
ChannelMember.channel_id == channel_id,
ChannelMember.user_id == user_id,
ChannelMember.is_active.is_(True),
).first()
return membership is not NoneThis aligns it with the existing get_channel_by_id_and_user_id method which already applies this filter correctly.
Credited to Classic298.
References
How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. No analysis has been written for this entry yet. Methodology
More Open WebUI vulnerabilities
All Open WebUI entriesCVE-2026-87011
Open WebUI: Unauthenticated requests can stall the server via uncached OIDC fetches in back-channel logout
high7.5Sep 10, 2026CVE-2026-87012
Open WebUI: Any authenticated user can suppress calendar alerts instance-wide via a non-numeric alert value
medium4.3Sep 10, 2026CVE-2026-87013
Open WebUI: Any authenticated user can start a non-terminating request via a folder parent cycle
medium4.3Sep 10, 2026CVE-2026-87014
Open WebUI: Admin demoted through SSO role sync keeps read and write access to all users' notes
medium6.5Sep 10, 2026CVE-2026-87015
Open WebUI: A user's session cookies are sent to tool servers configured for bearer authentication
medium6.8Sep 10, 2026CVE-2026-87016
Open WebUI: Sign-in as another user via wildcard characters in the OAuth subject claim on SQLite
high8.1Sep 10, 2026
