CVE-2026-73605

SiYuan versions before v3.7.4 contain a path traversal vulnerability in the getUniqueFilename endpoint that allows anonymous readers to probe filesystem existence without validation or confinement. Attackers can supply arbitrary absolute paths to determine whether files and directories exist on the host, enabling reconnaissance of the filesystem layout and installed software.

SiYuan versions before v3.7.4 contain a path traversal vulnerability in the getUniqueFilename endpoint that allows anonymous readers to probe filesystem existence without validation or confinement. Attackers can supply arbitrary absolute paths to determine whether files and directories exist on the host, enabling reconnaissance of the filesystem layout and installed software.

Summary

/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.

Suggested fix

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…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-hf8h-97gm-4x2p. This link is maintained to preserve external references.

Original Description

SiYuan versions before v3.7.4 contain a path traversal vulnerability in the getUniqueFilename endpoint that allows anonymous readers to probe filesystem existence without validation or confinement. Attackers can supply arbitrary absolute paths to determine whether files and directories exist on the host, enabling reconnaissance of the filesystem layout and installed software.

SiYuan versions before v3.7.4 contain a path traversal vulnerability in the getUniqueFilename endpoint that allows anonymous readers to probe filesystem existence without validation or confinement. Attackers can supply arbitrary absolute paths to determine whether files and directories exist on the host, enabling reconnaissance of the filesystem layout and installed software.

Summary

/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.

Suggested fix

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…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-hf8h-97gm-4x2p. This link is maintained to preserve external references.

Original Description

SiYuan versions before v3.7.4 contain a path traversal vulnerability in the getUniqueFilename endpoint that allows anonymous readers to probe filesystem existence without validation or confinement. Attackers can supply arbitrary absolute paths to determine whether files and directories exist on the host, enabling reconnaissance of the filesystem layout and installed software.

SiYuan: getUniqueFilename passes an unvalidated client-supplied path to the filesystem, giving anonymous readers an existence oracle over the entire host filesystem in github.com/siyuan-note/siyuan/kernel