Only the latest stable minor release receives security fixes.

For example, if the latest stable version is 0.92.3 and the latest beta is 0.93.0-beta, then only the 0.92.x line will receive security patches. Older versions (like 0.91.x) will not receive fixes.

This policy may be altered on a case-by-case basis for critical vulnerabilities.

Please report all security vulnerabilities through GitHub Security Advisories.

We do not accept security reports via email, public issues, or other channels. GitHub Security Advisories allows us to:

• Discuss and triage vulnerabilities privately
• Coordinate fixes before public disclosure
• Credit reporters appropriately
• Publish advisories with CVE identifiers

When reporting, please provide:

• A clear description of the vulnerability
• Steps to reproduce or proof-of-concept
• Affected versions (if known)
• Potential impact assessment
• Any suggested mitigations or fixes

• Initial response: Within 7 days
• Triage decision: Within 14 days
• Fix timeline: Depends on severity and complexity

• Remote code execution
• Authentication/authorization bypass
• Cross-site scripting (XSS) that affects other users
• SQL injection
• Path traversal
• Sensitive data exposure
• Privilege escalation

The following are considered out of scope or accepted risks:

Trilium is a personal knowledge base where users have full control over their own data. Users can intentionally create notes containing scripts, HTML, or other executable content. This is by design - Trilium's scripting system allows users to extend functionality with custom JavaScript.

Vulnerabilities that require a user to inject malicious content into their own notes and then view it themselves are not considered security issues.

A shared note is published by its owner, and the share view renders it as it was authored, raw HTML included. Script running on a page you publish is not an escalation of anything: Trilium supports it deliberately, through the ~shareJs relation, which loads a JavaScript note of your choosing into the share page, and through ~shareTemplate for the page around it.

Reports that reduce to "a note's own HTML or JavaScript executes for visitors to the page publishing it" are therefore out of scope, however the content was written (editor, ETAPI, sync). Content arriving through the importers and the web clipper is sanitized on write, independently of this.

What crosses out of the published page remains in scope: disclosing notes that were never shared, bypassing #shareCredentials or #shareHiddenFromTree, or reaching the authenticated session of someone who merely visited. So does a defect in how the share renderer itself builds markup, such as a value escaping the attribute it was placed in; we fix those as correctness bugs even where the value was the publisher's own.

The desktop application follows the Electron security checklist: nodeIntegration is disabled, contextIsolation is enabled, and the renderer can only reach the main process through a whitelisted contextBridge API (window.electronApi). Embedded web content (Web View notes) is isolated in a dedicated session partition with deny-by-default permission handlers, <webview> attach requests are vetted in the main process, and window-open/navigation requests are checked against a scheme allowlist. Electron fuses additionally prevent external abuse.

User scripting (see Self-XSS above) still intentionally allows arbitrary JavaScript in the renderer, so reports that reduce to "a user script can call the frontend API" remain out of scope. Renderer-to-main escapes, however, are in scope: gaining Node.js access from the renderer, bypassing the preload bridge whitelist, or escaping the webview isolation.

Actions that require valid authentication and only affect the authenticated user's own data are generally not vulnerabilities.

Creating extremely large notes or performing many operations is expected user behavior in a note-taking application.

We implement security headers where they provide meaningful protection, but may omit them on endpoints where they provide no practical benefit.

We follow a coordinated disclosure process:

1. Report received - We acknowledge receipt and begin triage
2. Fix developed - We develop and test a fix privately
3. Release prepared - Security release is prepared with vague changelog
4. Users notified - Release is published, users encouraged to upgrade
5. Advisory published - After reasonable upgrade window (typically 2-4 weeks), full advisory is published

We appreciate reporters allowing us time to fix issues before public disclosure. We aim to credit all reporters in published advisories unless they prefer to remain anonymous.

Security fixes are released as patch versions (e.g., 0.92.1 → 0.92.2) to minimize upgrade friction. We recommend all users keep their installations up to date.

Subscribe to GitHub releases or watch the repository to receive notifications of new releases.