Trilium Notes EUVD-2026-67230

Exploitation requires two operator-configured preconditions: (1) the Trilium instance must have the public share feature actively enabled and at least one note subtree published, since sharing is off by default; and (2) the attacker must possess or be able to enumerate a valid ancestorNoteId (the shareId of a published root note), which is typically embedded in any shared URL the operator has distributed. Within those prerequisites, exploitation is fully unauthenticated - no account, session, or credentials on the Trilium instance are required. What limits exploitation: the attack is read-only (no integrity or availability impact); it is confined to the published subtree identified by the supplied ancestor note ID; and the technique requires the attacker to iteratively query substrings to extract content rather than retrieve it in a single request, making bulk exfiltration slower and more detectable in access logs.

The CVSS 3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) accurately captures the technical severity: no authentication, no special network position, and high confidentiality impact. The oracle attack vector - where an attacker queries successive substrings to reconstruct full note content - meaningfully elevates the practical impact beyond simple title enumeration to complete plaintext exfiltration of credential-protected notes. Real-world priority, however, depends heavily on whether the operator has enabled public sharing and placed sensitive notes within shared subtrees, both of which are deliberate non-default actions. No active exploitation has been confirmed (not listed in CISA KEV), and no public proof-of-concept has been identified. EPSS data was not provided, so automated exploitation probability cannot be compared against the CVSS signal. The combination of a niche self-hosted deployment model and a required operator-configured prerequisite (public sharing enabled) meaningfully narrows the vulnerable population compared to what the raw CVSS score implies - though for any affected deployment that does have shared notes containing sensitive information, the risk is real and the fix is straightforward.

An attacker discovers a Trilium instance with public sharing enabled - for example by finding a shared note URL published by the operator - and extracts the ancestor note's shareId from the URL. The attacker then issues unauthenticated GET requests to /share/api/notes?ancestorNoteId=<id>&search=<substring>, iterating through character sequences and observing whether credential-protected or hidden notes appear in the JSON response, using the presence or absence of a note title as a one-bit oracle. Through successive queries, the attacker recovers the full content of notes that should require a password to access.