Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
89 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260808051406-3542530c505f
Fixed in
0.0.0-20260808051406-3542530c505f· Vendor fix available
Issue
`kernel/mcp/tools/file.go`'s `resolvePath()` includes an explicit comment stating its sensitive-path blocklist is meant to align with the HTTP file API's established blacklist (`refuseToAccess()` in `kernel/api/file.go`), following the remediation for GHSA-cvhv-7xhj-xjp8 ("Unauthenticated Administrator takeover exfiltrated via the MCP"), which specifically recommended restricting this tool's scope. In practice, the MCP tool implements only 1 of the 4 static blocklist entries the HTTP API enforces. Comparison `kernel/api/file.go` `refuseToAccess()` blocks: 1. `conf/conf.json` (API token, cookie signing key, accessAuthCode) 2. `data/snippets/conf.json` 3. the entire `data/templates` directory 4. `data/.siyuan/publishAccess.json` 5. (dynamic, per-request) any path the current publish-mode session isn't authorized for `kernel/mcp/tools/file.go` `resolvePath()` blocks only: ```go confPath := filepath.Join(util.ConfDir, "conf.json") if abs == confPath { return "",…
Recommended action: Upgrade to 0.0.0-20260808051406-3542530c505f (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260808010544-26ccb40d390e
Fixed in
0.0.0-20260808010544-26ccb40d390e· Vendor fix available
Issue
installBazaarPlugin (and the equivalent endpoints for widgets/icons/templates/themes) accept packageName, repoURL, and repoHash as independent request fields with no validation that they refer to the same package. packageName alone determines the install destination; repoURL/repoHash alone determine what content gets downloaded and written there. A request can name an already-installed, already-enabled plugin as packageName while pointing repoURL/ repoHash at different, attacker-influenced content, silently overwriting the existing plugin's files. Affected code kernel/api/bazaar.go: kernel/model/bazaar.go: kernel/bazaar/install.go: installPath is derived solely from packageName; the downloaded data is derived solely from repoURL/repoHash; nothing cross-validates them, and installPackage performs no check for whether installPath already contains an existing package before copying into it. The same pattern applies to the widget/icon/template/theme install endpoints, which share…
Recommended action: Upgrade to 0.0.0-20260808010544-26ccb40d390e (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260731131820-67bc300b6ea6
Fixed in
0.0.0-20260731131820-67bc300b6ea6· Vendor fix available
Issue
Two checks on the same WebSocket request URI parse it differently. The authentication exemption for keepalive sessions matches raw substrings, while the quarantine introduced to contain those sessions reads a parsed query parameter. Because Go's url.Values.Get returns only the first value for a repeated key, a single URI can satisfy the exemption and still resolve to a non-auth session identity. The result is that an unauthenticated remote caller connects to the kernel WebSocket with a valid access auth code configured, is placed in the general broadcast pool rather than the quarantined pool, and receives the live event stream. Details The exemption matches substrings. kernel/server/serve.go:1222 on the development branch, :1074 on master: Neither operand is parsed. Any URI containing both literals is exempted, regardless of what the query actually resolves to. The quarantine parses. Commit 1e370e373 added the containment for exempted sessions at kernel/util/websocket.go:171:…
Recommended action: Upgrade to 0.0.0-20260731131820-67bc300b6ea6 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260731093152-c7522b8db586
Fixed in
0.0.0-20260731093152-c7522b8db586· Vendor fix available
Issue
/api/filetree/authFilePublishAccess is registered with CheckAuth only and is reachable anonymously. It never sets a failure code, so its outcome is signalled entirely by the response message and by whether a Set-Cookie header is present. Those two signals differ across access tiers, which lets an anonymous caller determine, for any candidate document identifier, whether that document is public or nonexistent, password-protected, or exists at the hidden or forbidden tier. Separately, hidden and forbidden entries carry an empty password. Submitting password:"" therefore satisfies the equality check for them, and the server responds by issuing Set-Cookie: publish-auth-<docID for a document whose own tier is forbidden. Details Route, identical on both refs: No CheckAdminRole, no CheckReadonly. Handler, kernel/api/filetree.go:1608 on the development branch and :1421 on master. ret.Code is never assigned on the failure path, so every response carries code:0. The branch is: The…
Recommended action: Upgrade to 0.0.0-20260731093152-c7522b8db586 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260730150429-5b42614311b0
Fixed in
0.0.0-20260730150429-5b42614311b0· Vendor fix available
Issue
/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: CheckAuth only. No CheckAdminRole, no CheckReadonly. The defect. In FilterAttributeViewBacklinksByPublishAccess…
Recommended action: Upgrade to 0.0.0-20260730150429-5b42614311b0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260729005258-4daee87d4152
Fixed in
0.0.0-20260729005258-4daee87d4152· Vendor fix available
Issue
Relationship to GHSA-hgfg-j9pg-43xw That advisory concerned the administrator's live UI layout, and commit 63c7d5474 resolved it by removing FilterUILayoutByPublishIgnore and nulling Conf.UILayout for readers. That fix is correct and complete for the live layout. This report concerns a different endpoint, a different filter function and a different storage backing. /api/storage/getLocalStorage reads data/storage/local.json rather than Conf.UILayout, and its filter FilterLocalStorageByPublishAccess was not touched by that commit. The consequence is that the same serialized tab objects the earlier fix withheld continue to be served, from the closed-tab history rather than the live layout. Summary Three routes, /api/storage/getLocalStorage, getLocalStorageVal and getLocalStorageVals, are registered with CheckAuth only and are reachable by the publish RoleReader token and anonymously when Publish.Auth.Enable is false. All three call model.GetLocalStorage() and then, for read-only roles,…
Recommended action: Upgrade to 0.0.0-20260729005258-4daee87d4152 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260819144130-256d73aa7f94
Fixed in
0.0.0-20260819144130-256d73aa7f94· Vendor fix available
Issue
IsForbiddenAbsPath() only blocks conf/conf.json by exact match. The TLS private key (conf/key.pem) and CA private key (conf/ca.key) live in the same conf/ directory and are absent from the blocklist. Any authenticated user can retrieve them via POST /api/file/getFile. Root cause kernel/util/pathguard.go, IsForbiddenAbsPath() has no entry for TLS key material. The getFile handler at kernel/api/file.go:497 skips the blocklist for RoleAdministrator, and in v3.8.1 all authenticated users receive RoleAdministrator (no non-admin role is currently issued to direct API consumers). The files are generated on every boot regardless of whether TLS is active. Steps to reproduce: Response: Raw PEM private key bytes. <img width="927" height="467" alt="2026-08-1914-19" src="https://github.com/user-attachments/assets/12e0787f-6bfc-416a-b5ad-a22954e45c48" / Impact: On deployments with TLS enabled (--ssl flag or NetworkServeTLS), possession of key.pem allows decryption of captured HTTPS…
Recommended action: Upgrade to 0.0.0-20260819144130-256d73aa7f94 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260816034002-035bf9a8c311
Fixed in
0.0.0-20260816034002-035bf9a8c311· Vendor fix available
Issue
GHSA-c8r8-95hg-mp34 added a centralized guard, util.IsForbiddenAbsPath(), specifically to block access to a small set of sensitive files: conf/conf.json (plaintext accessAuthCode/API token/cookie key), data/snippets/conf.json, the entire data/templates/ directory, and data/.siyuan/publishAccess.json (plaintext publish-mode passwords). It was applied to kernel/api/file.go and kernel/mcp/tools/file.go. Two other routes in the same server that serve arbitrary files by path, /history/path and /repo/diff/path, construct their target paths independently and were not updated to call this new guard. Since the repo/history snapshot system's tracked root is data/ (confirmed by getSyncIgnoreLines(), whose ignore file lives at data/.siyuan/syncignore with entries relative to data/), both data/.siyuan/publishAccess.json and data/templates/ fall within the scope that can legitimately be captured in historical snapshots, meaning a prior version of either file can exist in…
Recommended action: Upgrade to 0.0.0-20260816034002-035bf9a8c311 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260813142806-dd2778b70d02
Fixed in
0.0.0-20260813142806-dd2778b70d02· Vendor fix available
Issue
Security Advisory — SiYuan Agent Tools SSRF via DNS-Rebinding TOCTOU (Bypass of CheckHostSSRF) | Field | Value | |---|---| | Disclosed by | joysinleung (joysinleung@gmail.com) | | Report date | 2026-08-13 | | Product | SiYuan (思源笔记) — siyuan-note/siyuan | | Go module | github.com/siyuan-note/siyuan/kernel | | Affected versions | <= 3.8.0 (latest release at report time; dynamically verified on v3.8.0) | | Patched versions | 3.8.1 | | Component | kernel/util/httprequest.go (CheckHostSSRF), kernel/mcp/tools/httprequest.go, kernel/util/webfetch.go, kernel/util/net.go (SSRFSafeDialer) | | Relationship to prior advisory | Incomplete-fix variant of GHSA-rg26-cg95-gq6p (SSRF main-vector remediation). See §Relationship. | | EPSS (exploitation probability) | Low–Moderate. Requires the attacker to influence an AI Agent / MCP client into fetching an attacker-controlled domain (prompt-injection scenario documented by the tool itself). | | KEV (CISA Known Exploited) | No (not listed in CISA KEV at…
Recommended action: Upgrade to 0.0.0-20260813142806-dd2778b70d02 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260813142104-b26a4a307b8a
Fixed in
0.0.0-20260813142104-b26a4a307b8a· Vendor fix available
Issue
Security Advisory — SiYuan MCP asset.upload Reads Arbitrary Absolute File Paths (Workspace Boundary Bypass) | Field | Value | |---|---| | Disclosed by | joysinleung (joysinleung@gmail.com) | | Report date | 2026-08-13 | | Product | SiYuan (思源笔记) — siyuan-note/siyuan | | Go module | github.com/siyuan-note/siyuan/kernel | | Affected versions | <= 3.8.0 (latest release at report time; statically confirmed on v3.8.0) | | Patched versions | 3.8.1 | | Component | kernel/mcp/tools/asset.go (assetUpload), kernel/model/upload.go (InsertLocalAssets) | | Relationship to prior advisory | Residual of CVE-2026-66012 (GHSA-cvhv-7xhj-xjp8) MCP remediation. See §Relationship. | | EPSS (exploitation probability) | Low. Requires the AI Agent to invoke asset.upload and the user to approve the (category-level) confirmation; reachable via prompt-injection of the agent. | | KEV (CISA Known Exploited) | No (not listed in CISA KEV at report time). | | Default-config reachable | Partial — requires the…
Recommended action: Upgrade to 0.0.0-20260813142104-b26a4a307b8a (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260804015139-bd067a4fe9b2
Fixed in
0.0.0-20260804015139-bd067a4fe9b2· Vendor fix available
Issue
Same CWE-862 family, found via an automated bulk sweep of every /api/block/ handler in kernel/api/block.go for the presence of any access-check reference (IsReadOnlyRoleContext, checkBlockPublishAccess, GetPublishAccess) anywhere in the function body. 17 of 28 candidate endpoints have none. Cross-checked against the file's own sibling functions (getBlockInfo, getBlockDOM, getRefIDs, etc.), which correctly implement the check, confirming this is a real, uneven gap rather than a deliberate design choice for the whole file. Summary 17 handlers in kernel/api/block.go, all gated only by model.CheckAuth with no admin-role requirement, return block content-derived text, structural metadata, or existence information for any block ID supplied, with no access check anywhere in the handler or, for the ones checked in detail, the model functions they call. This is CWE-862 (Missing Authorization), the same class as the companion advisories from this review round, found in a different file via a…
Recommended action: Upgrade to 0.0.0-20260804015139-bd067a4fe9b2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260803045322-cb67e0b4fab5
Fixed in
0.0.0-20260803045322-cb67e0b4fab5· Vendor fix available
Issue
High Package gomod github.com/siyuan-note/siyuan/kernel Affected versions 3.7.3 Patched versions (none yet — leave blank until a fix is released) Description Summary /ws/network/proxy is an admin-only WebSocket forward-proxy endpoint (target URL and headers fully attacker-specifiable via query parameters). Its websocket.Upgrader explicitly overrides CheckOrigin to unconditionally return true — disabling the origin validation that the gorilla/websocket library otherwise enforces by default. WebSocket handshake requests are not subject to CORS preflight at all (unlike fetch/XHR), so origin validation for WebSocket endpoints has to be done deliberately by the server; here it has been deliberately turned off instead. Combined with the endpoint's own query-parameter-driven proxy target, this is a textbook Cross-Site WebSocket Hijacking (CSWSH) primitive on a capability that amounts to an authenticated network pivot through the SiYuan kernel process. Details Route registration…
Recommended action: Upgrade to 0.0.0-20260803045322-cb67e0b4fab5 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260812083335-251596fc0de2
Fixed in
0.0.0-20260812083335-251596fc0de2· Vendor fix available
Issue
/api/block/getRefIDs filters its results for reader roles through a helper that checks only the visibility tiers. The password tier is not checked, because the helper does not receive the request context and therefore cannot evaluate the publish auth cookie. A reader who has not entered a document's publish password learns that the document references a given block. A function ten lines away in the same file does perform the full check, on the same input type. Details Route, identical at eef105683 (kernel/api/router.go:235) and dev a7ae96ce (:245): No CheckReadonly, no CheckAdminRole. The filter chain. getRefIDs (kernel/api/block.go:631) checks isEncryptedNotebookDeniedForPublish, calls model.GetBlockRefsInBox, then for read-only roles: FilterRefDefsByPublishIgnore (kernel/model/publishaccess.go:1324) collects the reference and definition identifiers, resolves their block trees, and delegates the decision to FilterBlockTreesByPublishIgnore (:1314), whose entire body is:…
Recommended action: Upgrade to 0.0.0-20260812083335-251596fc0de2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel >= 0.0.0-20260726161145-9b8e8956f997, < 0.0.0-20260812083335-251596fc0de2
Fixed in
0.0.0-20260812083335-251596fc0de2· Vendor fix available
Issue
Scope note This endpoint does not exist in v3.7.3 or on master. It was introduced on the development branch by commit `9b8e8956f` on 2026-07-27 and is present on the current development head. No released stable version is affected. Summary `/api/av/getAttributeViewSearchTarget` is registered with `CheckAuth` only and performs no authorization of any kind. Given a database identifier and a keyword, it searches that database's rows and returns matching content, regardless of whether the caller may see the database, the rows, or the notebook holding them. Commit `64c26e74b` on 2026-07-26 closed a reader-reachable gap on `getAttributeViewFieldViews` by adding `CheckReadonly` at router line 536. `9b8e8956f`, the following day, registered this endpoint at line 535 without it. The new route returns more than the one that was just closed: row content rather than field-visibility metadata. Details Route. `kernel/api/router.go:535` on the development branch: ```go…
Recommended action: Upgrade to 0.0.0-20260812083335-251596fc0de2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260812083335-251596fc0de2
Fixed in
0.0.0-20260812083335-251596fc0de2· Vendor fix available
Issue
/api/attr/getBookmarkLabels is registered with CheckAuth only and applies no filtering of any kind. It runs a scan of the entire blocks table and returns the distinct set of every bookmark label in the workspace. An anonymous reader in publish mode receives the author's complete bookmark vocabulary, regardless of whether the bookmarked blocks live in published, hidden, password-protected or forbidden documents. The adjacent endpoint that returns bookmarks with their blocks does filter, and does so in a way that makes the intended rule explicit: it drops a label entirely when no accessible block carries it. Details Route. kernel/api/router.go:297 on master, :300 on the development branch: No CheckAdminRole, no CheckReadonly. Reachable by the publish RoleReader token and anonymously when Publish.Auth.Enable is false. The handler (kernel/api/attr.go) is a single line: which reaches kernel/model/bookmark.go:184 and then sql.QueryBookmarkLabels() at kernel/sql/blockquery.go:315:…
Recommended action: Upgrade to 0.0.0-20260812083335-251596fc0de2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260812083335-251596fc0de2
Fixed in
0.0.0-20260812083335-251596fc0de2· Vendor fix available
Issue
/api/file/getUniqueFilename takes a path from the request body and passes it to a filesystem existence check with no validation, confinement or authorization. The response distinguishes paths that exist from paths that do not, so an anonymous reader in publish mode can probe arbitrary locations on the host, one request per probe. Files and directories both work. Every neighbouring file route either requires an administrator or confines the path first. Details Route. kernel/api/router.go:289 on master, :292 on the development branch, CheckAuth only. Handler, kernel/api/file.go:84, in full: The argument binder does no path handling. util.BindJsonArg (kernel/util/net.go:365) takes two booleans, required (the key must be present) and rejectEmpty (the value must be non-empty). That is its entire contract. There is no filepath.Clean, no workspace join, no traversal check. An absolute path outside the workspace reaches gulu.File.IsExist unmodified. The oracle. util/file.go:67: Input…
Recommended action: Upgrade to 0.0.0-20260812083335-251596fc0de2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260812083335-251596fc0de2
Fixed in
0.0.0-20260812083335-251596fc0de2· Vendor fix available
Issue
/api/storage/getOutlineStorage is registered with CheckAuth only and performs no authorization of any kind. Given a document identifier it returns that document's stored outline state, regardless of the document's publish tier. The two write endpoints for the same data, setOutlineStorage and removeOutlineStorage, both carry CheckAdminRole and CheckReadonly. Only the read path is unguarded. Details Routes. kernel/api/router.go:103 on master, :108 on the development branch: Handler. kernel/api/storage.go:466 on the development branch, :469 on master, identical. It binds docID and calls model.GetOutlineStorage(docID), which iterates the stored outline documents and returns the entry whose DocID matches. There is no filter function on this path at all: no gin.Context, no publish-access check, no password check, no visibility check. The caller supplies the identifier and receives the payload. What is stored. type OutlineDoc { DocID string; Data map[string]any }. The client writes…
Recommended action: Upgrade to 0.0.0-20260812083335-251596fc0de2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260812083335-251596fc0de2
Fixed in
0.0.0-20260812083335-251596fc0de2· Vendor fix available
Issue
/api/system/getConf serves Conf.UILayout to publish readers after passing it through FilterConfByPublishIgnore, whose only function is to filter that layout. The layout is written exclusively by setUILayout, which is administrator-gated, so what readers receive is the administrator's own live workspace state, re-saved on every tab open, close and focus change. The filter that is supposed to protect it, filterLayoutItemByPublishIgnore, has four separate defects. Together they mean a single unauthenticated POST with no arguments returns the titles and identifiers of the administrator's open password-protected documents, the titles of documents in locked or closed notebooks, their recent search terms and the paths those searches were scoped to, and the paths of private assets they have open. This report concerns FilterConfByPublishIgnore and its layout walker. It is distinct from the previously reported getConf issues, which concern configuration fields surviving…
Recommended action: Upgrade to 0.0.0-20260812083335-251596fc0de2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260721043339-eef10568384e
Fixed in
0.0.0-20260721043339-eef10568384e· Vendor fix available
Issue
The /api/filetree/searchDocs endpoint concatenates the caller-supplied search keyword directly into a SQL statement with no escaping and no parameter binding. The endpoint is gated by CheckAuth only reachable by the publish RoleReader token, and by the anonymous account when Publish.Auth.Enable is false. The resulting statement runs on a read-write SQLite handle through a driver that executes stacked (;-separated) statements, against the global blocks table spanning all cleartext notebooks. An unauthenticated request can therefore read and write database content across every non-encrypted notebook on the instance. Details Data flow, unescaped and unbound at every hop: - searchDocs (kernel/api/filetree.go): k := arg["k"].(string) passed straight to model.SearchDocs(k, …), no sanitization. - SearchDocs (kernel/model/file.go): after TrimSpace and strings.Fields, each token is spliced into a single-quoted LIKE literal by concatenation condition.WriteString("(hpath LIKE '%" + k +…
Recommended action: Upgrade to 0.0.0-20260721043339-eef10568384e (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260726020813-a25c2dd06aae
Fixed in
0.0.0-20260726020813-a25c2dd06aae· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72789. Summary publishAccess.json is an opt-out list. The publish gate returns accessible for anything not explicitly listed in it. Encrypted notebooks are never written into that file, because only the administrator-gated setPublishAccess writes it and no part of the encryption subsystem does. Consequently every encrypted notebook is publish-accessible as far as the gate is concerned. While an encrypted notebook is unlocked, an anonymous reader in publish mode can list it, enumerate its documents, and retrieve their fully decrypted content. No key material, no password, and no cracking is involved. The kernel decrypts the data and serves it because the authorization layer never asks whether the notebook is encrypted. This is reported as a defect in the gate rather than in any individual handler. Endpoints that were previously reviewed and found to apply the correct checks do apply them. The checks return true. Details The gate defaults…
Recommended action: Upgrade to 0.0.0-20260726020813-a25c2dd06aae (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260726005141-9edb321eb451
Fixed in
0.0.0-20260726005141-9edb321eb451· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72790. Relationship to GHSA-8x84-r2ff-h8pq (please read first) getNotebookInfo is named in the earlier advisory GHSA-8x84-r2ff-h8pq, in its remediation section, which asked for reader filtering on both getNotebookConf and getNotebookInfo. Commit 3bc014c7d applied that filtering to getNotebookConf only. That advisory grouped getNotebookInfo under BoxCrypt, and getNotebookInfo never returns BoxCrypt. Anyone checking the handler for key material would correctly find none and move on. This report corrects that characterisation and states what the handler actually discloses, which is notebook metadata rather than key material. If you would prefer this tracked as a follow-up on the original advisory rather than separately, that is entirely reasonable. Summary /api/notebook/getNotebookInfo is registered with CheckAuth only and applies no authorization check of any kind. Given a notebook identifier, it returns that notebook's author-written…
Recommended action: Upgrade to 0.0.0-20260726005141-9edb321eb451 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260726004013-64c26e74bb82
Fixed in
0.0.0-20260726004013-64c26e74bb82· Vendor fix available
Issue
Scope note (please read first) This endpoint does not exist in v3.7.3 or on master. It was introduced on the development branch by commit `acfc02ee8` ("Improve database field visibility across views", #11020) and is live on `v3.7.4-alpha.1`, so it will ship in v3.7.4 unless gated first. No released stable version is affected. Summary `/api/av/getAttributeViewFieldViews` is registered with `CheckAuth` only and applies no publish-access filtering. Given a database `avID`, it returns the complete view structure of that database: every view's name, icon, layout type and the per-field `Hidden` flag, regardless of whether the caller is authorized to see that database or those views. The route registered immediately before it, `getAttributeViewKeys`, does gate reader roles. Details | Item | Detail | |---|---| | Route | `kernel/api/router.go:530` `POST /api/av/getAttributeViewFieldViews` → `model.CheckAuth` → `getAttributeViewFieldViews` | | Middleware | `CheckAuth` only, no…
Recommended action: Upgrade to 0.0.0-20260726004013-64c26e74bb82 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260726002639-4515fa257cfa
Fixed in
0.0.0-20260726002639-4515fa257cfa· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72792. Summary /api/tag/getTag filters its results for reader roles through FilterTagsByPublishIgnore, which checks only the visible publish tier. Documents that are published but password-protected pass that check, so a reader who has never entered a document's publish password receives every tag label used inside it, together with occurrence counts. The project has already treated this exact tier mismatch as a vulnerability on a sibling path: commit 82e9ded42 ("Enforce publish access for graph nodes") moved the graph endpoint off the visible-only filter and onto a password-aware one. FilterTagsByPublishIgnore was not upgraded alongside it. Details | Item | Detail | |---|---| | Route | kernel/api/router.go:194 POST /api/tag/getTag → model.CheckAuth → getTag | | Middleware | CheckAuth only: no CheckReadonly, no CheckAdminRole | | Guard | Present but at the wrong tier: visible-only, no password check | | Exposed | Every tag label…
Recommended action: Upgrade to 0.0.0-20260726002639-4515fa257cfa (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260725132049-2d8b98395a91
Fixed in
0.0.0-20260725132049-2d8b98395a91· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72793. Summary /api/system/getConf is registered with CheckAuth only and is reachable by the publish RoleReader token, and anonymously when Publish.Auth.Enable is false. Its non-administrator masking chain is a blocklist that enumerates fields individually. Three fields that the configuration-export endpoint in the same file deliberately clears are absent from that blocklist and are returned to readers: | Field | JSON | What it is | Cleared by exportConf at | |---|---|---|---| | Conf.CookieKey | cookieKey | The session-cookie signing key | kernel/api/system.go:360 | | Conf.Export.PandocBin | export.pandocBin | Absolute path embedding the OS username | kernel/api/system.go:338 | | Conf.NotebookCrypto | notebookCrypto | Encrypted-notebook key material | kernel/api/system.go:360 | The project has already classified all three as values that must not leave the server. The reader-facing path returns them. Details Route.…
Recommended action: Upgrade to 0.0.0-20260725132049-2d8b98395a91 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siyuan-note/siyuan/kernel < 0.0.0-20260725125659-1ca1c3c9d94b
Fixed in
0.0.0-20260725125659-1ca1c3c9d94b· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72795. Summary /api/block/getBlockDOMWithEmbed and /api/block/getBlockDOMsWithEmbed gate only the requested block against publish access. The blocks pulled in by that block's embed (transclusion) query are inlined into the returned DOM with no publish-access check at all, so a reader who requests a legitimately-published block containing an embed query receives the content of every block that query matched including blocks in hidden, forbidden and password-protected documents. The dedicated embed endpoint getEmbedBlock filters these same results for reader roles. The DOM-with-embed path does not. Details | Item | Detail | |---|---| | Routes | kernel/api/router.go:226 POST /api/block/getBlockDOMWithEmbed → model.CheckAuth → getBlockDOMWithEmbed; :227 POST /api/block/getBlockDOMsWithEmbed → model.CheckAuth → getBlockDOMsWithEmbed | | Middleware | CheckAuth only — no CheckReadonly, no CheckAdminRole → reachable by the publish RoleReader…
Recommended action: Upgrade to 0.0.0-20260725125659-1ca1c3c9d94b (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.