CVE-2026-73049: SiYuan: hidden-tier docs leak via AV backlinks API

### 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: ```go 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): ```go 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: | Tier of document B | Result | |---|---| | Hidden (`visible:false`, no password, `disable:false`) | `total:1`, with `avName`, `title`, `databasePath` and `relations[].keyName` for the row in B | | Forbidden (`disable:true`) | `total:0` | | Private (password set) | `total:0` | | Hidden again (restored) | `total:1`, reproducible | 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.

An organization publishes a SiYuan workspace as a public knowledge base, with internal documents set to hidden so they are not listed. An anonymous attacker opens a public page, copies the avID and itemID of a database row from the DOM, and POSTs them to /api/av/getAttributeViewBacklinks without credentials. The response returns the database name, row title and document path of hidden documents that reference the row, for example project codenames or customer names. The attacker repeats this across public rows to map the hidden content and uses the titles for targeted phishing, social engineering or further reconnaissance.