GHSA-jx2x-j75f-xq3j

Описание

Summary

The POST /api/v1/notes/{id}/pin endpoint performs a write operation (toggling the is_pinned field) but only checks for read permission. Users with read-only access to a shared note can pin/unpin it, which is a state-modifying action that should require write permission. All other write endpoints (update, delete, access/update) correctly check for write permission.

Details

Affected code: backend/open_webui/routers/notes.py lines 412-444

Compare with update endpoint (correct, line 318-327):

PoC

Environment: Open WebUI v0.9.2, default configuration with notes sharing enabled.

Setup:

1. UserA creates a note
2. UserA shares note with UserB with read permission via POST /api/v1/notes/{id}/access/update with {"access_grants":[{"principal_type":"user","principal_id":"USERB_ID","permission":"read"}]}

Test:

E2E Verified Result:

• Step 1: UserB reads note (READ) -> 200 OK ✓
• Step 2: UserB updates note (WRITE) -> 403 Forbidden ✓ (correctly blocked)
• Step 3: UserB pins note (WRITE via READ) -> 200 OK, is_pinned: true ✗ (BUG)
• Step 4: UserB toggles pin again -> 200 OK, is_pinned: false ✗ (repeated write)

Impact

• A user with only read access to a shared note can toggle its is_pinned status
• This modifies the note's state without write authorization
• The pin status change is visible to the note owner and all other users with access
• Privilege escalation from read to write on the pin operation

Limitations: Only affects the is_pinned boolean field. Cannot modify title, content, or access_grants. Requires at least read access via explicit sharing.

Fix

One-line fix — change permission='read' to permission='write' in pin_note_by_id:

This makes the pin endpoint consistent with update and delete endpoints.