CVE-2026-44523

Note Mark prior to version 0.19.5 improperly validates slug values because the OpenAPI/huma pattern is not anchored, allowing paths with ../ segments to be accepted. Data export commands use these slugs to create files outside the export directory, potentially leading to file writes with root privileges.

Note Mark is an open-source note-taking application. Prior to version 0.19.5, GET /api/books/{bookID}/notes is an unauthenticated endpoint that accepts a "deleted" query parameter. When the request is ?deleted=true, the service runs the query with Unscoped() (bypassing GORM's soft-delete scope) but keeps the read-authorization clause as "owner_id = ? OR is_public = ?". As a result, any unauthenticated caller can enumerate the metadata of soft-deleted ("trashed") notes belonging to any public book — notes the owner explicitly deleted and expected to be removed from public view.

In Note Mark from 0.13.0 to before 0.19.4, the asset filename provided via the X-Name header by an authenticated user is stored without validation, allowing directory traversal sequences. During CLI export, the stored name is passed to `filepath.Join()` and `os.Create()`, enabling file writes to arbitrary locations on the filesystem.

Note Mark is an open-source note-taking application. Prior to version 0.19.3, after a note-mark owner soft-deletes a public book, its notes and uploaded assets stay readable at /api/notes/{id}, /api/notes/{id}/content, the slug URL, and the asset endpoints. Unauthenticated callers who hold the note ID or the slug path retain access. GORM's soft-delete scope does not reach the raw "JOIN books ..." clauses used by the note and asset queries.

In Note Mark versions 0.19.1 and prior, the /api/notes/{noteID}/assets/{assetID} endpoint lacks authentication middleware and the backend query does not verify ownership or book visibility. An unauthenticated user knowing valid note and asset IDs can retrieve full contents of private note assets.

In Note Mark versions 0.19.1 and prior, the login endpoint performs bcrypt password verification only for existing usernames, returning immediately for nonexistent ones. This timing discrepancy allows unauthenticated attackers to enumerate valid usernames. The issue is fixed in version 0.19.2.