CVE-2026-77438 in Trilium
Summary
by MITRE • 08/27/2026
Trilium is an open-source hierarchical note-taking application. In versions up to and including 0.103.0, the public share-search endpoint does not enforce the per-note shareCredentials and shareHiddenFromTree controls, allowing an unauthenticated visitor to read the titles, tree paths, and content of protected shared notes. The endpoint authorizes only the ancestor note supplied in the request and then runs a full-text search across the entire published subtree, returning each matching note's title, share identifier, and hierarchical path without re-checking whether that individual note requires a share password or is hidden from the navigation tree. Because the search matches note content, an attacker can enumerate protected notes and use the endpoint as a boolean oracle that confirms arbitrary substrings, recovering the full contents of notes that should be gated behind a password. This issue is fixed in version 0.104.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in Trilium versions up to and including 0.103.0 represents a critical failure in access control logic within the public share-search endpoint, classified under CWE-285: Improper Authorization. This open-source hierarchical note-taking application relies on granular permissions for shared notes, specifically utilizing per-note shareCredentials to require passwords and shareHiddenFromTree controls to prevent visibility in navigation structures. The core technical flaw lies in the server-side implementation of the search functionality, which authorizes access based solely on the ancestor note supplied in the request parameters rather than validating each individual result against its specific security attributes. When a user queries this endpoint with valid credentials for an ancestor node, the system performs a full-text search across the entire published subtree associated with that ancestor without re-evaluating whether the matching descendant notes are protected by passwords or marked as hidden from the tree.
This architectural oversight allows unauthenticated visitors who possess knowledge of any single shared note's identifier to bypass security controls intended for other notes within the same hierarchy. By submitting search queries containing specific substrings, an attacker can exploit this behavior to enumerate protected content effectively acting as a boolean oracle. The endpoint returns titles, share identifiers, and hierarchical paths for every matching note regardless of its individual access restrictions. Consequently, if a query matches a substring present in a password-protected or hidden note, the system reveals metadata about that note, confirming its existence and providing structural context such as its path within the tree. This leakage enables attackers to systematically recover full contents of notes that should remain gated behind authentication mechanisms by iteratively refining search terms based on returned results.
The operational impact of this vulnerability is severe, leading to a complete compromise of confidentiality for shared data structures. Attackers can map out the entire hierarchy of protected content without needing individual passwords for each note, effectively neutralizing the intended security boundaries established by administrators and users. This exposure violates fundamental principles of least privilege and secure design, as access granted to one resource inadvertently grants visibility into unrelated resources within the same subtree that have distinct authorization requirements. The ability to enumerate hidden notes further exacerbates the risk by revealing organizational structures or sensitive topics that were explicitly designed to be invisible in standard navigation interfaces.
To mitigate this vulnerability, organizations must immediately upgrade Trilium to version 0.104.0 or later, where the search endpoint has been patched to enforce per-note shareCredentials and shareHiddenFromTree controls during result generation. Until an update is applied, administrators should consider restricting public access to shared notes entirely if possible, as there are no effective workarounds for this logic flaw within the vulnerable version. Security monitoring should also be enhanced to detect unusual patterns of search queries that may indicate enumeration attempts against published subtrees. This incident underscores the importance of validating authorization controls at every level of data retrieval rather than relying on coarse-grained checks applied only at entry points, aligning with ATT&CK techniques related to Discovery and Collection where attackers leverage system misconfigurations to gather intelligence about protected assets.