Description

Trilium is an open-source hierarchical note-taking application. In versions prior to 0.104.0, the automatic image-download feature accepts file:// URLs in a note's img tags and reads the referenced local file with no path validation, allowing any authenticated user to disclose arbitrary files readable by the Trilium process. When a text note is saved, Trilium scans its HTML for image sources and downloads each external one; because the HTML sanitizer keeps file as an allowed scheme, a source such as file:///etc/passwd is passed straight to a filesystem read and its contents are stored as a note attachment the user can then retrieve. Pointing the same primitive at an unbounded source such as /dev/zero causes uncontrolled memory allocation that crashes the server process. The feature is enabled by default and is reachable through the web UI, the ETAPI, the web clipper, and note imports, requiring only an authenticated session or an ETAPI token. This issue is fixed in version 0.104.0

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-27T20:17:49.153Z",
  "pubdate": "2026-08-27T20:17:49.153Z",
  "executiveSummary": "Trilium versions prior to 0.104.0 are susceptible to a Local File Disclosure (LFD) and Denial of Service (DoS) vulnerability originating from improper input validation within the application's automatic image-download feature.\nThe vulnerability allows an authenticated user or an attacker possessing an ETAPI token to force the Trilium server process to read and store arbitrary files from the underlying filesystem as note attachments.\nBy manipulating image source attributes in HTML notes, an attacker can bypass security controls to exfiltrate sensitive local data or trigger a server-side crash via uncontrolled memory allocation when targeting device special files such as /dev/zero.\nThe flaw stems from the application's HTML sanitizer, which incorrectly permits the file:// URI scheme, enabling direct filesystem access without path validation.\nSuccessful exploitation requires an authenticated session or an ETAPI token, which can be leveraged through the web UI, web clipper, or note imports. Given that this feature is enabled by default, the risk of data compromise is significant for any deployment where untrusted users possess authentication credentials.\nThe vulnerability is remediated in version 0.104.0.",
  "technicalDetails": "The core vulnerability lies in the insufficient sanitization of URI schemes within the Trilium HTML processing engine. When a note is saved, the application initiates an automatic image-download routine that parses HTML content for external image resources. The application's sanitization logic fails to explicitly block or restrict the file:// URI scheme, allowing it to pass through to the underlying filesystem read functions.\nBecause the system performs no path validation or directory traversal checks on these URI inputs, the server process interprets file:/// paths as valid resource locations. When a user submits an HTML note containing an <img src='file:///etc/passwd'> tag, the Trilium backend executes a file read operation on the specified path. The resulting file content is then processed and stored as a note attachment within the application database, which the attacker can subsequently download and inspect via the authorized interface.\nThe attack flow proceeds as follows: First, the attacker authenticates to the Trilium instance or obtains a valid ETAPI token. Second, the attacker creates or modifies a note, inserting an HTML img tag with the file:// protocol directed at a sensitive system file. Third, the application's internal worker processes the note, parses the malicious HTML, and reads the referenced file from the host filesystem. Fourth, the content is saved to the instance's storage, effectively bypassing file system permissions as they pertain to the user, since the read is performed by the process owner. Finally, the attacker retrieves the attachment from the note storage.\nFurthermore, the vulnerability allows for a Denial of Service (DoS) attack. By pointing the img src attribute to infinite or high-entropy data sources like /dev/zero, the application attempts to read the device and store the output as an attachment. This process leads to uncontrolled memory allocation within the server process, causing the application to crash due to resource exhaustion. This primitive is particularly dangerous because it does not require complex logic to execute—only a simple, malformed HTML entry.\nThe affected component is the automated image processing and sanitization module. All versions prior to 0.104.0 are confirmed vulnerable. As the feature is enabled by default across multiple entry vectors—including ETAPI, web clipper, and standard UI note imports—the attack surface is broad for any multi-user or integrated Trilium environment."
}