GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-6MCF-G667-W3QV

Vulnerability from github – Published: 2026-09-03 22:50 – Updated: 2026-09-03 22:50
VLAI
Summary
SiYuan: Password (protected) tier omitted in the attribute-view/database publish filter: Reader receives rows of protected documents without the password (publish mode)
Details

CVE: This vulnerability corresponds to CVE-2026-72806.

Summary

FilterViewByPublishAccess, the filter renderAttributeView applies for Reader sessions drops rows using only the hidden/forbidden check and never checks the publish password. Its three sibling filters all check both tiers. As a result, a publish RoleReader (or the anonymous account when Publish.Auth.Enable is false) who has not entered a document's password still receives every database/attribute-view row bound to that password-protected document, the primary cell (title/ID) and all column values.

Details

FilterViewByPublishAccess (model/publish_access.go:290) drops rows on the hidden/forbidden tier only:

// Table (line 311), Gallery (348), Kanban (385), all identical:
if !CheckPathAccessableByPublishIgnore(bt.BoxID, bt.Path, publishIgnore) {
    row = nil   // hidden/forbidden dropped, but password NEVER checked
}

The three sibling filters all check both the hidden/forbidden tier and the password tier (password == "" || CheckPublishAuthCookie(...)): - FilterBlockAttributeViewKeysByPublishAccess (line 412) - FilterBlockInfoByPublishAccess (line 457) - FilterContentByPublishAccess (line 474)

So the password (protected) tier is enforced everywhere except this AV/database-view filter. Table layout masks nothing; Gallery and Kanban mask only the cover, keeping the card and its non-cover values. Reachable via renderAttributeView, getAttributeViewKeys, and renderSnapshotAttributeView, all CheckAuth-only.

Proof of Concept

Reproduced on a live instance (publish mode on 6808, anonymous Reader, no password cookie), against a password-protected document with a database/AV row.

Check Path Result
Control getDoc(secretDoc) πŸ”’ placeholder, body withheld password gate works normally
Test renderAttributeView(AV) row leaked : blockID=…rk7jofz, title secret-db-row
Differential (disable=true) same filter 0 rows : hidden tier correctly enforced
Differential (password set) same filter 1 row : password tier bypassed

Same filter, same document, same Reader: the hidden tier drops the row, the password tier leaks it isolating the omission.

Impact

An anonymous/Reader publish user who has not supplied a protected document's password receives all attribute-view/database rows bound to that document titles, block IDs, and column values defeating the publish-password control for database views. Confidentiality-only. The hidden/forbidden tier is unaffected (correctly enforced).

Suggested fix

Add the password check to the drop condition in all three layout branches (Table, Gallery, Kanban), mirroring the sibling filters:

if !CheckPathAccessableByPublishIgnore(...) ||
   !(password == "" || CheckPublishAuthCookie(c, passwordID, password)) {
    row = nil
}
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/siyuan-note/siyuan/kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260723040913-768427f20f13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-72806"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-03T22:50:49Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "**CVE:** This vulnerability corresponds to [CVE-2026-72806](https://nvd.nist.gov/vuln/detail/CVE-2026-72806).\n\n### Summary\n\n`FilterViewByPublishAccess`, the filter `renderAttributeView` applies for Reader sessions drops rows using only the hidden/forbidden check and never checks the publish password. Its three sibling filters all check both tiers. As a result, a publish `RoleReader` (or the anonymous account when `Publish.Auth.Enable` is `false`) who has not entered a document\u0027s password still receives every database/attribute-view row bound to that password-protected document, the primary cell (title/ID) and all column values.\n\n### Details\n\n`FilterViewByPublishAccess` (`model/publish_access.go:290`) drops rows on the hidden/forbidden tier only:\n```go\n// Table (line 311), Gallery (348), Kanban (385), all identical:\nif !CheckPathAccessableByPublishIgnore(bt.BoxID, bt.Path, publishIgnore) {\n    row = nil   // hidden/forbidden dropped, but password NEVER checked\n}\n```\n\nThe three sibling filters all check both the hidden/forbidden tier and the password tier (`password == \"\" || CheckPublishAuthCookie(...)`):\n- `FilterBlockAttributeViewKeysByPublishAccess` (line 412)\n- `FilterBlockInfoByPublishAccess` (line 457)\n- `FilterContentByPublishAccess` (line 474)\n\nSo the password (protected) tier is enforced everywhere except this AV/database-view filter. Table layout masks nothing; Gallery and Kanban mask only the cover, keeping the card and its non-cover values. Reachable via `renderAttributeView`, `getAttributeViewKeys`, and `renderSnapshotAttributeView`, all `CheckAuth`-only.\n\n### Proof of Concept\n\nReproduced on a live instance (publish mode on 6808, anonymous Reader, no password cookie), against a password-protected document with a database/AV row.\n\n| Check | Path | Result |\n|---|---|---|\n| Control | `getDoc(secretDoc)` | \ud83d\udd12 placeholder, body withheld password gate works normally |\n| Test | `renderAttributeView(AV)` | row leaked : `blockID=\u2026rk7jofz`, title `secret-db-row` |\n| Differential (`disable=true`) | same filter | 0 rows : hidden tier correctly enforced |\n| Differential (password set) | same filter | 1 row : password tier bypassed |\n\nSame filter, same document, same Reader: the hidden tier drops the row, the password tier leaks it isolating the omission.\n\n### Impact\n\nAn anonymous/Reader publish user who has not supplied a protected document\u0027s password receives all attribute-view/database rows bound to that document titles, block IDs, and column values defeating the publish-password control for database views. Confidentiality-only. The hidden/forbidden tier is unaffected (correctly enforced).\n\n### Suggested fix\n\nAdd the password check to the drop condition in all three layout branches (Table, Gallery, Kanban), mirroring the sibling filters:\n```go\nif !CheckPathAccessableByPublishIgnore(...) ||\n   !(password == \"\" || CheckPublishAuthCookie(c, passwordID, password)) {\n    row = nil\n}\n```",
  "id": "GHSA-6mcf-g667-w3qv",
  "modified": "2026-09-03T22:50:49Z",
  "published": "2026-09-03T22:50:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-6mcf-g667-w3qv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72806"
    },
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/commit/768427f20f13bbd8dc4effa8aa4e1d09a7741bf4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/siyuan-note/siyuan"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/siyuan-before-authentication-bypass-via-attribute-view"
    }
  ],
  "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: Password (protected) tier omitted in the attribute-view/database publish filter: Reader receives rows of protected documents without the password (publish mode)"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…