Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/enchant97/note-mark/backend < 0.0.0-20260601210719-67b7de04308a
Fixed in
0.0.0-20260601210719-67b7de04308a· Vendor fix available
Issue
Note Mark validates book and note slug values with the OpenAPI/huma tag pattern:"[a-z0-9-]+". huma compiles this with regexp.MustCompile(s.Pattern) and tests it with patternRe.MatchString(str), an UNANCHORED match. Because the pattern is not anchored (^...$), any string that merely CONTAINS one [a-z0-9-] substring passes validation. A slug such as ../../../../../../tmp/escape is accepted and stored verbatim. The data-export CLI commands (note-mark migrate export and note-mark migrate export-v1) join these unsanitized slugs straight into the output path with path.Join / filepath.Join, then os.MkdirAll the directory and os.Create the note file. path.Join resolves the ../ segments, so the note content file is written OUTSIDE the configured export directory. The export process commonly runs as root (default in Docker / bare-metal admin usage), so this is a root-privilege arbitrary directory create + file write. This is the unguarded sibling of GHSA-g49p-4qxj-88v3 (CVE class…
Recommended action: Upgrade to 0.0.0-20260601210719-67b7de04308a (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/enchant97/note-mark/backend < 0.0.0-20260601210758-9c9b72740f22
Fixed in
0.0.0-20260601210758-9c9b72740f22· Vendor fix available
Issue
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 "ownerid = ? OR ispublic = ?". 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. Affected component (code-verified) backend/services/notes.go — GetNotesByBookID (lines 72-89): func (s NotesService) GetNotesByBookID(currentUserID uuid.UUID, bookID uuid.UUID, deleted bool) ([]db.Note, error) { tx := db.DB if deleted { tx = tx.Unscoped() // <-- bypasses soft-delete scope } tx = tx. Preload("Book"). Joins("JOIN books ON books.id = notes.bookid"). Where( db.DB.Where("books.id = ?", bookID), db.DB.Where("ownerid = ? OR ispublic = ?", currentUserID, true), // <--…
Recommended action: Upgrade to 0.0.0-20260601210758-9c9b72740f22 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/enchant97/note-mark/backend < 0.0.0-20260501152247-18b587758667
Fixed in
0.0.0-20260501152247-18b587758667· Vendor fix available
Issue
No minimum length or entropy is enforced on the JWTSECRET configuration value. The application accepts any base64-decodable secret regardless of size, including secrets as short as 1 byte. HS256 secrets below 32 bytes are brute-forceable offline, allowing attackers to recover the signing key and forge valid JWTs for arbitrary users. --- Impact An attacker who captures a single valid JWT (e.g, from cookies, logs, or network traffic) can: \ Crack the signing secret offline using brute-force or wordlist attacks \ Forge valid JWTs for any user ID (including administrators) \ Authenticate without knowing any credentials This results in full account takeover across the entire application with no server-side detection or rate limiting possible. --- Details In backend/config/utils.go, the Base64Decoded.UnmarshalText function decodes the JWT secret but does not validate its length or entropy. In backend/core/auth.go, JWT tokens are signed using HS256 without enforcing minimum key size…
Recommended action: Upgrade to 0.0.0-20260501152247-18b587758667 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/enchant97/note-mark/backend < 0.0.0-20260501152243-db3f72bff780
Fixed in
0.0.0-20260501152243-db3f72bff780· Vendor fix available
Issue
The Note Mark application allows authenticated users to upload assets to notes via POST /api/notes/{noteID}/assets, where the asset filename is provided through the X-Name HTTP request header. This value is stored directly in the database without any sanitization or validation - no path separator filtering, no directory traversal sequence rejection, and no use of filepath.Base() to strip directory components. The unsanitized name is persisted as-is in the noteassets table (Name column, varchar(80)). When an administrator subsequently runs the data export CLI commands (note-mark migrate export-v1 or note-mark migrate export), the stored asset name is passed directly into filepath.Join() and path.Join() calls as part of the output file path argument to os.Create(). Since Go's filepath.Join() resolves ../ sequences during path normalization, an attacker-controlled asset name containing directory traversal sequences causes the export process to write files to arbitrary…
Recommended action: Upgrade to 0.0.0-20260501152243-db3f72bff780 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/enchant97/note-mark/backend < 0.0.0-20260417132843-d1bf845a2a2d
Fixed in
0.0.0-20260417132843-d1bf845a2a2d· Vendor fix available
Issue
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. Details DELETE /api/books/{bookID} sets books.deletedat to the current time. The book-level endpoint starts returning 404, which matches the owner's expectation that the book is gone. The note service and asset service query notes with a raw join that does not filter books.deletedat IS NULL: GORM applies its soft-delete scope to the primary model of a query (here, notes) and to implicit Joins("Book") association clauses. It does not rewrite raw SQL passed to Joins. The soft-deleted book row keeps ispublic = true, so the WHERE ownerid = ? OR ispublic = ? clause still evaluates true for any caller on a book that was…
Recommended action: Upgrade to 0.0.0-20260417132843-d1bf845a2a2d (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/enchant97/note-mark/backend < 0.0.0-20260417132909-dea5530cc989
Fixed in
0.0.0-20260417132909-dea5530cc989· Vendor fix available
Issue
IsPasswordMatch in backend/db/models.go falls back to a hard-coded bcrypt("null") placeholder whenever a user has no stored password. OIDC-registered users are created with an empty password, so anyone who submits password: "null" to the internal login endpoint receives a valid session for that user. The bypass is unauthenticated and requires no user interaction. Details backend/db/models.go:36 defines the placeholder hash used by the timing-attack mitigation inside IsPasswordMatch: IsPasswordMatch (backend/db/models.go:46-58) substitutes that placeholder when the stored password is empty: OIDC-registered users are stored with an empty password at backend/services/auth.go:102-115: The internal login endpoint (POST /api/auth/token, handled at backend/services/auth.go:20-54) calls IsPasswordMatch with the caller-supplied password. For any OIDC-only user, bcrypt.CompareHashAndPassword(nullPasswordHash, []byte("null")) returns nil, the function returns true, and the server issues…
Recommended action: Upgrade to 0.0.0-20260417132909-dea5530cc989 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/enchant97/note-mark/backend < 0.0.0-20260411145023-6593898855ad
Fixed in
0.0.0-20260411145023-6593898855ad· Vendor fix available
Issue
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. Details The issue is caused by the asset download route being registered without authentication middleware. Relevant route registration: - handlers/assets.go, line 40 By contrast, other asset operations correctly apply authentication middleware. For example: 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: 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…
Recommended action: Upgrade to 0.0.0-20260411145023-6593898855ad (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/enchant97/note-mark/backend < 0.19.2-0.20260411145025-cf4c6f6acf70
Fixed in
0.19.2-0.20260411145025-cf4c6f6acf70· Vendor fix available
Issue
A timing side-channel in the login endpoint allows unauthenticated attackers to determine whether a username exists by measuring response time differences. Requests for valid usernames take noticeably longer because the server performs bcrypt password verification, while requests for nonexistent usernames return much faster. This enables reliable remote username enumeration and increases the risk of targeted credential attacks. Details The issue affects the login endpoint: - POST /api/auth/token The root cause is that authentication processing takes different code paths depending on whether the supplied username exists. When the username is found, the server performs bcrypt.CompareHashAndPassword, which adds substantial latency. When the username does not exist, the server returns immediately without performing an equivalent bcrypt operation. Vulnerable flow: This creates a measurable timing discrepancy between: - existing username + wrong password requests, which incur…
Recommended action: Upgrade to 0.19.2-0.20260411145025-cf4c6f6acf70 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/enchant97/note-mark/backend < 0.0.0-20260411145018-6bb62842ccb9
Fixed in
0.0.0-20260411145018-6bb62842ccb9· Vendor fix available
Issue
A stored same-origin XSS vulnerability allows any authenticated user to upload an HTML, SVG, or XHTML file as a note asset and have it executed in a victim’s browser under the application’s origin. Because the application serves these files inline without a safe content type and without nosniff, browsers can sniff and render active content, giving the attacker access to authenticated Note Mark API actions as the victim. Details This issue results from three compounding flaws in the asset handling and delivery path. 1. Asset delivery can be used as an attack vector The asset delivery route can be used to deliver attacker-controlled uploaded content directly to a victim by URL. Relevant route: - handlers/assets.go:40 This makes the uploaded asset reachable by direct navigation, which provides the delivery mechanism for the payload. 2. Text-based active content is served with an empty Content-Type The asset handler relies on h2non/filetype for content-type detection: -…
Recommended action: Upgrade to 0.0.0-20260411145018-6bb62842ccb9 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.