GHSA-4pjg-x8qj-33j5

Dashboard / Vulnerabilities / GHSA-4pjg-x8qj-33j5

GHSA-4pjg-x8qj-33j5

Summary: SiYuan: authFilePublishAccess distinguishes hidden and forbidden documents from public and nonexistent ones, and issues a publish-auth cookie for documents it reports as forbidden

Details: ### 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: ```go 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: ```go 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 an encrypted notebook. Scoped precisely: no document content is disclosed and no privilege is gained, since the issued cookie is inert for these tiers. The value is as a confirmation primitive, turning an identifier obtained elsewhere into a definite statement about a document the reader is not permitted to see. Confidentiality only, with no integrity or availability impact. ### Suggested fix Return an identical response for every failure and for every tier the caller may not access, with no `Set-Cookie` header and no distinguishing message. In particular, do not treat an empty stored password as a successful match: hidden and forbidden entries should short-circuit before the password comparison rather than satisfying it. The encrypted-notebook branch should return the same generic response as everything else rather than its own code. A rate limit on this endpoint would be a reasonable additional hardening measure, though it does not address the disclosure above.

References: https://github.com/siyuan-note/siyuan/security/advisories/GHSA-4pjg-x8qj-33j5, https://nvd.nist.gov/vuln/detail/CVE-2026-73630, https://github.com/siyuan-note/siyuan/commit/c7522b8db586ef1e1d6fa98bbe7ca0eb9d019efe, https://github.com/siyuan-note/siyuan, https://github.com/siyuan-note/siyuan/releases/tag/v3.7.4-alpha.4, https://www.vulncheck.com/advisories/siyuan-before-information-disclosure-via-authfilepublishaccess