CVE-2026-54068: Unauthenticated Server-Side Template Injection and SQLite Exfiltration in SiYuan PKM

The SiYuan personal knowledge management system utilizes a client-server architecture where a Go-based backend (referred to as the kernel) processes internal system tasks and serves API requests. The core application exposes multiple endpoints to manipulate blocks, render views, and serve asset files. Among these endpoints, several are exposed publicly to handle system bootstrap processes and generate transient resources without requiring session validation.\n\nPrior to version 3.7.0, the API endpoint /api/icon/getDynamicIcon was designated as an unauthenticated route in the router configuration. This endpoint is responsible for rendering user-customized SVG files based on specified icon configurations and text formats. Because it lacked session validation, any remote network client with connectivity to the application interface could access this endpoint directly.\n\nThe unauthenticated status of this handler combined with the dynamic template processing logic exposes a significant attack surface. Unauthenticated users are permitted to supply structured query parameters that directly trigger internal compilation components. The subsequent sections explore how this lack of access control allows remote actors to invoke privileged system database actions.

The underlying flaw stems from the implementation of type 8 (text-based) icon generation in the backend handler. When the query parameter type is set to 8, the endpoint routes control to the generateTypeEightSVG function inside kernel/api/icon.go. This function checks the incoming request parameter content to verify if it contains the string token .action{.\n\nWhen this specific token is detected, the application transfers execution to RenderDynamicIconContentTemplate within the kernel/model/template.go file. This function initializes a Go text/template compilation engine utilizing .action{ and } as the template action delimiters. It maps a set of built-in file system and data access routines directly into the active compilation scope.\n\nThe crucial error is the registration of SQLite database queries in this template engine. The template initialization logic merges internal SQL query helper functions, specifically querySQL and queryBlocks, into the template's executive execution environment. Because the backend does not validate or clean the user-supplied string before parsing, Go compiles and executes the template's functional statements, which includes running any embedded database queries.

The vulnerability resides in the router registration block in kernel/api/router.go. In affected versions, the API handlers are divided into authenticated and unauthenticated sections. The /api/icon/getDynamicIcon route was grouped with standard unauthenticated endpoints such as the boot progress tracker.\n\ngo\n// Affected Router Registration (kernel/api/router.go)\nginServer.Handle("GET", "/api/icon/getDynamicIcon", getDynamicIcon)\n\n\nThe corresponding patch alters this registration by enforcing the model.CheckAuth middleware. This ensures that any incoming request validates session identifiers before reaching the handler.\n\ngo\n// Patched Router Registration (kernel/api/router.go)\nginServer.Handle("GET", "/api/icon/getDynamicIcon", model.CheckAuth, getDynamicIcon)\n\n\nmermaid\ngraph LR\n Client["Client Request"] --> Router["router.go"]\n Router -- "Unauthenticated (Vulnerable)" --> Handler["getDynamicIcon"]\n Router -- "Authenticated (Patched)" --> Middleware["model.CheckAuth"]\n Middleware -- "Valid Session" --> Handler\n Middleware -- "Invalid Session" --> Denied["401 Unauthorized"]\n Handler --> Template["Template Evaluation"]\n Template --> SQL["SQLite execution via querySQL"]\n

To exploit this vulnerability, an attacker must craft an HTTP request containing a valid database template statement. The primary prerequisite is discovering a valid block identifier (ID) within the database. Because SiYuan uses block-level notes, block IDs are routinely leaked through shared links, configuration files, or public document structures.\n\nAfter obtaining a valid block ID, the attacker targets the /api/icon/getDynamicIcon endpoint. The attacker sets the type parameter to 8 and the id parameter to the discovered block ID. The critical payload is passed via the content parameter, utilizing the custom template delimiter .action{ followed by the database execution function.\n\nAn example request payload targets the internal database to exfiltrate table contents. By supplying .action{querySQL "SELECT content FROM blocks LIMIT 1"}, the application executes the query against the SQLite backend. The returned string result is placed inside the <text> element of the resulting SVG payload, transferring the confidential data within the image structure to the unauthenticated requester.

The security impact is marked as a high confidentiality threat. The SQLite database contains the entirety of the user's workspace, including note content, system configurations, credential blocks, and synchronization metadata. Unauthenticated access allows complete extraction of this database without triggering endpoint logs associated with typical administrative functions.\n\nBecause the action does not modify the underlying database, the integrity and availability impacts are classified as none. The exploit complexity is rated as high because the attacker must first acquire or guess a valid block ID to satisfy the node retrieval check inside RenderDynamicIconContentTemplate. This requirement prevents automated blind scanning from immediately retrieving data unless standard default block configurations are present.\n\nThe vulnerability is tracked under CVE-2026-54068 and GHSA-gcm7-57gf-953c. The CVSS base score of 5.9 reflects the remote capability to read highly sensitive local system data offset by the complexity required to target specific instance files.

Addressing this issue requires updating the SiYuan application deployment to version 3.7.0 or newer. This update migrates the dynamic icon endpoint behind the core authentication layer. If immediate updates are not possible, administrators should use system firewalls or reverse proxy rules to drop external requests targeting /api/icon/getDynamicIcon.\n\nTo identify vulnerable servers, security teams can execute testing queries that do not require valid block IDs. Sending a GET request to the target dynamic icon endpoint with type 8 will elicit a specific behavior. If the server responds with an HTTP 200 and an SVG image content type, the system is lacking authentication checks and remains vulnerable.\n\nConversely, a secure instance will return a 401 Unauthorized status or redirect the client to the login page. Continuous monitoring of web application logs for unusual queries targeting the dynamic icon URL path helps identify potential reconnaissance and targeted exploitation attempts.