CVE-2026-72812: Broken Access Control and SQL Injection in SiYuan

SiYuan is an open-source, local-first personal knowledge management platform designed to organize structured notes using a block-based architecture. To support distributed collaborative scenarios, the platform supports a Publish mode where designated notebooks are rendered readable to public visitors. Under this layout, certain back-end endpoints are exposed to facilitate reading views without requiring administrative authentication.\n\nThe vulnerability designated as CVE-2026-72812 exists within the handling of the /api/ref/refreshBacklink endpoint, which is used to rebuild connection trees between referenced notes. In versions prior to v3.7.4, this route lacked administrative checks and read-only environmental validations. Consequently, any anonymous reader on a public instance can trigger recursive query execution and subsequent transaction flushes to disk.\n\nBeyond the access control failure, the application's core backlink-resolution logic suffers from a secondary vulnerability involving unsafe string formatting during parent-child structural evaluations. By combining the authorization bypass with the injection of crafted block identifiers, an adversary can influence SQL execution paths inside the SQLite database engine. This combination elevates the severity of the vulnerability from basic resource consumption to remote database manipulation.

The primary flaw stems from incomplete access control controls inside kernel/api/router.go. The routing definition mapped /api/ref/refreshBacklink strictly to the model.CheckAuth middleware instead of enforcing the more restrictive model.CheckAdminRole or checking the read-only flag via the model.CheckReadonly check. The model.CheckAuth middleware only checks if a session is present or if the application is running in read-only public publish mode, which maps anonymous guests to the RoleReader role.\n\nWhen a guest initiates a request, the router allows execution to proceed to the refreshBacklink handler in kernel/api/ref.go. This controller takes a block identifier string directly from the input JSON object without input format sanitization. It passes this string directly to model.RefreshBacklink(), which triggers background transaction management routines including model.FlushTxQueue() to flush memory queues into disk storage.\n\nThe secondary SQL injection vulnerability occurs in kernel/sql/block_ref_query.go inside the QueryRefsByDefID function. When executing nested lookups for child block structures, the function fetches child block IDs via Go slice routines and attempts to join them into an SQL IN statement. The implementation does this by enclosing each block ID string in raw double-quotes and executing raw string concatenation: SELECT * FROM refs WHERE def_block_id IN ( + strings.Join(params, ",") + ). This direct integration of unescaped string outputs inside structural queries permits an injection payload to escape the quoted literal wrapper.

To understand the vulnerable logic, examine the way the query construction historically concatenated values within kernel/sql/block_ref_query.go:\n\ngo\n// Vulnerable code in block_ref_query.go\nif containChildren {\n blockIDs := queryBlockChildrenIDs(defBlockID)\n var params []string\n for _, id := range blockIDs {\n params = append(params, "\""+id+"\"")\n }\n rows, err = query("SELECT * FROM refs WHERE def_block_id IN (" + strings.Join(params, ",") + ")")\n}\n\n\nBecause there was no escaping mechanism, if an attacker successfully seeded a custom block ID containing nested double-quotes, SQL injection occurred. In the patch, this code pattern was deleted entirely and replaced with a relational, database-side recursion using a Common Table Expression (CTE):\n\ngo\n// Patched code utilizing recursive CTE and parameterization\nconst queryRefsByDefIDWithChildren = `WITH RECURSIVE child_ids(id) AS (\n\tSELECT ?\n\tUNION\n\tSELECT blocks.id FROM blocks JOIN child_ids ON blocks.parent_id = child_ids.id\n)\nSELECT refs.* FROM refs JOIN child_ids ON refs.def_block_id = child_ids.id`\n\n\nThe application now binds the root parameter defBlockID via standard prepared parameter replacement (?). By doing so, the query engine processes input values strictly as string literals, rendering injection payloads harmless. Additionally, the route protection check in kernel/api/router.go was patched to append validation layers:\n\ngo\n// Patched routing rule in router.go\nginServer.Handle("POST", "/api/ref/refreshBacklink", model.CheckAuth, model.CheckAdminRole, model.CheckReadonly, refreshBacklink)\n\n\nAdding both model.CheckAdminRole and model.CheckReadonly prevents non-admin users and users in read-only publish mode from invoking this transactional route, eliminating the unauthenticated write vector.

Exploitation of the authorization bypass is conducted through a single HTTP POST payload targeting the /api/ref/refreshBacklink route. Because public instances exposing notes in read-only publish mode allow access to the handler, an attacker does not require any credentials. The only prerequisite is harvesting a valid block ID, which is exposed in the page structure of public notes.\n\nThe secondary SQL injection payload requires injecting a corrupted block ID into the blocks database table. This can be achieved through other vector interfaces such as syncing malicious notes or using notebook import functions. Once the malicious block ID is present (for example, carrying a payload like 20260723000000-injection" OR (SELECT 1 FROM (SELECT UPPER(HEX(RANDOMBLOB(10000000)))))) --), invoking the backlink refresh endpoint on its parent triggers the vulnerable query builder.\n\nmermaid\ngraph LR\n Attacker["Attacker (Anonymous Reader)"] -->|1. POST /api/ref/refreshBacklink| WebRouter["Web Router (No Admin Filter)"]\n WebRouter -->|2. Invoke Handlers| QueryHandler["QueryRefsByDefID (Unsafe Concatenation)"]\n QueryHandler -->|3. Read Malicious Block ID| SQLite["SQLite Database Engine (SQL Injection)"]\n SQLite -->|4. High Resource Consumption| Crash["Service Outage / DoS"]\n\n\nThis diagram illustrates the execution flow. The unauthenticated request successfully bypasses the router, leverages the unsafe query construction on the backend, and causes SQLite to execute expensive procedures, leading to Denial-of-Service conditions.

The impact of CVE-2026-72812 varies depending on whether the primary authorization bypass is executed alone or chained with the secondary SQL injection vulnerability. On its own, the authorization bypass allows read-only users to force write-queue flushes (FlushTxQueue) and backlink recalculations. In shared personal knowledge workspaces, this leads to CPU spikes, high disk write overhead, and localized denial-of-service.\n\nWhen chained with the SQL injection flaw, the impact escalates. Because the SQL execution context is SQLite, arbitrary database execution remains confined to database-accessible commands. However, attackers can leverage SQL injection to read sensitive notebook databases, retrieve application configurations, or exhaust server system resources through recursive calculations such as generating large random blobs in memory.\n\nThe CVSS 3.1 base score is 6.5, with an environmental vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L. This score reflects that while the access control vulnerability is unauthenticated and simple to exploit, the resulting write impact is restricted compared to remote shell access.

The definitive resolution for this issue is upgrading the SiYuan container, application binary, or package deployment to version v3.7.4 or higher. This release integrates both the route-level authorization checks and the database CTE query parameterized replacements, resolving both components of the vulnerability.\n\nFor deployments where immediate updates are not possible, administrators must implement network-level mitigations. Ensure that access to the default API port 6806 is restricted to local interfaces (127.0.0.1 or localhost). If running public publish modes, configure an upfront reverse proxy (such as Nginx or Caddy) to drop incoming external HTTP traffic targeting /api/ endpoints.\n\nNetwork-based intrusion detection systems can inspect payload metrics to identify abuse patterns. For example, monitoring high frequencies of requests to /api/ref/refreshBacklink from non-administrative IP addresses can expose exploit attempts. Similarly, database transaction logging can be used to track unvalidated string patterns inside block query executions.