Summary
SiYuan: getUniqueFilename passes an unvalidated client-supplied path to the filesystem, giving anonymous readers an existence oracle over the entire host filesystem
/api/file/getUniqueFilename takes a path from the request body and passes it to a filesystem existence check with no validation, confinement or authorization. The response distinguishes paths that exist from paths that do not, so an anonymous reader in publish mode can probe arbitrary locations on the host, one request per probe. Files and directories both work.
Every neighbouring file route either requires an administrator or confines the path first.
Details
Route. kernel/api/router.go:289 on master, :292 on the development branch, CheckAuth only.
Handler, kernel/api/file.go:84, in full:
util.ParseJsonArgs(arg, ret, util.BindJsonArg("path", &filePath, true, true))
ret.Data = map[string]any{"path": util.GetUniqueFilename(filePath)}
The argument binder does no path handling. util.BindJsonArg (kernel/util/net.go:365) takes two booleans, required (the key must be present) and rejectEmpty (the value must be non-empty). That is its entire contract. There is no filepath.Clean, no workspace join, no traversal check. An absolute path outside the workspace reaches gulu.File.IsExist unmodified.
The oracle. util/file.go:67:
if !gulu.File.IsExist(filePath) {
return filePath
}
// otherwise loop, returning the first non-existent dir/base (i).ext
Input echoed back means the path does not exist. A (1) suffix means it does.
The asymmetry.
| Route | Middleware |
|---|---|
putFile, copyFile, globalCopyFiles, workspaceCopyFiles, removeFile, renameFile |
CheckAuth, CheckAdminRole, CheckReadonly |
readDir (directory enumeration) |
CheckAuth, CheckAdminRole |
getFile |
CheckAuth, but GetAbsPathInWorkspace returns 403 on escape, plus rejectEncryptedBoxPath and a publish-access check |
getUniqueFilename |
CheckAuth, nothing else |
getFile binds the identical BindJsonArg("path", &filePath, true, true) and confines it as its first action.
Proof of Concept
Kernel 3.7.2, publish mode on port 6808, Publish.Auth.Enable false, anonymous client. Reader context confirmed by getChildBlocks returning HTTP 403 on the same session.
{"path":"/etc/passwd"}
→ {"code":0,"msg":"","data":{"path":"/etc/passwd (1)"}}
{"path":"/etc/shadow"}
→ {"code":0,"msg":"","data":{"path":"/etc/shadow (1)"}}
{"path":"/etc/definitely-not-here"}
→ {"code":0,"msg":"","data":{"path":"/etc/definitely-not-here"}}
Directories behave the same way:
{"path":"/root"} → {"path":"/root (1)"}
{"path":"/rootnope"} → {"path":"/rootnope"}
And within the workspace, confirming whether a specific document file exists:
{"path":"<workspace>/data/<boxID>/<docID>.sy"} → "<...> (1).sy"
{"path":"<workspace>/data/nope-no-such.sy"} → echoed unchanged
Impact
An anonymous reader in publish mode, or any publish RoleReader, determines whether arbitrary paths exist on the host. Because directories respond the same way as files, the filesystem can be walked rather than only guessed at. This supports identifying the operating-system user's home directory, detecting installed software, backup and synchronisation directories, mapping the workspace layout, and confirming the existence of specific documents by probing their storage paths.
It also composes with the absolute workspace path returned elsewhere, which supplies a concrete prefix rather than requiring guesswork, and it recovers the operating-system username that the browser-request path strip added under issue #17410 was introduced to conceal.
Scoped precisely: nothing is read and nothing is written. This is an existence and layout disclosure, valuable primarily as a reconnaissance step.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
CVE-2026-73605 has a CVSS score of 5.8 (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-20260812083335-251596fc0de2); upgrading removes the vulnerable code path.
Affected versions
Security releases
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
Confine the path as the adjacent getFile route does, by routing filePath through util.GetAbsPathInWorkspace and returning 403 on escape, or add CheckAdminRole and CheckReadonly to match readDir. The frontend uses this endpoint only for naming uploads and assets inside the workspace, so neither change affects legitimate use.
Frequently Asked Questions
- What is CVE-2026-73605? CVE-2026-73605 is a medium-severity missing authorization vulnerability in github.com/siyuan-note/siyuan/kernel (go), affecting versions < 0.0.0-20260812083335-251596fc0de2. It is fixed in 0.0.0-20260812083335-251596fc0de2. The application does not perform an authorization check before performing a sensitive operation.
- How severe is CVE-2026-73605? CVE-2026-73605 has a CVSS score of 5.8 (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.
- Which versions of github.com/siyuan-note/siyuan/kernel are affected by CVE-2026-73605? github.com/siyuan-note/siyuan/kernel (go) versions < 0.0.0-20260812083335-251596fc0de2 is affected.
- Is there a fix for CVE-2026-73605? Yes. CVE-2026-73605 is fixed in 0.0.0-20260812083335-251596fc0de2. Upgrade to this version or later.
- Is CVE-2026-73605 exploitable, and should I be worried? Whether CVE-2026-73605 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
- What actually determines whether CVE-2026-73605 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.
- How do I fix CVE-2026-73605? Upgrade
github.com/siyuan-note/siyuan/kernelto 0.0.0-20260812083335-251596fc0de2 or later.