<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 13:39:29 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-54006 — Open WebUI: Calendar event re-parenting allows writing events into another user's calendar</title>
      <link>https://db.gcve.eu/vuln/cve-2026-54006</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; open-webui&lt;/p&gt;
&lt;p&gt;Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.6, POST /api/v1/calendars/events/{event_id}/update validates that the caller has write access to the calendar the event currently belongs to, but does not validate the destination calendar_id supplied in the request body. The model layer then persists the new calendar_id unconditionally. A regular user-role account can therefore create an event in their own calendar and immediately move it into any other user&amp;#39;s calendar whose ID they know — bypassing the authorization check that create_event correctly performs.  This vulnerability is fixed in 0.9.6.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; open-webui&lt;/p&gt;
&lt;p&gt;Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.6, POST /api/v1/calendars/events/{event_id}/update validates that the caller has write access to the calendar the event currently belongs to, but does not validate the destination calendar_id supplied in the request body. The model layer then persists the new calendar_id unconditionally. A regular user-role account can therefore create an event in their own calendar and immediately move it into any other user&amp;#39;s calendar whose ID they know — bypassing the authorization check that create_event correctly performs.  This vulnerability is fixed in 0.9.6.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-54006</guid>
    </item>
    <item>
      <title>GHSA-f3g7-59qc-pqg6 — Open WebUI IDOR: Calendar event re-parenting allows writing events into another user's calendar</title>
      <link>https://db.gcve.eu/vuln/ghsa-f3g7-59qc-pqg6</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: open-webui&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`POST /api/v1/calendars/events/{event_id}/update` validates that the caller has **write** access to the calendar the event *currently* belongs to, but does not validate the **destination** `calendar_id` supplied in the request body. The model layer then persists the new `calendar_id` unconditionally.&lt;/p&gt;
&lt;p&gt;A regular `user`-role account can therefore create an event in their own calendar and immediately move it into any other user&amp;#39;s calendar whose ID they know — bypassing the authorization check that `create_event` correctly performs. This is reachable on **default configuration**: `ENABLE_CALENDAR` and `USER_PERMISSIONS_FEATURES_CALENDAR` both default to `True`.&lt;/p&gt;
&lt;p&gt;### Details
### Sink — missing destination check&lt;/p&gt;
&lt;p&gt;`backend/open_webui/routers/calendar.py:283-297`&lt;/p&gt;
&lt;p&gt;```python
@router.post(&amp;#39;/events/{event_id}/update&amp;#39;, response_model=CalendarEventModel)
async def update_event(
    request: Request, event_id: str, form_data: CalendarEventUpdateForm,
    user: UserModel = Depends(get_verified_user)
):
    await check_calendar_permission(request, user)
    event = await CalendarEvents.get_event_by_id(event_id)
    if not event:
        raise HTTPException(status_code=404, detail=&amp;#39;Event not found&amp;#39;)&lt;/p&gt;
&lt;p&gt;await _check_calendar_access(event.calendar_id, user, &amp;#39;write&amp;#39;)   # ← SOURCE only&lt;/p&gt;
&lt;p&gt;updated = await CalendarEvents.update_event_by_id(event_id, form_data)  # ← writes form_data.calendar_id
    ...
```&lt;/p&gt;
&lt;p&gt;`backend/open_webui/models/calendar.py:658-693` (`update_event_by_id`)&lt;/p&gt;
&lt;p&gt;``…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: open-webui&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`POST /api/v1/calendars/events/{event_id}/update` validates that the caller has **write** access to the calendar the event *currently* belongs to, but does not validate the **destination** `calendar_id` supplied in the request body. The model layer then persists the new `calendar_id` unconditionally.&lt;/p&gt;
&lt;p&gt;A regular `user`-role account can therefore create an event in their own calendar and immediately move it into any other user&amp;#39;s calendar whose ID they know — bypassing the authorization check that `create_event` correctly performs. This is reachable on **default configuration**: `ENABLE_CALENDAR` and `USER_PERMISSIONS_FEATURES_CALENDAR` both default to `True`.&lt;/p&gt;
&lt;p&gt;### Details
### Sink — missing destination check&lt;/p&gt;
&lt;p&gt;`backend/open_webui/routers/calendar.py:283-297`&lt;/p&gt;
&lt;p&gt;```python
@router.post(&amp;#39;/events/{event_id}/update&amp;#39;, response_model=CalendarEventModel)
async def update_event(
    request: Request, event_id: str, form_data: CalendarEventUpdateForm,
    user: UserModel = Depends(get_verified_user)
):
    await check_calendar_permission(request, user)
    event = await CalendarEvents.get_event_by_id(event_id)
    if not event:
        raise HTTPException(status_code=404, detail=&amp;#39;Event not found&amp;#39;)&lt;/p&gt;
&lt;p&gt;await _check_calendar_access(event.calendar_id, user, &amp;#39;write&amp;#39;)   # ← SOURCE only&lt;/p&gt;
&lt;p&gt;updated = await CalendarEvents.update_event_by_id(event_id, form_data)  # ← writes form_data.calendar_id
    ...
```&lt;/p&gt;
&lt;p&gt;`backend/open_webui/models/calendar.py:658-693` (`update_event_by_id`)&lt;/p&gt;
&lt;p&gt;``…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-f3g7-59qc-pqg6</guid>
    </item>
  </channel>
</rss>
