CVE-2026-50554

The Note Mark application prior to version 0.19.4 does not enforce minimum length or entropy for the JWT_SECRET configuration value. It allows any base64-decodable secret, including secrets as short as 1 byte.

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.

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.