5.8 Medium

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

CVE-2026-73630

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- 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…

Assessment

CVSS: 5.8 (v3.1)
Severity: Medium
EPSS: 0.00343% chance of exploitation in the next 30 days
Known exploited: Not listed in CISA KEV
Exploit availability: Nothing found in Exploit-DB, Metasploit, Nuclei or public PoC repositories
Published: 23 October 2026
Last updated: 23 October 2026
Affected: go · github.com/siyuan-note/siyuan/kernel
Weakness: CWE-203

CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

At the source

GitHub Advisories

References

Community proofs of concept

No community proof of concept yet. If you have one for a published vulnerability and the right to share it, add it below — it will appear here once reviewed.

Submit a proof of concept

Only for publicly disclosed vulnerabilities, and only material from testing you were authorised to perform. This platform does not buy, sell, or broker exploits — see earning from vulnerability research for legitimate bounty programs. Submissions are reviewed before they appear. Text only; do not include live credentials, personal data, or anything targeting systems you are not permitted to test.

Title *

Proof of concept *

Write-up (optional)

Affected versions (optional)

Name or handle (optional)

References (optional, one URL per line)

Licence for your contribution *

Private contact (optional, never shown)

Before you submit * This vulnerability is already publicly disclosed (it has a published CVE). This material comes only from testing I was authorised to perform. I have the legal right to publish this content and am not breaching any agreement by doing so. It contains no live credentials, personal data, or anything targeting systems I am not authorised to test. I understand it will be reviewed before it appears publicly and may be rejected. I agree to the submission terms.

What is 3 + 1? *

Query this programmatically

Agents can read this through the MCP endpoint, or over HTTP:

curl https://cve.zerocrew.in/api/cve/CVE-2026-73630