CVE-2026-44561

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=False

Compare with get_channel_by_id_and_user_id (line 778) which correctly checks ChannelMember.is_active.is_(True).

CVSS 3.1 Breakdown

Attack Scenario

1. User A and User B are members of a private group channel.
2. The channel owner removes User B (or User B leaves). User B's membership is set to is_active=False, status='left'.
3. The channel disappears from User B's UI, but User B noted the channel ID while they were a member.
4. User B calls the API directly:
   • GET /api/v1/channels/{channel_id}/messages, reads all messages, including those posted after deactivation
   • POST /api/v1/channels/{channel_id}/messages/post, posts new messages
   • POST /api/v1/channels/{channel_id}/messages/{id}/update, edits messages
   • DELETE /api/v1/channels/{channel_id}/messages/{id}/delete, deletes messages
5. All requests succeed because is_user_channel_member returns True.

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)

• 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

The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.

CVE-2026-44561 has a CVSS score of 5.4 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.9.0); upgrading removes the vulnerable code path.

Kodem intelligence

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 None

This aligns it with the existing get_channel_by_id_and_user_id method which already applies this filter correctly.

1. What is CVE-2026-44561? CVE-2026-44561 is a medium-severity incorrect authorization vulnerability in open-webui (pip), affecting versions <= 0.8.12. It is fixed in 0.9.0. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
2. How severe is CVE-2026-44561? CVE-2026-44561 has a CVSS score of 5.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of open-webui are affected by CVE-2026-44561? open-webui (pip) versions <= 0.8.12 is affected.
4. Is there a fix for CVE-2026-44561? Yes. CVE-2026-44561 is fixed in 0.9.0. Upgrade to this version or later.
5. Is CVE-2026-44561 exploitable, and should I be worried? Whether CVE-2026-44561 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-44561 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-44561? Upgrade open-webui to 0.9.0 or later.