Description

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. This issue has been patched in version 0.19.5.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-03T16:17:25.020Z",
  "pubdate": "2026-09-03T16:17:25.020Z",
  "executiveSummary": "A security vulnerability has been identified in Note Mark, an open-source note-taking application, affecting all versions prior to 0.19.5. This vulnerability is classified as an improper access control and information disclosure issue. It allows unauthenticated remote attackers to obtain sensitive metadata from soft-deleted ('trashed') notes. The impact is significant as users expect deleted content to be completely inaccessible, particularly to unauthorized external parties.\nThe flaw lies within the implementation of the API endpoint responsible for retrieving notes. By manipulating query parameters, an attacker can bypass the standard soft-delete filtering mechanism. This issue poses a privacy risk, potentially exposing historical data structure, titles, and creation patterns of private notes that were previously associated with public books. Exploitation does not require authentication or special privileges, making the vulnerability highly accessible to any network-based attacker with knowledge of target book identifiers.\nThe risk implications involve potential intelligence gathering on targeted individuals or organizations using Note Mark, as deleted notes often contain sensitive information that was discarded due to confidentiality concerns.",
  "technicalDetails": "The root cause of the vulnerability resides in the backend database querying logic of Note Mark, specifically in the handling of the 'GET /api/books/{bookID}/notes' endpoint. Under normal operating conditions, Note Mark utilizes GORM (an Object Relational Mapper for Go) to manage database interactions, which employs a 'soft-delete' feature. When a user deletes a note, GORM flags the record by setting a 'deleted_at' timestamp rather than performing a hard delete from the database physical storage. Subsequent standard queries automatically filter out these soft-deleted records.\nHowever, the endpoint accepts a 'deleted' query parameter. When a client issues a request containing '?deleted=true', the application code invokes GORM's 'Unscoped()' method. The 'Unscoped()' method explicitly instructs the ORM to ignore the soft-delete state and retrieve all records, including those where 'deleted_at' is populated. While this functionality is intended for administrative or recovery purposes, the application fails to restrict its usage to authenticated and authorized owners.\nFrom a framework perspective, GORM's GORM.DeletedAt model struct is designed to intercept SQL queries at the driver level to append a 'WHERE deleted_at IS NULL' clause dynamically. The use of GORM's Unscoped() method completely deactivates this middleware-like behavior for the duration of the transaction or query context. This architectural detail means that once Unscoped() is called, the application logic assumes the responsibility of manually applying equivalent or more restrictive security boundaries.\nThe database query combines the 'Unscoped()' modifier with an authorization clause: 'owner_id = ? OR is_public = ?'. For a public book, the 'is_public' condition evaluates to true. Because the application processes unauthenticated requests and permits them to query public books, the authorization check succeeds based solely on the public status of the parent book. The system does not verify if the unauthenticated requester should have access to the unscoped (deleted) items associated with that book.\nIn the vulnerable Note Mark implementation, the developer attempted to maintain authorization by preserving the 'owner_id = ? OR is_public = ?' check within the same database query. However, this logic suffers from a structural breakdown: a note being part of a public book does not imply that its deleted history should remain public. When a note is soft-deleted, its implicit visibility status changes; it is no longer considered an active public asset. By failing to evaluate the interaction between 'Unscoped()' and 'is_public', the application treats active public notes and deleted public notes identically, presenting a severe logical bypass.\nConsequently, the attack flow is straightforward: an unauthenticated attacker sends a crafted HTTP GET request to the target endpoint specifying a public book ID and appending the '?deleted=true' parameter. The server executes the unscoped query, matches the public book criteria, and returns the metadata of all notes—including those previously deleted by the owner. This bypasses the expected privacy boundaries, leading to unauthorized metadata enumeration."
}