CVE-2026-50554 in note-mark
Summary
by MITRE • 09/03/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in Note Mark prior to version 0.19.5 represents a critical authorization bypass within its REST API, specifically affecting the endpoint responsible for retrieving notes associated with a specific book. The core technical flaw stems from an inconsistent implementation of data filtering logic when handling soft-deleted records. In typical database architectures utilizing Object-Relational Mapping frameworks like GORM, soft deletes are managed by adding implicit scopes that filter out rows marked as deleted to ensure they do not appear in standard queries. However, the application's code explicitly invoked Unscoped() for this specific endpoint when processing requests with a query parameter indicating deletion status. This invocation effectively disabled the global soft-delete scope, allowing access to records physically present but logically removed from the user experience.
The severity of this flaw is amplified by the persistence of read-authorization checks that were not updated to account for the bypassed filtering logic. The authorization clause retained its original condition, which grants access if the requesting user is the owner or if the book is marked as public. Consequently, an unauthenticated attacker could exploit this discrepancy by sending a GET request with deleted=true. Because the soft-delete filter was disabled but the ownership check remained active for public books, the system returned metadata for notes that had been explicitly trashed by their owners. This behavior contradicts the expected security model where deletion implies removal from all views, including those of unauthorized users accessing public content.
From an operational perspective, this vulnerability enables information disclosure and enumeration attacks against user data privacy. Attackers can systematically iterate through book identifiers to harvest metadata associated with deleted notes belonging to any public book on the platform. This exposure violates the principle of least privilege by granting access to sensitive contextual information that users intended to discard permanently or temporarily hide from general view. The ability to enumerate these records may facilitate further attacks, such as social engineering campaigns using private details found in note titles or summaries, or potentially aiding in the reconstruction of deleted content if additional endpoints were similarly misconfigured.
This issue is classified under CWE-284 Improper Access Control and aligns with MITRE ATT&CK technique T1078 Valid Accounts when considering how public access credentials are leveraged to bypass intended restrictions. It also reflects aspects of CWE-605 Multiple Bindings in a Single Condition, where the logic for filtering data (soft delete) is decoupled from the logic for authorizing access (ownership/public status). The inconsistency between these two layers creates a predictable attack vector that undermines the integrity of the application's security model.
The vulnerability has been remediated in version 0.19.5 by ensuring that authorization checks and data filtering scopes are applied consistently regardless of query parameters. To mitigate similar risks, developers should enforce strict separation of concerns between authentication, authorization, and data retrieval logic. It is recommended to implement centralized access control policies that evaluate all security constraints before executing database queries. Additionally, thorough code reviews focusing on ORM scope manipulations can prevent accidental bypasses of soft-delete filters in endpoints handling sensitive or user-specific data.