CVE-2026-73630

SiYuan before v3.7.4 contains an information disclosure vulnerability in the /api/filetree/authFilePublishAccess endpoint, which is registered with CheckAuth only and is reachable anonymously. The endpoint never sets a failure code, so its outcome is signalled entirely by the response message and by the presence of a Set-Cookie header, and these signals differ across access tiers. By submitting requests with an empty password for a candidate document identifier, an anonymous attacker can distinguish whether a document is public/nonexistent, password-protected, or exists at the hidden or forbidden tier, thereby confirming the existence of documents they are not permitted to access. Because hidden and forbidden entries store an empty password, such requests also cause the server to issue a publish-auth cookie for forbidden documents.

SiYuan before v3.7.4 contains an information disclosure vulnerability in the /api/filetree/authFilePublishAccess endpoint, which is registered with CheckAuth only and is reachable anonymously. The endpoint never sets a failure code, so its outcome is signalled entirely by the response message and by the presence of a Set-Cookie header, and these signals differ across access tiers. By submitting requests with an empty password for a candidate document identifier, an anonymous attacker can distinguish whether a document is public/nonexistent, password-protected, or exists at the hidden or forbidden tier, thereby confirming the existence of documents they are not permitted to access. Because hidden and forbidden entries store an empty password, such requests also cause the server to issue a publish-auth cookie for forbidden documents.

Summary

/api/filetree/authFilePublishAccess is registered with CheckAuth only and is reachable anonymously. It never sets a failure code, so its outcome is signalled entirely by the response message and by whether a Set-Cookie header is present. Those two signals differ across access tiers, which lets an anonymous caller determine, for any candidate document identifier, whether that document is public or nonexistent, password-protected, or exists at the hidden or forbidden tier.

Separately, hidden and forbidden entries carry an empty password. Submitting password:"" therefore satisfies the equality check for them, and the server responds by issuing Set-Cookie: publish-auth-<docID> for a document whose own tier is forbidden.

Details

Route, identical on both refs:

ginServer.Handle("POST", "/api/filetree/authFilePublishAccess", model.CheckAuth, authFilePublishAccess)

No CheckAdminRole, no CheckReadonly.

Handler, kernel/api/filetree.go:1608 on the development branch and :1421 on master. ret.Code is never assigned on the failure path, so every response carries code:0. The branch is:

if item.Password == password {
    // SetPublishAuthCookie
} else {
    ret.Msg = Conf.Language(285)
}

The cookie is issued for forbidden documents. Entries at the hidden and forbidden tiers store Password == "". A request with password:"" therefore makes item.Password == password true for them, and the handler takes the success branch. The server issues a publish-auth cookie for a document it otherwise treats as inaccessible.

The cookie itself confers nothing, because those tiers are decided before any password check elsewhere in the codebase. The defect is that the endpoint's success signal does not correspond to access being granted, and that signal is observable.

Three distinguishable outcomes. With password:"", one request per candidate identifier:

| Tier of the target | Set-Cookie | Body | |---|---|---| | Public (no publish-access entry) | absent | {"code":0,"msg":""} | | Nonexistent identifier | absent | {"code":0,"msg":""} | | Password-protected | absent | {"code":0,"msg":"Password is incorrect"} | | Hidden | present | {"code":0,"msg":""} | | Forbidden | present | {"code":0,"msg":""} |

Public and nonexistent are indistinguishable from each other, which is correct. Everything else separates. A caller learns whether a given identifier names a password-protected document, or a document that exists at the hidden or forbidden tier, which is precisely the class the publish tiers exist to conceal.

Identifiers are readily available. Document and block identifiers appear in the DOM of published pages, in reference and backlink payloads, and in annotation reference data. The caller does not need to guess them.

A fourth response on the development branch. IsEncryptedPublishRuntimeTarget sets ret.Code = -1, which identifies the supplied identifier as belonging to an encrypted notebook. That is a membership oracle for encrypted notebooks, the same data class as GHSA-f2rw-w22v-54vh.

Proof of Concept

Publish mode enabled, Publish.Auth.Enable false, anonymous client. One request per candidate identifier, all with an empty password:

POST /api/filetree/authFilePublishAccess
{"id":"<candidate document id>","password":""}

Comparing the response message and the presence of Set-Cookie against the table above classifies the identifier. Documents at the hidden and forbidden tiers return a publish-auth cookie and an empty message, distinguishing them both from public documents and from identifiers that name nothing at all.

Impact

An anonymous reader in publish mode, or any publish RoleReader, can classify arbitrary document identifiers by access tier and confirm the existence of documents at the hidden and forbidden tiers. On the development branch the same endpoint additionally reveals whether an identifier belongs to…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-4pjg-x8qj-33j5. This link is maintained to preserve external references.

Original Description

SiYuan before v3.7.4 contains an information disclosure vulnerability in the /api/filetree/authFilePublishAccess endpoint, which is registered with CheckAuth only and is reachable anonymously. The endpoint never sets a failure code, so its outcome is signalled entirely by the response message and by the presence of a Set-Cookie header, and these signals differ across access tiers. By submitting requests with an empty password for a candidate document identifier, an anonymous attacker can distinguish whether a document is public/nonexistent, password-protected, or exists at the hidden or forbidden tier, thereby confirming the existence of documents they are not permitted to access. Because hidden and forbidden entries store an empty password, such requests also cause the server to issue a publish-auth cookie for forbidden documents.

