https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 18 Oct 2026 23:52:14 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-291844 EUVD-2026-291844 https://cve.radiocsirt.org/vuln/euvd-2026-291844 https://cve.radiocsirt.org/vuln/fkie_cve-2026-40265 <p>Note Mark is an open-source note-taking application. In versions 0.19.1 and prior, the asset download endpoint at /api/notes/{noteID}/assets/{assetID} is registered without authentication middleware, and the backend query does not verify ownership or book visibility. An unauthenticated user who knows a valid note ID and asset ID can retrieve the full contents of private note assets without authentication, regardless of whether the associated book is public or private. This issue has been fixed in version 0.19.2.</p> <p>Note Mark is an open-source note-taking application. In versions 0.19.1 and prior, the asset download endpoint at /api/notes/{noteID}/assets/{assetID} is registered without authentication middleware, and the backend query does not verify ownership or book visibility. An unauthenticated user who knows a valid note ID and asset ID can retrieve the full contents of private note assets without authentication, regardless of whether the associated book is public or private. This issue has been fixed in version 0.19.2.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-40265 https://cve.radiocsirt.org/vuln/ghsa-p5w6-75f9-cc2p <p><strong>Affected:</strong> Go: github.com/enchant97/note-mark/backend</p> <p>### Summary A broken access control vulnerability allows unauthenticated users to retrieve note assets directly from the asset download endpoint when they know both the note UUID and asset UUID. This exposes the full contents of private note assets without authentication, even when the associated book is not public.</p> <p>### Details The issue is caused by the asset download route being registered without authentication middleware.</p> <p>Relevant route registration: - `handlers/assets.go`, line 40</p> <p>```go huma.Get(api, &#34;/api/notes/{noteID}/assets/{assetID}&#34;, h.GetNoteAssetContentByID) ```</p> <p>By contrast, other asset operations correctly apply authentication middleware. For example:</p> <p>```go huma.Delete(api, &#34;/api/notes/{noteID}/assets/{assetID}&#34;, h.DeleteNoteAsset, huma.WithMiddleware(h.authMiddleware.AuthRequiredMiddleware)) ```</p> <p>The backend service for asset retrieval also does not enforce ownership or visibility checks. According to the provided code references, the lookup only queries the asset table by asset ID and note ID:</p> <p>```sql SELECT * FROM note_assets WHERE id = ? AND note_id = ? ```</p> <p>Because the retrieval path does not join against the related `notes` or `books` records, it does not verify: - whether the requester owns the parent book - whether the parent book is public or private - whether the related note has been deleted</p> <p>As a result, possession of a valid `noteID` and `assetID` is sufficient to retrieve the asset binary, regardless of whether the note belongs to a priva…</p> <p><strong>Affected:</strong> Go: github.com/enchant97/note-mark/backend</p> <p>### Summary A broken access control vulnerability allows unauthenticated users to retrieve note assets directly from the asset download endpoint when they know both the note UUID and asset UUID. This exposes the full contents of private note assets without authentication, even when the associated book is not public.</p> <p>### Details The issue is caused by the asset download route being registered without authentication middleware.</p> <p>Relevant route registration: - `handlers/assets.go`, line 40</p> <p>```go huma.Get(api, &#34;/api/notes/{noteID}/assets/{assetID}&#34;, h.GetNoteAssetContentByID) ```</p> <p>By contrast, other asset operations correctly apply authentication middleware. For example:</p> <p>```go huma.Delete(api, &#34;/api/notes/{noteID}/assets/{assetID}&#34;, h.DeleteNoteAsset, huma.WithMiddleware(h.authMiddleware.AuthRequiredMiddleware)) ```</p> <p>The backend service for asset retrieval also does not enforce ownership or visibility checks. According to the provided code references, the lookup only queries the asset table by asset ID and note ID:</p> <p>```sql SELECT * FROM note_assets WHERE id = ? AND note_id = ? ```</p> <p>Because the retrieval path does not join against the related `notes` or `books` records, it does not verify: - whether the requester owns the parent book - whether the parent book is public or private - whether the related note has been deleted</p> <p>As a result, possession of a valid `noteID` and `assetID` is sufficient to retrieve the asset binary, regardless of whether the note belongs to a priva…</p> https://cve.radiocsirt.org/vuln/ghsa-p5w6-75f9-cc2p