GHSA-p4m3-mgmm-c664
HIGHGHSA-p4m3-mgmm-c664 is a high-severity (CVSS 7.5) Path Traversal vulnerability in github.com/siyuan-note/siyuan/kernel. O3 Security confirms whether GHSA-p4m3-mgmm-c664 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SiYuan: Path Traversal via Double URL Encoding in /assets/*path (publish mode arbitrary file─read), Incomplete fix of CVE-2026-41894
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-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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-p4m3-mgmm-c664 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-p4m3-mgmm-c664 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-p4m3-mgmm-c664. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-p4m3-mgmm-c664 in your dependencies?
O3 detects GHSA-p4m3-mgmm-c664 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.