SiYuan Note LFD: Turning Personal Knowledge into Public Property

SiYuan markets itself as a "privacy-first" personal knowledge management system. It's the kind of tool where you store your deepest thoughts, your startup ideas, and maybe your API keys. It runs locally or on a private server, promising that your data belongs to you.

But as any security researcher knows, the more a product screams "privacy," the more ironic its inevitable security failure will be. CVE-2026-23850 is a textbook example of a convenience feature tearing a hole through that privacy promise. It turns the application into a glorified file server for anyone with a login.

This isn't a complex buffer overflow or a race condition. It is a logic flaw born from the desire to make the user experience smoother. The developers wanted to let you save external images locally. They just forgot to check if those "images" were actually system files like /etc/passwd.

The vulnerability lives in a feature called netAssets2LocalAssets. The logic is simple: you write a Markdown document with a link to an image (e.g., ![cat](http://cat.com/meow.jpg)), and the server fetches that image and saves it to your local workspace so you don't lose it if the internet goes down.

The problem? The function netAssets2LocalAssets0 in kernel/model/assets.go trusted the input implicitly. It parses the Markdown, extracts the link, and hands it off to a resource fetcher.

It failed to ask two critical questions:

1. What protocol are we using? (It accepted file:// just as happily as http://).
2. Where does this point? (It didn't validate if the target was localhost, a private IP, or a sensitive system path).

If you passed it file:///etc/shadow, the server reasoned: "Ah, the user wants to save a local copy of this file. I shall read it and place it in the public assets folder for them."

Let's look at the logic flow. The vulnerable code effectively treated any string inside []() or ![]() as a target for retrieval.

Here is a conceptual simplification of what was happening server-side:

// Pseudo-code of the vulnerable logic
func netAssets2LocalAssets(link string) {
    // No check for 'file://' prefix!
    data, err := readFileOrNetwork(link)
    if err == nil {
        // Saves content to /data/assets/network-asset-xxx
        saveToPublicDir(data)
    }
}

The fix, introduced in version 3.5.4, didn't actually disable the file:// protocol or implement a robust whitelist. Instead, it introduced a utility function IsSensitivePath in kernel/util/path.go.

This function acts as a massive blocklist (a "deny list"). It explicitly checks if the path contains strings like:

• /etc/passwd, /etc/shadow
• .ssh, id_rsa
• .env, config.yaml

> [!ALERT] > Researcher Note: Blacklists are notoriously difficult to maintain. While this stops the script kiddie copying a /etc/passwd PoC, it leaves the door open for creative attackers to find files that aren't on the list, or to use the SSRF vector to hit internal metadata endpoints (like AWS 169.254.169.254), which are rarely file paths.

Exploiting this requires an authenticated session, but in many self-hosted instances, users share credentials or use weak auth codes. Here is how we turn a note-taking app into a data exfiltration tool.

1. Login: Authenticate to the API.
2. Plant the Bait: Create a new Markdown note via /api/filetree/createDocWithMd.

   {
     "markdown": "[loot](file:///etc/passwd)"
   }

3. Trigger the Trap: Call the asset conversion endpoint /api/format/netAssets2LocalAssets on the document ID you just created.
4. The Server Obeys: The server reads /etc/passwd, thinks it's downloading an asset, and saves it to /data/assets/ with a name like network-asset-passwd-xyz.txt.
5. Exfiltrate: List the directory contents via /api/file/readDir to find the generated filename, then download it directly via the web interface.

The impact here is twofold: Local File Disclosure (LFD) and Server-Side Request Forgery (SSRF).

LFD: Attackers can grab configuration files. If SiYuan is running in a Docker container, you might just get container configs. But if it's running on bare metal (common for personal servers), you could grab SSH keys (~/.ssh/id_rsa), the app's own database credentials, or environment variables containing API keys for third-party integrations.

SSRF: Since the validator doesn't block IP addresses, an attacker could force the server to scan the internal network.

• [router](http://192.168.1.1/admin) -> Saves the router login page.
• [cloud](http://169.254.169.254/latest/meta-data/) -> If hosted on AWS/GCP, this could leak the instance IAM role credentials, leading to full cloud account compromise.

The vendor patched this in version 3.5.4. The patch (Commits b2274bab and f8f4b517) implements the IsSensitivePath check.

Critique: The fix is a "band-aid." It patches the symptom (reading sensitive files) by blocking specific filenames, rather than addressing the root cause (unrestricted protocol usage). A more robust fix would have been to:

1. Whitelist protocols: Only allow http and https.
2. Disable local interaction: Explicitly ban file://.
3. Implement an egress filter: Block calls to private IP ranges (RFC 1918) to prevent SSRF.

For now, the blocklist stops the obvious attacks, but savvy researchers will likely be fuzzing that IsSensitivePath function looking for bypasses involving symbolic links, alternative encodings, or unlisted sensitive files.