https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 14 Oct 2026 19:32:14 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-09662 bdu:2026-09662 https://cve.radiocsirt.org/vuln/bdu:2026-09662 https://cve.radiocsirt.org/vuln/euvd-2026-319078 EUVD-2026-319078 https://cve.radiocsirt.org/vuln/euvd-2026-319078 https://cve.radiocsirt.org/vuln/fkie_cve-2026-44561 <p>Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.0, 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=&#39;left&#39;. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls. This vulnerability is fixed in 0.9.0.</p> <p>Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.0, 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=&#39;left&#39;. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls. This vulnerability is fixed in 0.9.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-44561 https://cve.radiocsirt.org/vuln/ghsa-hmgr-67hw-j2cq <p><strong>Affected:</strong> PyPI: open-webui</p> <p># Deactivated Channel Members Retain Full Access to Group/DM Channels</p> <p>## Affected Component</p> <p>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`</p> <p>## Affected Versions</p> <p>Current main branch (commit `6fdd19bf1`) and likely all versions with the group/DM channel feature.</p> <p>## Description</p> <p>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=&#39;left&#39;`. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls.</p> <p>The channel correctly disappears from the deactivated user&#39;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`.</p> <p>```python # 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…</p> <p><strong>Affected:</strong> PyPI: open-webui</p> <p># Deactivated Channel Members Retain Full Access to Group/DM Channels</p> <p>## Affected Component</p> <p>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`</p> <p>## Affected Versions</p> <p>Current main branch (commit `6fdd19bf1`) and likely all versions with the group/DM channel feature.</p> <p>## Description</p> <p>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=&#39;left&#39;`. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls.</p> <p>The channel correctly disappears from the deactivated user&#39;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`.</p> <p>```python # 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…</p> https://cve.radiocsirt.org/vuln/ghsa-hmgr-67hw-j2cq https://cve.radiocsirt.org/vuln/pysec-2026-2732 <p><strong>Affected:</strong> PyPI: open-webui</p> <p># Deactivated Channel Members Retain Full Access to Group/DM Channels</p> <p>## Affected Component</p> <p>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`</p> <p>## Affected Versions</p> <p>Current main branch (commit `6fdd19bf1`) and likely all versions with the group/DM channel feature.</p> <p>## Description</p> <p>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=&#39;left&#39;`. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls.</p> <p>The channel correctly disappears from the deactivated user&#39;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`.</p> <p>```python # 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…</p> <p><strong>Affected:</strong> PyPI: open-webui</p> <p># Deactivated Channel Members Retain Full Access to Group/DM Channels</p> <p>## Affected Component</p> <p>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`</p> <p>## Affected Versions</p> <p>Current main branch (commit `6fdd19bf1`) and likely all versions with the group/DM channel feature.</p> <p>## Description</p> <p>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=&#39;left&#39;`. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls.</p> <p>The channel correctly disappears from the deactivated user&#39;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`.</p> <p>```python # 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…</p> https://cve.radiocsirt.org/vuln/pysec-2026-2732