SiYuan: The publish filter for database backlinks consults the forbidden list instead of the visibility list, disclosing hidden-tier documents to anonymous readers

Summary

/api/av/getAttributeViewBacklinks filters its results for reader roles through FilterAttributeViewBacklinksByPublishAccess. That function resolves its ignore list with GetDisablePublishAccess, which covers only the forbidden tier. Documents at the hidden tier are absent from that list, so they pass the check.

The result is that an anonymous reader supplying a publicly visible database row receives the database name, row title and document path of rows in hidden documents that reference it.

The rest of the function is correct. It takes *gin.Context and calls GetPathPasswordByPublishAccess and CheckPublishAuthCookie at all four decision points, so the password-protected and private tiers are properly enforced. The defect is the choice of list, on one line.

Details

Route, kernel/api/router.go:545 on the development branch and :527 on master:

ginServer.Handle("POST", "/api/av/getAttributeViewBacklinks", model.CheckAuth, getAttributeViewBacklinks)

CheckAuth only. No CheckAdminRole, no CheckReadonly.

The defect. In FilterAttributeViewBacklinksByPublishAccess (kernel/model/publish_access.go:1060 on dev, :435 on master):

publishIgnore := GetDisablePublishAccess(publishAccess)

GetDisablePublishAccess returns only entries at the forbidden tier. A hidden document has visible:false, password:"", disable:false, so it does not appear in that list. CheckPathAccessableByPublishIgnore therefore returns true for it, and because the password is empty the authentication branch short-circuits. Hidden documents pass both halves of the check.

The sibling filter uses the correct list. The regular backlink panel is the same product feature in the same UI, and it is gated properly. kernel/api/ref.go:170 getBacklink2 calls FilterPathsByPublishAccess, which at kernel/model/publish_access.go:1256 resolves its list with GetInvisiblePublishAccess. Two backlink filters in the same file, opposite list choices.

The distinction the tiers are meant to draw. The shipped description of the hidden tier, from app/appearance/langs/en.json:

publishAccessHiddenComment = "Not publicly visible, can be accessed directly."

A direct-access endpoint using the forbidden list is consistent with that: hidden documents are meant to be reachable when the caller already knows the identifier. Backlink discovery is not direct access. The caller supplies the target row and receives the identities of referring rows it never named, which is enumeration, and enumeration is precisely what "not publicly visible" excludes.

Origin. The filter was introduced by 6da2c736e (2026-07-18, "Show database relation backlinks in the attribute panel", #10599) with this list choice from the start. No security-focused commit has touched the attribute-view backlink path since.

What is returned. Per matched backlink: AvName (the database name), Title (the row title), DatabasePath (the HPath of the containing document), BoxID, DatabaseBlockID, and Relations[].KeyName. These are author-written names and titles, not opaque identifiers.

Proof of Concept

Publish mode enabled, Publish.Auth.Enable false, anonymous client with no credentials or cookies. Document A is public and holds a database with a row. Document B is set to varying tiers and holds a database whose relation field points at A's row. The attacker needs only A's avID and itemID, both present in the DOM of A's own published page.

Listing control first, establishing that the platform agrees B must not be listed:

POST /api/filetree/listDocsByPath
→ returns only the public document

Then the same backlinks request at four tier settings, spaced to clear the 30-second GetPublishAccess() cache:

The forbidden row confirms that the disable list is what the filter consults. The private row confirms that the password half works correctly. The gap is the hidden tier alone.

POST /api/av/getAttributeViewBacklinks
{"avID":"<public database id>","itemID":"<public row id>"}

→ 200, total:1, disclosing the database name, row title and document path
       of a document the same session cannot list

Impact

An anonymous reader in publish mode, or any publish RoleReader, discovers that a hidden document contains a database row referencing a public one, and receives that row's title, its database's name, and the containing document's path. Names and titles are author-written and routinely describe their subject, so this discloses both the existence and the topic of documents the author marked as not publicly visible.

The reader does not need to know anything about the hidden document beforehand. The only input is a public row identifier taken from a page they are already entitled to view.

Confidentiality only, with no integrity or availability impact. No document body content is returned.

Suggested fix

Change the list resolution in FilterAttributeViewBacklinksByPublishAccess to GetInvisiblePublishAccess, mirroring FilterPathsByPublishAccess on the regular backlink path. The password handling in the function is already correct and needs no change.