GHSA-4WWP-F6GW-6QM5: Sensitive Information Disclosure via Incomplete Path Blocklist in SiYuan

SiYuan is an open-source personal knowledge management platform designed to organize and synchronize markdown-formatted content. The core application exposes an HTTP API allowing users and integrated extensions to interact with the underlying database and file system. This architecture requires strict access control boundaries to prevent unauthorized directory traversal and direct retrieval of security-critical configuration files.

The file retrieval interface, specifically the /api/file/getFile endpoint, acts as a gateway for fetching system and workspace files. To secure this endpoint, the developers implemented a custom path-guard system intended to block access to sensitive data structures. This vulnerability arose from a logical deficiency within the path-guard implementation where the list of restricted files was constructed with an incomplete set of targets.

By exploiting this deficiency, an authenticated user or client possesses the capability to download raw cryptographic keys and CA certificates from the host system. The root cause lies in the application restricting access specifically to a singular configuration database file while neglecting other sensitive configuration material residing in the identical workspace directory.

The vulnerability is categorized as an incomplete blocklist (CWE-184) combined with path traversal limitations (CWE-22) leading to information exposure (CWE-200). Within the application backend, the file access operations are intercepted by the refuseToAccess helper function located in kernel/api/file.go. This function forwards the requested absolute file path to the IsForbiddenAbsPath validation routine in kernel/util/path_guard.go.

The IsForbiddenAbsPath routine was designed to normalize the requested path and compare it against critical application components. However, prior to version v3.8.2, the blocklist logic only checked for equality against the path of the main configuration file, conf/conf.json. No directory-level restrictions were established for the parent conf/ directory, allowing arbitrary file retrieval within that path if the file name did not match conf.json exactly.

During initial configuration, SiYuan generates and stores critical cryptographic assets within this exact conf/ directory. These assets include leaf TLS private keys, public leaf certificates, root CA certificates, and root CA private keys. Because these filenames were omitted from the explicit blocklist, the guard evaluated paths targeting these key files as safe, resulting in raw private key exposure.

To understand the exact code-level flaw, analyze the differences in kernel/util/path_guard.go before and after the patch. In the vulnerable implementation, the system verified the path using the following block:

// Vulnerable Code
func IsForbiddenAbsPath(abs string) bool {
    fileNorm := NormalizeAndResolve(abs)
 
    // Only forbidden configuration file conf/conf.json is blocked:
    confPath := NormalizeAndResolve(filepath.Join(ConfDir, "conf.json"))
    if fileNorm == confPath {
        return true
    }
 
    // ... (Template and snippet checks continue)
}

In this implementation, the filepath.Join(ConfDir, "conf.json") call creates a single static path. If an attacker queries a different file in the configuration directory, such as key.pem, the comparison fileNorm == confPath returns false.

To remediate this, the developer refactored the verification check to iterate over an explicit array of forbidden configuration files. The updated codebase in version v3.8.2 implements the path check with the following logic:

// Patched Code in v3.8.2
func IsForbiddenAbsPath(abs string) bool {
    fileNorm := NormalizeAndResolve(abs)
 
    // Block sensitive files under conf/ folder
    forbiddenConfFiles := []string{
        "conf.json",
        TLSCACertFilename, // Defined as "ca.key" / "ca.pem"
        TLSCAKeyFilename,
        TLSCertFilename,
        TLSKeyFilename,
    }
    for _, filename := range forbiddenConfFiles {
        if fileNorm == NormalizeAndResolve(filepath.Join(ConfDir, filename)) {
            return true
        }
    }
    // ...
}

This iterative validation evaluates each key constant, resolving the absolute path of every cryptographic asset to confirm whether the requested file matches any blocked item.

Exploitation of this vulnerability requires administrative or authenticated API access to the SiYuan local web interface. An attacker who has acquired the kernel authorization token can execute HTTP POST requests directed at /api/file/getFile to retrieve files.

The targeted paths are resolved using standard platform conventions, making the location of cryptographic files highly predictable. The attacker crafts a request payload containing the specific path of the private key relative to the workspace, such as /conf/key.pem or /conf/ca.key.

POST /api/file/getFile HTTP/1.1
Host: localhost:6806
Authorization: Token [API_TOKEN]
Content-Type: application/json
 
{
  "path": "/conf/key.pem"
}

The path-guard normalization function resolves the input to its canonical absolute filesystem representation. Because the requested file path does not match /conf/conf.json, the blocklist routine returns false. The server then reads the raw PEM-formatted private key from the filesystem and responds with the raw content in the JSON response payload.

Below is a flowchart representing this validation bypass path:

The security impact of retrieving raw private cryptographic keys is severe and directly compromises the integrity of transport security. In typical deployments, SiYuan utilizes TLS to protect transit data, sync structures, and authorize API clients securely. Compromising the leaf private key allows an attacker with network access to decrypt local or remote session traffic silently.

If the CA private key is obtained, the attacker can sign arbitrary SSL certificates. This allows the attacker to conduct Man-in-the-Middle (MitM) attacks against clients connecting to the platform, capturing passwords, active session cookies, or subsequent synchronization data.

The vulnerability holds a high severity rating because the exposure of core cryptographic secrets is irreversible without a manual certificate and key rotation sequence.

The patch implemented in version v3.8.2 restricts direct retrieval of the TLS certificates and key files by expanding the validation to cover defined constants. However, several minor implementation weaknesses exist. First, because the blocklist is file-specific rather than directory-specific, any newly added sensitive file inside the /conf/ directory in future updates will remain vulnerable until manually added to the blocklist array.

Second, validation bypass risks related to operating system specifics must be considered. On Windows systems where the 8.3 short filename generation (SFN) is enabled, files may be mapped to truncated names such as CONF~1/KEY~1.PEM. If the canonicalization helper NormalizeAndResolve does not call operating system-level APIs to expand 8.3 short paths, bypass opportunities remain.

A more robust architectural solution would involve directory-level blocking, preventing access to the entire conf/ hierarchy by default rather than relying on list enumeration.