CVE-2026-73605: Path Traversal and File Existence Oracle via getUniqueFilename Endpoint in SiYuan

This section outlines the attack surface and core mechanism of CVE-2026-73605, a vulnerability discovered in the SiYuan personal knowledge management platform. The affected component is the github.com/siyuan-note/siyuan/kernel package, specifically within the API routing and handling logic. The vulnerability manifests as a path traversal vulnerability and a file existence oracle, allowing remote users to query the host filesystem.

The primary exposure exists in the /api/file/getUniqueFilename endpoint, which is designed to assist the frontend editor in resolving file name conflicts for assets. Under normal workspace operation, path arguments should be restricted and confined to the user’s designated workspace path (the storage directory containing the .sy note files). However, /api/file/getUniqueFilename failed to enforce workspace confinement, allowing input absolute paths to escape to the host filesystem.

An attacker can exploit this endpoint to verify the existence of files and directories across the host operating system. The vulnerability is classified under CWE-862 (Missing Authorization) and carries a CVSS v4.0 base score of 6.9, reflecting its role as a high-fidelity reconnaissance mechanism.

The root cause of CVE-2026-73605 resides in the lack of path sanitization and directory confinement controls within the getUniqueFilename API handler. When the frontend requests a unique filename, the application accepts a user-provided file path parameter without performing verification against the configured workspace directory. This omission allows an absolute path referencing directories outside the intended application sandbox to reach the underlying helper function.

The input processing chain begins in kernel/api/file.go inside the handler for /api/file/getUniqueFilename. The utility function util.BindJsonArg verifies that the path argument exists and is not empty, but it does not perform directory verification or normalization. Consequently, the raw path is passed directly to the util.GetUniqueFilename helper located in util/file.go.

Within the helper function, the application invokes gulu.File.IsExist using the unchecked input path. If the file or directory exists on the host operating system, the function appends an incremented numerical suffix and returns the modified path. If the file does not exist, the helper returns the original input path verbatim, establishing a binary response condition that serves as an oracle.

Analyzing the application router configuration in kernel/api/router.go highlights the discrepancy in access control configurations. While file management routes like /api/file/putFile are restricted with CheckAdminRole and CheckReadonly middleware, /api/file/getUniqueFilename only implements the basic CheckAuth middleware. This setup permits users in anonymous viewing or publish modes to bypass administrative checks and interact with the file endpoint.

The handler function processes JSON arguments and maps the path key directly to the underlying utility without applying workspace boundaries:

// Vulnerable code in kernel/api/file.go
func getUniqueFilename(c *gin.Context) {
    var filePath string
    ret := gulu.Ret.NewResult()
    defer c.JSON(http.StatusOK, ret)
    
    // Parses and binds the JSON argument without restricting the path to the workspace
    if err := util.ParseJsonArgs(c, ret, util.BindJsonArg("path", &filePath, true, true)); err != nil {
        return
    }
    
    // Direct invocation of the oracle helper using the raw parameter
    ret.Data = map[string]any{"path": util.GetUniqueFilename(filePath)}
}

By contrast, secure endpoints utilize functions such as util.GetAbsPathInWorkspace to validate that input paths resolve within the strict boundaries of the designated storage directory. The omission of this verification step in /api/file/getUniqueFilename enables the path traversal condition.

An attacker can exploit this vulnerability by issuing HTTP POST requests containing targeted absolute paths to the /api/file/getUniqueFilename endpoint. Because the application returns different responses based on file existence, the attacker can systematically probe the host file system. This technique requires no special execution environment or timing measurements, as the server returns a distinct string modification.

For instance, an attacker probing for the existence of /etc/passwd sends a payload containing that exact absolute path. If the file is present, the server returns /etc/passwd (1) in the response JSON. If the file is absent, the server returns /etc/passwd unmodified. This predictable divergence allows high-speed automated tools to map files.

POST /api/file/getUniqueFilename HTTP/1.1
Host: target.local:6808
Content-Type: application/json
 
{
  "path": "/etc/passwd"
}

The server response for an existing file:

{
  "code": 0,
  "msg": "",
  "data": {
    "path": "/etc/passwd (1)"
  }
}

The primary consequence of this vulnerability is the disclosure of the host file system structure, which facilitates advanced targeted attacks. Although the oracle does not allow attackers to read file contents or write files to the server, it reveals configuration files, installed software, and system usernames. This reconnaissance capability is critical during the initial stages of an intrusion.

Attackers can verify the presence of specific software packages, configuration templates, and administrative directories, such as /var/run/docker.sock or /etc/nginx/nginx.conf. This information allows them to identify secondary vulnerabilities or misconfigurations. Furthermore, querying directories like /home/ or /Users/ reveals active system usernames, negating previous privacy mitigations.

The vulnerability also impacts the security of private notebooks. If an attacker knows or guesses the structures of workspace directories, they can verify the presence of sensitive notebook identifiers and document keys. The CVSS v3.1 score is evaluated at 5.8 with a scope change (S:C), because the sandbox escape leaks host system state information.

Remediation requires upgrading the SiYuan application to version 3.7.4 or later, which restricts path inputs to the workspace directory. Organizations unable to apply the update immediately must implement network access controls to limit access to the workspace. Restricting the API to trusted IP addresses or disabling the public sharing and publish features mitigates the risk of exposure to external threat actors.

To detect ongoing exploitation, administrators should monitor web server and application logs for unusual request patterns targeting /api/file/getUniqueFilename. A sequence of requests containing system directories, configuration files, or absolute paths outside the workspace indicates directory scanning. Security teams can deploy web application firewall rules to detect and block absolute paths within JSON parameters to this route.

An example detection signature targeting this behavior involves searching for standard system files inside the JSON request body. Deploying Suricata or Snort rules can identify attempts to query common Linux or Windows system files through the affected endpoint.