SiYuan before v3.7.4 contains an information disclosure vulnerability in the /api/filetree/authFilePublishAccess endpoint, which is registered with CheckAuth only and is reachable anonymously. The endpoint never sets a failure code, so its outcome is signalled entirely by the response message and by the presence of a Set-Cookie header, and these signals differ across access tiers. By submitting requests with an empty password for a candidate document identifier, an anonymous attacker can distinguish whether a document is public/nonexistent, password-protected, or exists at the hidden or forbidden tier, thereby confirming the existence of documents they are not permitted to access. Because hidden and forbidden entries store an empty password, such requests also cause the server to issue a publish-auth cookie for forbidden documents.

Summary

/api/filetree/authFilePublishAccess is registered with CheckAuth only and is reachable anonymously. It never sets a failure code, so its outcome is signalled entirely by the response message and by whether a Set-Cookie header is present. Those two signals differ across access tiers, which lets an anonymous caller determine, for any candidate document identifier, whether that document is public or nonexistent, password-protected, or exists at the hidden or forbidden tier.

Separately, hidden and forbidden entries carry an empty password. Submitting password:"" therefore satisfies the equality check for them, and the server responds by issuing Set-Cookie: publish-auth-<docID> for a document whose own tier is forbidden.

Details

Route, identical on both refs:

ginServer.Handle("POST", "/api/filetree/authFilePublishAccess", model.CheckAuth, authFilePublishAccess)

No CheckAdminRole, no CheckReadonly.

Handler, kernel/api/filetree.go:1608 on the development branch and :1421 on master. ret.Code is never assigned on the failure path, so every response carries code:0. The branch is:

if item.Password == password {
    // SetPublishAuthCookie
} else {
    ret.Msg = Conf.Language(285)
}

The cookie is issued for forbidden documents. Entries at the hidden and forbidden tiers store Password == "". A request with password:"" therefore makes item.Password == password true for them, and the handler takes the success branch. The server issues a publish-auth cookie for a document it otherwise treats as inaccessible.

The cookie itself confers nothing, because those tiers are decided before any password check elsewhere in the codebase. The defect is that the endpoint's success signal does not correspond to access being granted, and that signal is observable.

Three distinguishable outcomes. With password:"", one request per candidate identifier:

| Tier of the target | Set-Cookie | Body | |---|---|---| | Public (no publish-access entry) | absent | {"code":0,"msg":""} | | Nonexistent identifier | absent | {"code":0,"msg":""} | | Password-protected | absent | {"code":0,"msg":"Password is incorrect"} | | Hidden | present | {"code":0,"msg":""} | | Forbidden | present | {"code":0,"msg":""} |

Public and nonexistent are indistinguishable from each other, which is correct. Everything else separates. A caller learns whether a given identifier names a password-protected document, or a document that exists at the hidden or forbidden tier, which is precisely the class the publish tiers exist to conceal.

Identifiers are readily available. Document and block identifiers appear in the DOM of published pages, in reference and backlink payloads, and in annotation reference data. The caller does not need to guess them.

A fourth response on the development branch. IsEncryptedPublishRuntimeTarget sets ret.Code = -1, which identifies the supplied identifier as belonging to an encrypted notebook. That is a membership oracle for encrypted notebooks, the same data class as GHSA-f2rw-w22v-54vh.

Proof of Concept

Publish mode enabled, Publish.Auth.Enable false, anonymous client. One request per candidate identifier, all with an empty password:

POST /api/filetree/authFilePublishAccess
{"id":"<candidate document id>","password":""}

Comparing the response message and the presence of Set-Cookie against the table above classifies the identifier. Documents at the hidden and forbidden tiers return a publish-auth cookie and an empty message, distinguishing them both from public documents and from identifiers that name nothing at all.

Impact

An anonymous reader in publish mode, or any publish RoleReader, can classify arbitrary document identifiers by access tier and confirm the existence of documents at the hidden and forbidden tiers. On the development branch the same endpoint additionally reveals whether an identifier belongs to…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-4pjg-x8qj-33j5. This link is maintained to preserve external references.

Original Description

SiYuan before v3.7.4 contains an information disclosure vulnerability in the /api/filetree/authFilePublishAccess endpoint, which is registered with CheckAuth only and is reachable anonymously. The endpoint never sets a failure code, so its outcome is signalled entirely by the response message and by the presence of a Set-Cookie header, and these signals differ across access tiers. By submitting requests with an empty password for a candidate document identifier, an anonymous attacker can distinguish whether a document is public/nonexistent, password-protected, or exists at the hidden or forbidden tier, thereby confirming the existence of documents they are not permitted to access. Because hidden and forbidden entries store an empty password, such requests also cause the server to issue a publish-auth cookie for forbidden documents.

SiYuan: authFilePublishAccess distinguishes hidden and forbidden documents from public and nonexistent ones, and issues a publish-auth cookie for documents it reports as forbidden in github.com/siyuan-note/siyuan/kernel