GHSA-P4QW-VX5P-G984
Vulnerability from github – Published: 2026-10-23 18:30 – Updated: 2026-10-23 18:30Summary
/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:
| 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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260730150429-5b42614311b0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73049"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-23T18:30:42Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\n`/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.\n\nThe 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.\n\nThe 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.\n\n### Details\n\n**Route,** `kernel/api/router.go:545` on the development branch and `:527` on master:\n\n```go\nginServer.Handle(\"POST\", \"/api/av/getAttributeViewBacklinks\", model.CheckAuth, getAttributeViewBacklinks)\n```\n\n`CheckAuth` only. No `CheckAdminRole`, no `CheckReadonly`.\n\n**The defect.** In `FilterAttributeViewBacklinksByPublishAccess` (`kernel/model/publish_access.go:1060` on dev, `:435` on master):\n\n```go\npublishIgnore := GetDisablePublishAccess(publishAccess)\n```\n\n`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.\n\n**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.\n\n**The distinction the tiers are meant to draw.** The shipped description of the hidden tier, from `app/appearance/langs/en.json`:\n\n```\npublishAccessHiddenComment = \"Not publicly visible, can be accessed directly.\"\n```\n\nA 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.\n\n**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.\n\n**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.\n\n### Proof of Concept\n\nPublish 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\u0027s row. The attacker needs only A\u0027s `avID` and `itemID`, both present in the DOM of A\u0027s own published page.\n\nListing control first, establishing that the platform agrees B must not be listed:\n\n```\nPOST /api/filetree/listDocsByPath\n\u2192 returns only the public document\n```\n\nThen the same backlinks request at four tier settings, spaced to clear the 30-second `GetPublishAccess()` cache:\n\n| Tier of document B | Result |\n|---|---|\n| Hidden (`visible:false`, no password, `disable:false`) | `total:1`, with `avName`, `title`, `databasePath` and `relations[].keyName` for the row in B |\n| Forbidden (`disable:true`) | `total:0` |\n| Private (password set) | `total:0` |\n| Hidden again (restored) | `total:1`, reproducible |\n\nThe 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.\n\n```\nPOST /api/av/getAttributeViewBacklinks\n{\"avID\":\"\u003cpublic database id\u003e\",\"itemID\":\"\u003cpublic row id\u003e\"}\n\n\u2192 200, total:1, disclosing the database name, row title and document path\n of a document the same session cannot list\n```\n\n### Impact\n\nAn 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\u0027s title, its database\u0027s name, and the containing document\u0027s 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.\n\nThe 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.\n\nConfidentiality only, with no integrity or availability impact. No document body content is returned.\n\n### Suggested fix\n\nChange 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.",
"id": "GHSA-p4qw-vx5p-g984",
"modified": "2026-10-23T18:30:42Z",
"published": "2026-10-23T18:30:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-p4qw-vx5p-g984"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73049"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/commit/5b42614311b0afda29ccc65e55d74bf3e8cc9054"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/releases/tag/v3.7.4-alpha.4"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-information-disclosure-via-getattributeviewbacklinks"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "SiYuan: The publish filter for database backlinks consults the forbidden list instead of the visibility list, disclosing hidden-tier documents to anonymous readers"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.