CVE-2026-54066 — kernel
HIGHCVE-2026-54066 is a high-severity (CVSS 7.5) Path Traversal vulnerability in github.com/siyuan-note/siyuan/kernel. A fix is available for github.com/siyuan-note/siyuan/kernel — see the affected versions and patch details below.
SiYuan: Path Traversal via Double URL Encoding in /assets/*path (publish mode arbitrary file─read)
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.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-54066.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-54066 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 380,526 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
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 patch for CVE-2026-41894 ("Path Traversal via Double URL Encoding") sanitized the /export/ route but the
identical root cause remains in the /assets/*path route. In publish mode (anonymous read-only HTTP endpoint,
default port 6808), an unauthenticated remote attacker can read arbitrary files inside WorkspaceDir — including
conf/conf.json (which contains the AccessAuthCode SHA256 hash, API token, and sync keys), temp/siyuan.db,
temp/blocktree.db, and siyuan.log — by double-URL-encoding .. segments.
Verified against siyuan v3.6.5:
GET /assets/%252e%252e/%252e%252e/conf/conf.json→ HTTP 200, 10349 bytes (conf.json served)GET /export/%252e%252e/%252e%252e/conf/conf.json→ HTTP 401 (patched)GET /assets/%2e%2e/conf/conf.json→ HTTP 404 (single-decode handled correctly)
Vulnerable Code
Step 1 — route & first decode (kernel/server/serve.go:587-626):
The router registers GET /assets/*path for the publish listener. Gin performs one URL decoding pass on URL.Path,
so a request for /assets/%252e%252e/... yields context.Param("path") == "/%2e%2e/%2e%2e/conf/conf.json" — literal
%2e%2e strings, which path.Clean cannot collapse.
Step 2 — second decode via fallback (kernel/model/assets.go:536-563, GetAssetAbsPath):
p, err := getAssetAbsPath(relativePath)
if nil != err {
// fallback
decoded, e := url.PathUnescape(relativePath) // ← line 548, second decode
if nil == e {
p, err = getAssetAbsPath(decoded)
}
}
After the fallback decodes %2e%2e to .., filepath.Join(DataDir, "../../conf/conf.json") is Clean-ed to
WorkspaceDir/conf/conf.json, an existing file.
Step 3 — publish-mode access gate fall-through (kernel/model/publish_access.go:288,
CheckAbsPathAccessableByPublishAccess):
if !filelock.IsSubPath(util.DataDir, absPath) {
return true // ← fall-through allows anything outside DataDir but inside WorkspaceDir
}
Because the resolved file is outside DataDir (it's in WorkspaceDir), the gate returns true and
IsSensitivePath() is never invoked — .db / .log / conf/ denylists do not apply to the /assets/ route at all
(unlike the patched /export/ route, which additionally checks IsSubPath(exportBaseDir, ...)).
Step 4 — file served (http.ServeFile): the request URL.Path contains literal %2e%2e, not .., so Go's
containsDotDot guard passes and the file is sent.
PoC
Preconditions: siyuan kernel running with publish mode enabled (conf.publish.enable = true). Publish mode is the
documented anonymous read-only endpoint for sharing notebooks.
$ curl -i "http://victim:6808/assets/%252e%252e/%252e%252e/conf/conf.json"
HTTP/1.1 200 OK
Content-Length: 10349
Content-Type: application/json
...
{"appearance":{...},"editor":{...},"system":{...},"accessAuthCode":"<sha256>","api":{"token":"<api token>"}, ...}
Compared with the patched route:
$ curl -i "http://victim:6808/export/%252e%252e/%252e%252e/conf/conf.json"
HTTP/1.1 401 Unauthorized
Root Cause
Three independent flaws combine:
GetAssetAbsPathperforms a secondurl.PathUnescapeas a "compatibility" fallback, re-introducing the double-decode primitive that the CVE-2026-41894 patch eliminated on/export/.CheckAbsPathAccessableByPublishAccessreturnstruefor any path outsideDataDir, even when that path is still insideWorkspaceDir(which containsconf/conf.json,temp/*.db,siyuan.log).- The
IsSensitivePath()denylist applied to/export/is not called from the/assets/handler.
Impact
Unauthenticated remote arbitrary file read inside WorkspaceDir. Confirmed-readable files include:
conf/conf.json—accessAuthCodeSHA256 (offline crackable), API token, S3/WebDAV sync credentials.temp/siyuan.db,temp/blocktree.db,temp/asset_content.db— full notebook content (SQLite).siyuan.log— internal paths, OS username, plugin info.
Compromise of accessAuthCode / API token escalates to authenticated kernel API access (full read/write of all
notebooks). Compromise of sync credentials escalates beyond the host.
Fix
- Remove the
url.PathUnescapefallback inGetAssetAbsPath(assets.go:548), matching the/export/patch. - In
CheckAbsPathAccessableByPublishAccess, replace theIsSubPath(DataDir, ...)fall-through with an explicit allowlist (onlyDataDirand its publishable subtree) and always callIsSensitivePath(). - Apply
IsSensitivePath()inside the/assets/*pathhandler inserve.goas defense-in-depth.
Status
Privately reported via GitHub Security Advisory. PoC reproduced locally against v3.6.5 (publish port 6808): GET /assets/%252e%252e/%252e%252e/conf/conf.json returned HTTP 200 / 10349 bytes.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/siyuan-note/siyuan/kernel | all versions | 0.0.0-20260628153353-2d5d72223df4go get github.com/siyuan-note/siyuan/kernel@v0.0.0-20260628153353-2d5d72223df4 |
Detection & 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.
Fix
Update github.com/siyuan-note/siyuan/kernel to 0.0.0-20260628153353-2d5d72223df4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-54066 is resolved across your whole dependency graph.
Workarounds
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.
How to detect CVE-2026-54066
A community-maintained Nuclei template exists for this CVE. You can scan for it directly:
nuclei -id cve-2026-54066 -u https://target- Template
- SiYuan <= 3.6.5 - Unauthenticated Path Traversal
- Severity
- high
- Impact
- Unauthenticated attackers can read conf/conf.json exposing the API token, accessAuthCode SHA256 hash, and sync credentials, enabling full authenticated API access to all notebooks.
- Remediation
- Update to SiYuan v3.7.0 or later.
Template by ProjectDiscovery nuclei-templates (0x_Akoko), MIT licensed. View the full template. Scan only systems you are authorised to test.
Frequently Asked Questions
Is CVE-2026-54066 in your dependencies?
Find it across Go, including transitive dependencies.