Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
PYSEC-2026-2768
No affected components available
Summary
The API /api/v1/notes/{note_id} endpoint lacks proper authorization checks, allowing authenticated users to retrieve notes belonging to other users by guessing or enumerating UUIDs. This results in unauthorized disclosure of potentially sensitive or private user data.
Details
- if notes is enabled from UI (Settings >> General >> Features >> Notes (Beta))
- From API, attacker can access other user notes
- if notes is disabled from UI (Settings >> General >> Features >> Notes (Beta))
- Then attacker can enable the notes from /api/config and access other user notes
PoC
-
Step 1: Log in to the application as a valid user (User A).
-
Step 2: Intercept or inspect the response from the endpoint GET /api/config.
-
Step 3: Observe the field "enable_notes": false in the JSON response.
-
Step 4: Manually change "enable_notes" to true using browser DevTools or by intercepting and modifying the response via a proxy like Burp Suite. (Please note, the occurrence of this API comes twice, hence modification needs to be made twice as well.)
-
Step 5: Observe the loaded frontend application; the previously hidden notes form will now be visible.
- Step 6: Again, click on any note, intercept the request, and Replace the note_id in the URL with a different note ID known to belong to another user (e.g., by guessing or bruteforcing).
- Step 7: Send the modified request while remaining logged in as User A.
- Step 8: Observe that the server returns the content of another user's note, confirming unauthorized access.
Impact
- Unauthorized access to user-created notes
- Possible exposure of confidential or sensitive uploaded data
- Violation of user privacy and data isolation
- High risk of legal or compliance breaches in regulated environments
Resolution
Fixed in commit de3317e26, first released in v0.8.11 (Mar 2026). All per-id note endpoints (GET /api/v1/notes/{id}, POST /api/v1/notes/{id}/update, POST /api/v1/notes/{id}/access/update, deletion) now enforce ownership: the handler fetches the note, then requires the caller to be admin, the note owner, or have an AccessGrants grant for the appropriate permission (read for retrieval, write for mutation). A non-owner with no grant receives 403.
Users on >= 0.8.11 are not affected.
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker needs basic access or low-level privileges. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the confidentiality of the information.
Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard