CVE-2026-72802

CVE-2026-72802 is a medium-severity security vulnerability in github.com/siyuan-note/siyuan/kernel (go), affecting versions < 0.0.0-20260724095509-eee3410aa131. It is fixed in 0.0.0-20260724095509-eee3410aa131.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

SiYuan: Absolute filesystem path and OS username disclosure via resolveAssetPath

CVE: This vulnerability corresponds to CVE-2026-72802.

POST /api/asset/resolveAssetPath returns the resolved absolute filesystem path of an asset, unmodified. The route is CheckAuth-only, so it is reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. An anonymous reader who knows any asset's relative path trivially harvested from an <img src="assets/…"> in any published document receives the server's absolute workspace path, disclosing the operating-system username and the installation layout.

Details

// kernel/api/asset.go: resolveAssetPath
p, err := model.GetAssetAbsPathInBox(path, "")   // boxID="" → absolute workspace path
...
ret.Data = p                                     // returned raw, no stripping

GetAssetAbsPathInBox(path, "") resolves under util.DataDir / util.WorkspaceDir, producing a full host path such as C:\Users\<username>\SiYuan\data\assets\foo.png or /home/<user>/…. The handler returns it directly with no redaction and no publish-scope check.

This is data the project already treats as sensitive. getConf explicitly zeroes System.WorkspaceDir, AppDir, ConfDir, DataDir, and HomeDir when util.IsBrowserRequest(c), a change made specifically to avoid leaking the username (issue #17410). resolveAssetPath performs no equivalent stripping, so it re-exposes precisely the values getConf was patched to hide.

Related unfiltered siblings in the same file, also CheckAuth-only with no publish scoping:

  • getMissingAssets: workspace-wide list of missing asset references
  • getUnusedAssets: every unused asset filename in the assets directory

Both return asset inventory spanning all documents, including publish-forbidden ones.

Verified at origin/master: resolveAssetPath returns the absolute path with no redaction, getConf contains the IsBrowserRequest stripping; all three routes are registered CheckAuth without CheckAdminRole.

Proof of Concept

Precondition: publish mode enabled (default port 6808); anonymous when Publish.Auth.Enable is false, otherwise any publish reader account.

1. Harvest an asset path: open any published document and read a relative asset path from its markup, e.g. assets/foo-20260101120000-abcdefg.png.

2. Resolve it as an anonymous reader:

POST http://127.0.0.1:6808/api/asset/resolveAssetPath
{"path":"assets/foo-20260101120000-abcdefg.png"}

3. Result: the response returns the absolute host path, e.g.
C:\Users\<username>\SiYuan\data\assets\foo-...png disclosing the OS username and the full workspace/installation layout.

Control: getConf from the same anonymous session returns WorkspaceDir/DataDir/HomeDir blanked, confirming the project intends these values to be withheld from browser requests.

Related:

POST http://127.0.0.1:6808/api/asset/getUnusedAssets   {}
POST http://127.0.0.1:6808/api/asset/getMissingAssets  {}

Return workspace-wide asset inventory with no publish scoping.

Impact

An anonymous reader (publish mode with auth disabled) or any publish RoleReader obtains the server's absolute workspace path, which typically embeds the OS username, plus the installation directory layout. This is useful for targeting subsequent attacks (path construction, user enumeration, social engineering) and directly contradicts the redaction the project applies in getConf. The related endpoints additionally disclose workspace-wide asset inventory, including assets referenced only by publish-forbidden documents. Confidentiality-only.

CVE-2026-72802 has a CVSS score of 5.3 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.0.0-20260724095509-eee3410aa131); upgrading removes the vulnerable code path.

Affected versions

github.com/siyuan-note/siyuan/kernel (< 0.0.0-20260724095509-eee3410aa131)

Security releases

github.com/siyuan-note/siyuan/kernel → 0.0.0-20260724095509-eee3410aa131 (go)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Apply the same redaction getConf uses: for browser/reader requests, return the asset path relative to the workspace root rather than the absolute host path (or omit it entirely). Add publish-access scoping to getUnusedAssets and getMissingAssets so their results are limited to documents the caller may see.

Frequently Asked Questions

  1. What is CVE-2026-72802? CVE-2026-72802 is a medium-severity security vulnerability in github.com/siyuan-note/siyuan/kernel (go), affecting versions < 0.0.0-20260724095509-eee3410aa131. It is fixed in 0.0.0-20260724095509-eee3410aa131.
  2. How severe is CVE-2026-72802? CVE-2026-72802 has a CVSS score of 5.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of github.com/siyuan-note/siyuan/kernel are affected by CVE-2026-72802? github.com/siyuan-note/siyuan/kernel (go) versions < 0.0.0-20260724095509-eee3410aa131 is affected.
  4. Is there a fix for CVE-2026-72802? Yes. CVE-2026-72802 is fixed in 0.0.0-20260724095509-eee3410aa131. Upgrade to this version or later.
  5. Is CVE-2026-72802 exploitable, and should I be worried? Whether CVE-2026-72802 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-72802 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-72802? Upgrade github.com/siyuan-note/siyuan/kernel to 0.0.0-20260724095509-eee3410aa131 or later.

Stop the waste.
Protect your environment with Kodem.