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-20260725123945-77421530be4a
Fixed in
0.0.0-20260725123945-77421530be4a· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72794. Summary /api/system/getConf returns Conf.CookieKey, the key used to sign the server's session cookies in its response body. The endpoint is registered with CheckAuth only, so the field reaches the publish RoleReader token and the anonymous account when Publish.Auth.Enable is false. The configuration-export endpoint in the same file strips this exact field before returning config, so the project already treats it as secret. The reader-facing masking path does not. Details | Item | Detail | |---|---| | Route | kernel/api/router.go:70 POST /api/system/getConf → model.CheckAuth → getConf | | Middleware | CheckAuth only — no CheckReadonly, no CheckAdminRole | | Leaked field | AppConf.CookieKey, serialized as cookieKey | | Purpose of the field | Signing key for the siyuan session cookie | The field survives every stage of the masking chain. getConf masks through GetMaskedConf() → HideConfSecret() (non-administrators) →…
Recommended action: Upgrade to 0.0.0-20260725123945-77421530be4a (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-20260725122641-34be6c0bb073
Fixed in
0.0.0-20260725122641-34be6c0bb073· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72796. Summary Several static-file routes in the server mux (kernel/server/serve.go) are registered with CheckAuth only and serve directories directly, without the publish-access checks, sensitive-path blocklist, or refuseToAccess rules that the REST API applies to the same data. They are therefore reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. Most notably, /templates/ serves data/templates a directory the REST file API explicitly refuses to serve to non-administrators. Details | Route | Registration | Guard | Exposed to a reader | |---|---|---|---| | /templates/ (line 424) | Group("/templates/", model.CheckAuth).Static("", data/templates) | none beyond path cleaning | the templates directory | | /snippets/ (line 434) | CheckAuth | blocks only conf.json | any snippet's JS/CSS content by name | | /widgets/, /plugins/, /emojis/ (409/414/419) | Group(CheckAuth).Static(dir) | none…
Recommended action: Upgrade to 0.0.0-20260725122641-34be6c0bb073 (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-20260724123622-8fb1b5766093
Fixed in
0.0.0-20260724123622-8fb1b5766093· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72797. Summary POST /api/notebook/getEncryptedNotebookStatus returns the identifier, name, and current lock state of every encrypted notebook, with no publish-access filtering. The route is registered CheckAuth only, no CheckReadonly, no CheckAdminRole so it is reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. Encrypted notebooks are private by design; their names frequently reveal the sensitive topic that motivated encrypting them. Details Route registration (kernel/api/router.go:131): The handler (kernel/api/notebook.go) accepts no arguments and contains no IsReadOnlyRoleContext branch and no publish-access filter of any kind. It returns, for every encrypted notebook, {id, name, unlocked}, the notebook's box.Name and its live lock state together with enabled, count, migrationPending, migrationBoxes, and hasHistoryDependency. Guarded-sibling asymmetry. The primary notebook listing…
Recommended action: Upgrade to 0.0.0-20260724123622-8fb1b5766093 (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-20260724121519-426991d155c0
Fixed in
0.0.0-20260724121519-426991d155c0· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72798. Summary renderAttributeView correctly applies the reader publish-access filter, but the filter's row-accessibility decision is keyed solely to the row's first cell, and it never inspects the remaining cells' values. Relation and Rollup cells carry mirrored content from a different database, so a row belonging to a published database can hand an anonymous reader the contents of a related database whose host document is hidden, publish-forbidden, or password-protected. Separately, when the first column is not a block value the accessibility check is skipped entirely and the row is returned unchecked. Note: This is distinct from the previously reported password-tier omission in the same function that concerns the row's own primary block, whereas these two defects concern (a) other cells' related-database content, which no row-level check covers and (b) rows where the first cell is not a block at all. A fix to the row-drop condition…
Recommended action: Upgrade to 0.0.0-20260724121519-426991d155c0 (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-20260724112156-5bae0926b896
Fixed in
0.0.0-20260724112156-5bae0926b896· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72799. Summary Five filetree endpoints resolve arbitrary document IDs and paths with no publish-access check of any kind. All are CheckAuth-only, so they are reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. An anonymous reader can map the complete private document tree every notebook, folder, and document title, and which notebook holds each document for documents marked hidden, password-protected, or publish-forbidden, and can resolve titles to document IDs. Details None of the following handlers invokes IsReadOnlyRoleContext, CheckBlockIdAccessableByPublishAccess, or CheckPathAccessableByPublishIgnore: | Endpoint | Returns | Discloses | |---|---|---| | getFullHPathByID (router 159) | GetFullHPathByID(id) | full title path including notebook, e.g. /MySecretNotebook/Confidential/Q3 Layoffs Plan | | getHPathByID (router 157) | GetHPathByID(id) | document-relative title path | |…
Recommended action: Upgrade to 0.0.0-20260724112156-5bae0926b896 (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-20260724103335-f36331956ae9
Fixed in
0.0.0-20260724103335-f36331956ae9· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72800. Summary POST /api/av/getAttributeViewKeysByID returns a database's full column schema with no publish-access filtering, while its sibling getAttributeViewKeys applies the filter for reader sessions. Two further endpoints, getBlockDefIDsByRefText and getBlockRelevantIDs return workspace-wide block IDs with no publish scoping. All three are CheckAuth-only, so they are reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. Details (a) getAttributeViewKeysByID: ungated column-schema disclosure The entire handler (kernel/api/av.go, router line 548): With an empty keyIDs, GetAttributeViewKeysByID calls av.ParseAttributeView(avID) and returns every column's av.Key: | Field | Discloses | |---|---| | Name, Desc | column title and user-authored description | | Options | the full single/multi-select vocabulary and colours (e.g. status labels such as "Fired", "Confidential") | | Template |…
Recommended action: Upgrade to 0.0.0-20260724103335-f36331956ae9 (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-20260724102025-3bc014c7dc32
Fixed in
0.0.0-20260724102025-3bc014c7dc32· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72801. Summary Two CheckAuth-only endpoints disclose the complete offline attack material for the encrypted-notebook master password, plus the wrapped per-notebook key needed to use it. Both are reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. An unauthenticated remote client can retrieve the Argon2id salt and cost parameters, a verifier that confirms a correct password offline, and the encrypted per-notebook data key reducing the security of every encrypted notebook to the master password's resistance to offline GPU cracking. Details (1) POST /api/system/getConf leaks NotebookCrypto. getConf → GetMaskedConf() marshals the full configuration including NotebookCrypto conf.NotebookCrypto (JSON tag notebookCrypto, not -, so it survives the deep copy). For non-administrators HideConfSecret() is applied, which nulls a dozen secret-bearing fields like AI, MCPOAuth, Api, Flashcard,…
Recommended action: Upgrade to 0.0.0-20260724102025-3bc014c7dc32 (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-20260724095509-eee3410aa131
Fixed in
0.0.0-20260724095509-eee3410aa131· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72802. Summary POST /api/asset/resolveAssetPath returns the resolved absolute filesystem path of an asset, unmodified. The route is CheckAuth-only, so it is reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. An anonymous reader who knows any asset's relative path trivially harvested from an <img src="assets/…" in any published document receives the server's absolute workspace path, disclosing the operating-system username and the installation layout. Details GetAssetAbsPathInBox(path, "") resolves under util.DataDir / util.WorkspaceDir, producing a full host path such as C:\Users\<username\SiYuan\data\assets\foo.png or /home/<user/…. The handler returns it directly with no redaction and no publish-scope check. This is data the project already treats as sensitive. getConf explicitly zeroes System.WorkspaceDir, AppDir, ConfDir, DataDir, and HomeDir when util.IsBrowserRequest(c), a…
Recommended action: Upgrade to 0.0.0-20260724095509-eee3410aa131 (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-20260724093256-229fdffd7e4a
Fixed in
0.0.0-20260724093256-229fdffd7e4a· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72803. Summary POST /api/attr/getBlockAttrs and POST /api/attr/batchGetBlockAttrs return a block's full attribute set (IAL) with no publish-access check. Both are CheckAuth-only, so they are reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. An anonymous reader supplying a block ID receives the block's name, alias, memo, bookmark, tags, and every custom- attribute including for blocks in publish-forbidden and password-protected documents. The batch variant accepts an ID list, making it a bulk extraction primitive. Details Neither handler applies a filter: sql.GetBlockAttrs is a direct database read returning the block's entire IAL: name, alias, memo, bookmark, tags, and any custom- key/value the user has set. Several of these are user-authored free text memos in particular are freeform notes attached to a block so this is document content, not merely structural metadata.…
Recommended action: Upgrade to 0.0.0-20260724093256-229fdffd7e4a (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-20260724091654-82e9ded423e4
Fixed in
0.0.0-20260724091654-82e9ded423e4· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72804. Summary getGraph and getLocalGraph filter reader sessions against the visibility tier only and never check the publish password. Password-protected documents are Visible = true, so their graph nodes survive the filter and graph nodes are block-level and carry the block's actual content. An anonymous reader who has never supplied a document's password can therefore retrieve that document's per-block content and its reference/backlink topology. Both endpoints are CheckAuth-only, so they are reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. Details Both handlers filter with the invisible-tier set only: FilterGraphByPublishIgnore (kernel/model/publishaccess.go:849) drops a node only when !CheckPathAccessableByPublishIgnore(node.Box, node.Path, publishIgnore). There is no password evaluation anywhere in the graph code grepping graph.go for CheckPublishAuthCookie or password…
Recommended action: Upgrade to 0.0.0-20260724091654-82e9ded423e4 (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-20260723163028-931ba693375e
Fixed in
0.0.0-20260723163028-931ba693375e· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72805. Summary Three block endpoints return document content snippets and metadata without any publish-access check, while their sibling getBlockInfo which returns comparable data does enforce one. All three are CheckAuth-only, so they are reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. An anonymous reader supplying a block ID receives content and metadata belonging to publish-forbidden and password-protected documents. Details getBlockInfo (kernel/api/block.go) gates on the publish boundary: The following siblings in the same file perform no equivalent check: | Endpoint | Returns | Publish check | |---|---|---| | getBlockInfo | root/title/path metadata | checkBlockPublishAccess: present | | getBlockBreadcrumb | BlockPath.Name : root document title plus every ancestor block's content snippet | none | | getRefText | the block's reference/anchor text (document content) | none | |…
Recommended action: Upgrade to 0.0.0-20260723163028-931ba693375e (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-20260723040913-768427f20f13
Fixed in
0.0.0-20260723040913-768427f20f13· Vendor fix available
Issue
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/publishaccess.go:290) drops rows on the hidden/forbidden tier only: 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…
Recommended action: Upgrade to 0.0.0-20260723040913-768427f20f13 (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-20260723035036-0a176345e02a
Fixed in
0.0.0-20260723035036-0a176345e02a· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72807. Summary Attribute-view (AV) template columns are live-evaluated on every render and expose the queryBlocks template function, which runs raw SQL on the read-write database handle (SelectBlocksRawStmt, using ?→argument string substitution rather than parameter binding). AV mutations are admin-gated, so this is not directly reader-injectable but it is a second-order vector: an attacker distributes a SiYuan document or AV package whose template column contains .action{queryBlocks "<arbitrary SQL"} when a victim imports the package and renders the AV, the attacker's SQL executes on the victim's kernel (read and, via statement stacking, write). Details Doc-level {{…}} templates are rendered at insert-time and become static, so they are not re-evaluated on reader view. The residual is AV template columns, which are live-evaluated at render. queryBlocks passes its argument to SelectBlocksRawStmt with ?→arg string substitution, not a…
Recommended action: Upgrade to 0.0.0-20260723035036-0a176345e02a (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-20260723031702-509b35055940
Fixed in
0.0.0-20260723031702-509b35055940· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72808. Summary The /api/asset/getFileAnnotation endpoint returns the content of .sya PDF-annotation files with no publish-access check. It is gated by CheckAuth only, so it is reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. Its sibling, the /assets/ asset route does enforce publish access, including the publish password. An anonymous reader who knows an asset path can therefore read the private PDF annotations (highlights, notes) attached to assets in publish-forbidden, password-protected, or unpublished documents. Details getFileAnnotation resolves the annotation file via GetAssetAbsPathInBox (no path traversal) and returns the .sya content. Unlike the /assets/ route, which applies the publish-access filter including password enforcement before serving asset bytes, getFileAnnotation applies no publish-access, publish-ignore, or password check. The guarded-sibling asymmetry…
Recommended action: Upgrade to 0.0.0-20260723031702-509b35055940 (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-20260723031701-9c16e9851f0b
Fixed in
0.0.0-20260723031701-9c16e9851f0b· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72809. Summary The kernel's CheckAuth grants RoleAdministrator to any request whose RemoteAddr is loopback (127.0.0.1), for a specific set of endpoints, and these localhost bypasses sit outside the accessAuthCode gate so they apply even when an access auth code is configured. This is demonstrated live (Part A below). Separately, the fixed-port reverse proxy (fixedport.go) forwards requests to the kernel over loopback and injects no authentication token, and no SetTrustedProxies is configured, so gin does not derive the client address from forwarding headers. By code inspection, a request forwarded through this proxy would reach the kernel with RemoteAddr = 127.0.0.1. If the fixed-port proxy is bound to a network interface (via NetworkServe) and forwards remote requests to the kernel this way, the localhost bypass would grant a remote unauthenticated caller admin on those endpoints. This second step is established by reading the code but…
Recommended action: Upgrade to 0.0.0-20260723031701-9c16e9851f0b (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-20260723013612-ba948639d7f6
Fixed in
0.0.0-20260723013612-ba948639d7f6· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72810. Summary WebSocket sessions established through the publish surface (port 6808, RoleReader anonymous when Publish.Auth.Enable is false) are added to the same broadcast session pool as authenticated sessions. The kernel's broadcast functions push content events transactions carrying block DOM, document save/create, move/rename to every session in the pool with no role or publish-access filtering. As a result, an anonymous reader who holds a WebSocket connection open passively receives a real-time feed of every edit made in the workspace, including edits to password-protected, publish-forbidden, and unpublished documents. Because these events are delivered over the push channel and never pass through an HTTP handler, none of the publish-access filters that gate the HTTP endpoints apply. Details Session admission. HandleConnect admits the injected RoleReader publish token, and the session is registered via AddPushChan into the same…
Recommended action: Upgrade to 0.0.0-20260723013612-ba948639d7f6 (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-20260723004839-1a5b3431d5ab
Fixed in
0.0.0-20260723004839-1a5b3431d5ab· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72811. Summary The backlink/mention search query (kernel/model/backlink.go) concatenates stored block metadata (title, name, alias, anchor text) and the client-supplied keyword into a SQL MATCH/search statement, escaping only the double-quote character (") and not the single quote ('). A single quote in either the client keyword or in stored document metadata breaks out of the string literal. The query runs on the main read-write siyuan.db handle through a statement-stacking-capable driver. This yields two vectors: - First-order: a client-supplied keyword containing ' injects directly. This path is reachable by an anonymous reader on the publish surface. - Second-order: a document whose title/name/alias contains ' is stored safely (indexing uses parameterized inserts) but detonates when that stored value is later concatenated into the backlink query including on another user's kernel that has ingested the malicious document. Details…
Recommended action: Upgrade to 0.0.0-20260723004839-1a5b3431d5ab (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-20260723002528-7d273c271ce1
Fixed in
0.0.0-20260723002528-7d273c271ce1· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-72812. Summary The /api/ref/refreshBacklink endpoint is gated by CheckAuth only. Unlike its mutating siblings, it carries no CheckAdminRole, no CheckReadonly, and no inline reader-role guard so it falls through all three authorization mechanisms the codebase uses to protect write operations. A publish RoleReader or the anonymous account when Publish.Auth.Enable is false can invoke it, forcing the server to flush its pending write-transaction queue, scan all references globally, load and parse referencing trees from disk, and enqueue database writes. This violates the read-only invariant (it writes even in a globally read-only workspace), provides an unauthenticated resource-amplification/DoS primitive, and applies no per-object access check to the caller-supplied ID. Details Route / auth tier. router.go: Handle("POST", "/api/ref/refreshBacklink", model.CheckAuth, refreshBacklink), CheckAuth only. CheckAuth admits RoleReader; the publish…
Recommended action: Upgrade to 0.0.0-20260723002528-7d273c271ce1 (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-20260721020826-2d069dce84a2
Fixed in
0.0.0-20260721020826-2d069dce84a2· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-68584. Summary SiYuan's publish mode defines a "protected" access level: a document that is publicly listed but requires a password to read (per the product's own UI help text, protected = "Publicly visible, requires password to access"). The password is enforced on the primary content path (getDoc, via FilterContentByPublishAccess). Several other content-returning endpoints getHeadingChildrenDOM, getHeadingDeleteTransaction/getHeadingLevelTransaction/ getHeadingInsertTransaction, and getBacklinkDoc/getBackmentionDoc return rendered block DOM with no password check at all. Combined with reader-reachable endpoints that leak a protected document's internal block IDs, an anonymous reader can retrieve the full body of a password-protected document without the password. This has been reproduced end-to-end on a live instance. Details The password control and where it is enforced. Publish access has five levels encoded in…
Recommended action: Upgrade to 0.0.0-20260721020826-2d069dce84a2 (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-20260721014951-ffde3b21eca4
Fixed in
0.0.0-20260721014951-ffde3b21eca4· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-68585. Summary The /api/block/getBlockInfo endpoint returns document root metadata including the document title (rootTitle) for a block in a publish-forbidden document, with no publish-access check. Its sibling /api/block/getDocInfo applies the publish-access filter, getBlockInfo does not. Both are gated by CheckAuth only, so getBlockInfo is reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. Details The list/info side of this API is filtered while the block-info twin is not the asymmetry indicates an oversight rather than intended behavior: | Endpoint | Returns | Publish-access filter | Route | |---|---|---|---| | getDocInfo | document info/metadata | present | CheckAuth | | getBlockInfo | box, path, rootID, rootTitle, rootChildID, rootIcon | none | CheckAuth | getBlockInfo takes a caller-supplied block ID, validates only its format, and returns the containing document's root…
Recommended action: Upgrade to 0.0.0-20260721014951-ffde3b21eca4 (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-20260721014413-f45749a7ef6e
Fixed in
0.0.0-20260721014413-f45749a7ef6e· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-68586. Summary The backlink API splits into list endpoints (which documents reference a block) and content endpoints (the rendered text of those referencing blocks). The list endpoints apply a publish-access filter, the content endpoints do not. As a result, /api/ref/getBacklinkDoc and /api/ref/getBackmentionDoc return the rendered DOM of blocks belonging to a publish-forbidden document to an anonymous reader, with no access check. Both content endpoints are gated by CheckAuth only, reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. Details The asymmetry between the list and content sides is the tell that this is an oversight, not intended behavior: | Endpoint | Returns | Publish-access filter | Route | |---|---|---|---| | getBacklink | list (Path) | FilterPathsByPublishAccess - present | CheckAuth | | getBacklink2 | list (Path) | FilterPathsByPublishAccess - present | CheckAuth | |…
Recommended action: Upgrade to 0.0.0-20260721014413-f45749a7ef6e (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-20260721013353-69db783b782a
Fixed in
0.0.0-20260721013353-69db783b782a· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-68587. Summary Three "heading transaction" endpoints /api/block/getHeadingDeleteTransaction, /api/block/getHeadingLevelTransaction, and /api/block/getHeadingInsertTransaction return the rendered block DOM of a heading and its subtree in the computed transaction payload, with no publish-access check. They are gated by CheckAuth only, so they are reachable by the publish RoleReader token, and by the anonymous account when Publish.Auth.Enable is false. Despite their write-implying names, these endpoints perform no mutation on this path, they compute a transaction object and return it, and that object contains RenderNodeBlockDOM output. As a result, an anonymous reader who supplies a heading block ID can read the full rendered content of a document that has been explicitly marked publish-disabled by an administrator, content that the reader-facing /api/filetree/getDoc path correctly refuses to return. Details Route / auth tier. All three…
Recommended action: Upgrade to 0.0.0-20260721013353-69db783b782a (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-20260721004815-cf42dd5680c8
Fixed in
0.0.0-20260721004815-cf42dd5680c8· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-69083. Summary The /api/search/fullTextSearchAssetContent endpoint exposes two SQL flaws on the asset-content database, both reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false: 1. method 2 passes a client-supplied SQL statement to the read-write asset-content DB with no single-statement or read-only guard, and without the admin restriction its sibling fullTextSearchBlock applies to the same SQL method. 2. method 3 builds a REGEXP clause by concatenating the client expression with no quote-escaping, permitting SQL breakout while the equivalent block-search builder does escape. Both run on a read-write handle through a statement-stacking-capable driver, spanning the cross-notebook asset-content store. Details Route / auth tier. router.go: Handle("POST", "/api/search/fullTextSearchAssetContent", model.CheckAuth, fullTextSearchAssetContent), CheckAuth only. Anonymous/reader reachable on…
Recommended action: Upgrade to 0.0.0-20260721004815-cf42dd5680c8 (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-20260720151813-0f5a0e7c67b0
Fixed in
0.0.0-20260720151813-0f5a0e7c67b0· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-69086. Summary Four attribute-view read endpoints build a filesystem path from a caller-controlled id/avID and read it without confining the result to the attribute-view storage directory (DataDir/storage/av/). On the load (file-exists) code path there is no boundary check, so an avID containing ../ segments escapes storage/av/ and causes the kernel to read a .json file elsewhere in the workspace. The endpoints require only CheckAuth, which the publish service's RoleReader token satisfies; when Publish.Auth.Enable is false the publish proxy uses the anonymous account, making the surface reachable with no credentials. Details Affected endpoints (all gated by CheckAuth only, no CheckAdminRole): - POST /api/av/renderAttributeView → arg["id"] - POST /api/av/getAttributeViewKeysByID → arg["avID"] - POST /api/av/getAttributeViewKeys → arg["id"] - POST /api/av/getCurrentAttrViewImages → arg["id"] In model.RenderAttributeView…
Recommended action: Upgrade to 0.0.0-20260720151813-0f5a0e7c67b0 (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-20260721002947-23a17d44b5f3
Fixed in
0.0.0-20260721002947-23a17d44b5f3· Vendor fix available
Issue
CVE: This vulnerability corresponds to CVE-2026-69084. Summary The /api/search/searchEmbedBlock endpoint passes a client-supplied SQL statement verbatim to the database with no validation. 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 statement runs on the main read-write siyuan.db handle through a driver that executes stacked statements, with no single-statement or read-only guard. An unauthenticated request can therefore execute arbitrary SQL reading and writing content across all cleartext notebooks. Unlike SQL injection into a fixed query, this endpoint accepts a full SQL statement by design and simply fails to restrict who may call it or what the statement may do. Details Data flow verbatim, unvalidated: - searchEmbedBlock (kernel/api/search.go): stmt := arg["stmt"].(string) passed directly to model.SearchEmbedBlock(stmt, …). No validation. - SearchEmbedBlock →…
Recommended action: Upgrade to 0.0.0-20260721002947-23a17d44b5f3 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.