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-20260510110132-b763d787d1f2
Fixed in
0.0.0-20260510110132-b763d787d1f2· Vendor fix available
Issue
SiYuan's /export/ file handler was hardened against export disclosure (issue #12213) by adding an IsSubPath(exportBaseDir, fullPath) check and an IsSensitivePath() check in commit bb481e1. These guards were added only to the main branch of the handler. The handler begins with a short-circuit branch: This branch joins the broader util.TempDir with the raw, percent-decoded request path and serves it with neither IsSubPath nor IsSensitivePath. An authenticated request to /export/temp/%2e%2e/.../etc/passwd traverses out of TempDir and reads arbitrary files - exactly the sensitive-file disclosure the patch intended to prevent. Present in the latest master. Affected - From commit bb481e1 (the hardening) through the latest master. - Requires SiYuan access authorization (model.CheckAuth) - but the patch's stated goal is to deny sensitive-file export even to authorized callers. Root cause kernel/server/serve.go serveExport(): the main branch has IsSubPath + IsSensitivePath; the…
Recommended action: Upgrade to 0.0.0-20260510110132-b763d787d1f2 (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-20260714095344-f08dee71ba8e
Fixed in
0.0.0-20260714095344-f08dee71ba8e· Vendor fix available
Issue
SiYuan cleans user supplied SVG with util.SanitizeSVG before it serves the file inline as image/svg+xml. This cleaner is the guard behind the Editor.AllowSVGScript setting, which is off by default, so a <script inside an SVG is meant to be removed. The cleaner reads the input as HTML, but the browser reads the served file as XML (SVG). Because the two parsers treat some tags differently, a <script can be hidden so the cleaner never removes it. The cleaned file still holds a working script. When a browser opens that file as an SVG document, the script runs in the app origin. There is no Content Security Policy in the product to stop it. The same bug can be reached in two ways. Both share one root cause (the cleaner), so one fix in the cleaner closes both: Reflected, through a single link: GET /api/icon/getDynamicIcon Stored, through a planted .svg asset: GET /assets/<name.svg I confirmed this on a live SiYuan 3.7.2 kernel. Root cause util.SanitizeSVG (kernel/util/misc.go:319)…
Recommended action: Upgrade to 0.0.0-20260714095344-f08dee71ba8e (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-20260704035520-68cc0f537dfa
Fixed in
0.0.0-20260704035520-68cc0f537dfa· Vendor fix available
Issue
Reporter: Cavan Loughran, Celvex Group Inc. Summary ------- The /snippets/filepath route handler serveSnippets in kernel/server/serve.go performs a bare filepath.Join(util.SnippetsPath, filePath) on the single-decoded c.Request.URL.Path and serves the result with c.File(), with NO IsSubPath containment and NO IsSensitivePath denylist - unlike the sibling /export/ (serveExport) and /appearance/ (serveAppearance) handlers, which both carry IsSubPath, and unlike /assets/ (serveAssets), whose traversal was fixed in GHSA-p4m3-mgmm-c664. Because util.SnippetsPath = WorkspaceDir/data/snippets, an authenticated request to GET /snippets/%2e%2e/%2e%2e/conf/conf.json resolves to WorkspaceDir/conf/conf.json and leaks the kernel API token and AccessAuthCode (the same secret file CVE-2026-30869 leaked from /export/); GET /snippets/%2e%2e/%2e%2e/temp/siyuan.db leaks the full document database. Affected versions ----------------- v3.6.5 and current master (verified by direct source read). The…
Recommended action: Upgrade to 0.0.0-20260704035520-68cc0f537dfa (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-20260704035518-d0f0fe146fb0
Fixed in
0.0.0-20260704035518-d0f0fe146fb0· Vendor fix available
Issue
Siyuan's block search endpoint concatenates attacker-controlled paths[] values into SQL predicates used by non-SQL search modes. Through Siyuan's publish service, an unauthenticated visitor is forwarded to the kernel with a reader-role token and can reach POST /api/search/fullTextSearchBlock. An attacker can inject a UNION SELECT through paths[] and return rows from hidden documents while projecting an allowed visible box and path. The post-query publish access filter trusts the projected box and path, so the injected hidden row is returned to the publish visitor. Affected Code The API blocks explicit SQL search mode for non-admin users, but allows other search methods to use caller-controlled paths: Source: input/siyuan/kernel/api/search.go paths[] is parsed into notebook IDs and paths without SQL escaping or validation: Source: input/siyuan/kernel/api/search.go Those values are then concatenated directly into SQL: Source: input/siyuan/kernel/model/search.go Regexp search…
Recommended action: Upgrade to 0.0.0-20260704035518-d0f0fe146fb0 (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-20260628153353-2d5d72223df4
Fixed in
0.0.0-20260628153353-2d5d72223df4· Vendor fix available
Issue
SiYuan v3.6.5 and earlier versions contain a stored cross-site scripting (XSS) vulnerability in the Attribute View (database) asset cell renderer that escalates to remote code execution (RCE) in the Electron desktop client. This is a neighbor-bug of CVE-2026-44588: the fix for -44588 used escapeAriaLabel() (double-escapes <), but the AV asset renderers were left using the weaker escapeAttr() (escapes only quotes) or no escaping at all. Vulnerability Details The Electron renderer is configured with nodeIntegration: true and contextIsolation: false (app/electron/main.js:307), allowing any JavaScript executing in the renderer to directly access Node.js APIs including require('childprocess'). Two XSS sinks exist. Sink 1 (Direct Stored XSS - triggers on page load) app/src/protyle/render/av/cell.ts:1008: text += <span class="b3-chip avcelltext--url ariaLabel" aria-label="${escapeAttr(item.content)}" data-name="${escapeAttr(item.name)}"…
Recommended action: Upgrade to 0.0.0-20260628153353-2d5d72223df4 (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-20260628153353-2d5d72223df4
Fixed in
0.0.0-20260628153353-2d5d72223df4· Vendor fix available
Issue
The attribute-view (database) cell renderer genAVValueHTML interpolates cell content raw in four of its branches: text, url, phone, and mAsset. A cell value like </textarea<img src=x onerror="..." or "<img src=x onerror="..." breaks out of its surrounding tag and runs arbitrary JavaScript in the renderer when the victim opens the block-attribute panel. On Electron desktop the renderer runs with nodeIntegration:true, so the XSS chains to host RCE via require('childprocess'). AV files live under the workspace and ride normal sync, so an attacker with write access to any synced workspace plants the payload once and it fires on every device that opens a panel containing that row. The kernel doesn't escape on the way in either, so the malicious cell persists byte-for-byte. There's no equivalent of the html.EscapeAttrVal call that protects block IAL attributes at kernel/model/blockial.go:261. Companion advisory: GHSA-mvjr-vv3c-w4qv. Same workspace-sync to renderer-sink to…
Recommended action: Upgrade to 0.0.0-20260628153353-2d5d72223df4 (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-20260628153353-2d5d72223df4
Fixed in
0.0.0-20260628153353-2d5d72223df4· Vendor fix available
Issue
renderPackageREADME in kernel/bazaar/readme.go renders a Bazaar package README from Markdown to HTML with the lute engine and SetSanitize(true). The lute sanitizer is an event-handler blocklist: allowAttr rejects only attribute names present in a fixed eventAttrs map copied from the w3schools legacy handler list. That map omits modern event handlers. onpointerover, onpointerdown, onauxclick, onbeforetoggle, onfocusin, onanimationstart, and ontransitionend are not in the list, so the sanitizer passes them through verbatim on any tag. The frontend assigns the rendered HTML to mdElement.innerHTML in app/src/config/bazaar.ts with no client-side DOMPurify on this path, into a normal element in the main document (no iframe, no sandbox). The kernel sends no Content-Security-Policy, X-Frame-Options, or X-Content-Type-Options header on any response, so an inline handler runs when its event fires. The README is rendered when an Administrator opens a package in Settings → Marketplace,…
Recommended action: Upgrade to 0.0.0-20260628153353-2d5d72223df4 (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-20260628153353-2d5d72223df4
Fixed in
0.0.0-20260628153353-2d5d72223df4· Vendor fix available
Issue
SiYuan Note's kernel HTTP server unconditionally trusts all chrome-extension:// origins, granting RoleAdministrator access to every installed browser extension without any authentication. Combined with the default empty AccessAuthCode on desktop installs, any Chrome/Chromium extension -- including a compromised legitimate extension via supply chain attack -- can make fully authenticated admin API calls to the SiYuan kernel at 127.0.0.1:6806, enabling data exfiltration, stored XSS injection, and configuration tampering. Affected Versions SiYuan <= v3.6.5 (commit 96dfe0bea474). The chrome-extension allowlist remains unfixed as of the latest commit on the fix branch (d7b77d945e0d). Vulnerability Details Blanket chrome-extension:// Origin Trust (CWE-346) In kernel/model/session.go:277, the CheckAuth middleware exempts all chrome-extension:// origins from authentication: At session.go:284, the request is assigned RoleAdministrator: The AccessAuthCode field defaults to an empty…
Recommended action: Upgrade to 0.0.0-20260628153353-2d5d72223df4 (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-20260628153353-2d5d72223df4
Fixed in
0.0.0-20260628153353-2d5d72223df4· Vendor fix available
Issue
The /api/icon/getDynamicIcon endpoint is explicitly excluded from authentication in SiYuan's kernel router (router.go, "不需要鉴权" -- no auth needed). When called with type=8 and a valid block id parameter, this endpoint invokes RenderDynamicIconContentTemplate, which executes a Go template that includes the querySQL and queryBlocks functions. These functions run arbitrary SELECT statements against the SiYuan SQLite database. An unauthenticated network-adjacent attacker who knows a valid block ID can exfiltrate all user note content, tags, asset references, and block attributes from the database. Details Root cause -- kernel/api/router.go, line 37: Attack chain: 1. getDynamicIcon (kernel/api/icon.go) checks type=8 and calls model.RenderDynamicIconContentTemplate(content, id) when content contains .action{. 2. RenderDynamicIconContentTemplate (kernel/model/template.go:264) parses content as a Go template. The template function map includes querySQL and queryBlocks registered via…
Recommended action: Upgrade to 0.0.0-20260628153353-2d5d72223df4 (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-20260628153353-2d5d72223df4
Fixed in
0.0.0-20260628153353-2d5d72223df4· Vendor fix available
Issue
A CSS snippet body containing </style breaks out of its surrounding <style tag when renderSnippet() interpolates it via insertAdjacentHTML. A payload like </style<img src=x onerror="..." runs arbitrary JavaScript in the renderer. On Electron desktop builds the renderer runs with nodeIntegration:true, so require('childprocess') is reachable from the injected handler and the XSS chains to host RCE. Snippets sync via the workspace repository, so an attacker with write access to any synced workspace plants the payload once and it fires on every device that pulls. The bug also bypasses the user's enabledCSS / enabledJS separation. A user who turned enabledJS off was making a deliberate call not to run untrusted JavaScript; the CSS path runs it anyway. Details Affected: - HEAD 96dfe0b (v3.6.5, 2026-04-21) - Sink: app/src/config/util/snippets.ts:32 - Source: /api/snippet/getSnippet, backed by data/snippets/conf.json - Default config: EnabledCSS: true, EnabledJS: true at…
Recommended action: Upgrade to 0.0.0-20260628153353-2d5d72223df4 (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-20260628153353-2d5d72223df4
Fixed in
0.0.0-20260628153353-2d5d72223df4· Vendor fix available
Issue
The patch for CVE-2026-41894 ("Path Traversal via Double URL Encoding") sanitized the /export/ route but the identical root cause remains in the /assets/path route. In publish mode (anonymous read-only HTTP endpoint, default port 6808), an unauthenticated remote attacker can read arbitrary files inside WorkspaceDir — including conf/conf.json (which contains the AccessAuthCode SHA256 hash, API token, and sync keys), temp/siyuan.db, temp/blocktree.db, and siyuan.log — by double-URL-encoding .. segments. Verified against siyuan v3.6.5: - GET /assets/%252e%252e/%252e%252e/conf/conf.json → HTTP 200, 10349 bytes (conf.json served) - GET /export/%252e%252e/%252e%252e/conf/conf.json → HTTP 401 (patched) - GET /assets/%2e%2e/conf/conf.json → HTTP 404 (single-decode handled correctly) Vulnerable Code Step 1 — route & first decode (kernel/server/serve.go:587-626): The router registers GET /assets/path for the publish listener. Gin performs one URL decoding pass on URL.Path, so a…
Recommended action: Upgrade to 0.0.0-20260628153353-2d5d72223df4 (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-20260512140701-d7b77d945e0d
Fixed in
0.0.0-20260512140701-d7b77d945e0d· Vendor fix available
Issue
SiYuan publish-mode Reader can mutate Conf and SQL index via 8 ungated APIs POST /api/graph/getGraph, POST /api/graph/getLocalGraph, POST /api/sync/setSyncInterval, POST /api/storage/updateRecentDocViewTime, POST /api/storage/updateRecentDocCloseTime, POST /api/storage/updateRecentDocOpenTime, POST /api/storage/batchUpdateRecentDocCloseTime, and POST /api/search/updateEmbedBlock are registered with model.CheckAuth only, omitting both model.CheckAdminRole and model.CheckReadonly. Each of them writes server-side state, including atomic rewrites of <workspace/conf/conf.json via model.Conf.Save(). Any caller whose JWT passes CheckAuth, including a publish-service RoleReader (the role assigned to anonymous publish visitors) and a RoleEditor against a workspace where Editor.ReadOnly = true, can hit them. This is the same root-cause class as the patched GHSA-6r88-8v7q-q4p2 and GHSA-4j3x-hhg2-fm2x. Details Affected: github.com/siyuan-note/siyuan, all tags up to and including v3.6.5…
Recommended action: Upgrade to 0.0.0-20260512140701-d7b77d945e0d (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-20260512140701-d7b77d945e0d
Fixed in
0.0.0-20260512140701-d7b77d945e0d· Vendor fix available
Issue
The advisory GHSA-c77m-r996-jr3q patched getBookmark so that, when invoked by a publish-mode RoleReader, results are filtered through FilterBlocksByPublishAccess to remove entries from password-protected / publish-ignored notebooks. Four sibling search handlers in the same file did not receive the equivalent treatment and continue to expose metadata across the publish-access boundary. Details Affected files / lines (v3.6.5): kernel/api/router.go:181-190 — all four endpoints registered with CheckAuth only, which the publish-service RoleReader JWT passes: kernel/api/search.go — none of the four handlers branches on model.IsReadOnlyRoleContext(c) to filter the response, while their peers in the same file do. Compare: model.SearchAssetsByName, model.SearchTags, model.SearchWidget, model.SearchTemplate operate over the entire workspace database / filesystem, not just the publish-visible subset. A FilterTagsByPublishIgnore helper already exists in kernel/model/ and is used by…
Recommended action: Upgrade to 0.0.0-20260512140701-d7b77d945e0d (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-20260512140701-d7b77d945e0d
Fixed in
0.0.0-20260512140701-d7b77d945e0d· Vendor fix available
Issue
POST /api/tag/getTag is registered with model.CheckAuth only, omitting both model.CheckAdminRole and model.CheckReadonly, despite the handler performing a configuration write that is normally guarded by both. Any authenticated user — including publish-service RoleReader accounts and RoleEditor accounts on a read-only workspace — can call this endpoint with a sort argument to mutate model.Conf.Tag.Sort and trigger model.Conf.Save(), which atomically rewrites the entire workspace conf.json. Same root-cause class as the patched GHSA-4j3x-hhg2-fm2x (which fixed missing CheckAdminRole + CheckReadonly on /api/template/renderSprig). Details Affected files / lines (v3.6.5): kernel/api/router.go:170 — only CheckAuth: kernel/api/tag.go:28-64 — handler. The if nil != arg["sort"] block writes config without any role check: Conf.Save() rewrites the entire configuration file, which means a malicious caller racing with a legitimate config change can roll back another user's setting (TOCTOU…
Recommended action: Upgrade to 0.0.0-20260512140701-d7b77d945e0d (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-20260421031503-96dfe0bea474
Fixed in
0.0.0-20260512140701-d7b77d945e0d· Vendor fix available
Issue
The kernel stores Attribute View (AV / database) names without any HTML escape, then a render template uses raw strings.ReplaceAll(tpl, "${avName}", nodeAvName) to embed the name in HTML before pushing to all clients via WebSocket. Three independent client paths (render.ts:120 → outerHTML, Title.ts:401 → innerHTML, transaction.ts:559 → innerHTML) consume the value without escaping. Because the main BrowserWindow runs nodeIntegration:true, contextIsolation:false, webSecurity:false (app/electron/main.js:407-411), HTML injection in the renderer becomes Node.js code execution. Payload is stored on disk under data/storage/av/<id.json, replicates via every sync transport (S3 / WebDAV / cloud), survives .sy.zip export-import, and triggers for any role (Administrator / Editor / Reader / publish-service Visitor) opening a doc bound to the AV. Details Kernel write — no escape. kernel/model/attributeview.go:3244-3255: Kernel template — raw replace.…
Recommended action: Upgrade to 0.0.0-20260512140701-d7b77d945e0d (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for CVE-2026-30869 in SiYuan v3.5.10 only added a denylist check (IsSensitivePath) but did not address the root cause — a redundant url.PathUnescape() call in serveExport(). An authenticated attacker can use double URL encoding (%252e%252e) to traverse directories and read arbitrary workspace files including the full SQLite database (siyuan.db), kernel log, and all user documents. Details In kernel/server/serve.go, the serveExport() function (line 314-320) processes file paths as follows: Go's HTTP server already decodes percent-encoded characters once during request parsing. The additional url.PathUnescape() call creates a double-decode vulnerability: 1. Attacker sends: GET /export/%252e%252e/siyuan.db 2. Go HTTP decodes %25 → %, result: URL.Path = /export/%2e%2e/siyuan.db 3. Go's path cleaner sees %2e%2e as literal characters (not ..), no redirect occurs 4. url.PathUnescape("%2e%2e") decodes to .. 5. filepath.Join(exportBaseDir, "../siyuan.db") resolves to…
Recommended action: Upgrade to 3.6.5 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-20260414013942-62eed37a3263
Fixed in
0.0.0-20260414013942-62eed37a3263· Vendor fix available
Issue
The incomplete fix for SiYuan's bazaar README rendering enables the Lute HTML sanitizer but fails to block <iframe tags, allowing stored XSS via srcdoc attributes containing embedded scripts that execute in the Electron context. Affected Package - Ecosystem: Go - Package: github.com/siyuan-note/siyuan - Affected versions: < commit b382f50e1880 - Patched versions: = commit b382f50e1880 Details The renderPackageREADME() function in kernel/bazaar/readme.go renders Markdown README content from bazaar (marketplace) packages into HTML. The original vulnerability allowed stored XSS through unsanitized HTML in READMEs. The fix adds luteEngine.SetSanitize(true) to enable Lute's built-in HTML sanitizer. However, the Lute sanitizer in lute/render/sanitizer.go has a critical gap: 1. <iframe is explicitly commented out of setOfElementsToSkipContent, so iframe tags pass through. 2. The srcdoc attribute is checked against URL-prefix blocklists (javascript:, data:text/html), but srcdoc…
Recommended action: Upgrade to 0.0.0-20260414013942-62eed37a3263 (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-20260407035653-2f416e5253f1
Fixed in
0.0.0-20260407035653-2f416e5253f1· Vendor fix available
Issue
An authenticated publish-service reader can invoke /api/av/removeUnusedAttributeView and cause persistent deletion of arbitrary attribute view (AV) definition files from the workspace. The route is protected only by generic CheckAuth, which accepts publish RoleReader requests. The handler forwards a caller-controlled id directly into a model function that deletes data/storage/av/<id.json without verifying either: - that the caller is allowed to perform write/destructive actions; or - that the target AV is actually unused. This is a persistent integrity and availability issue reachable from the publish surface. Root Cause 1. Publish users are issued a RoleReader JWT - kernel/model/auth.go 2. The publish reverse proxy forwards that token upstream - kernel/server/proxy/publish.go - kernel/server/proxy/publish.go 3. CheckAuth accepts RoleReader - kernel/model/session.go 4. The route is exposed with CheckAuth only - kernel/api/router.go There is no CheckAdminRole and no…
Recommended action: Upgrade to 0.0.0-20260407035653-2f416e5253f1 (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-20260407035653-2f416e5253f1
Fixed in
0.0.0-20260407035653-2f416e5253f1· Vendor fix available
Issue
SiYuan configures Mermaid.js with securityLevel: "loose" and htmlLabels: true. In this mode, <img tags with src attributes survive Mermaid's internal DOMPurify and land in SVG <foreignObject blocks. The SVG is injected via innerHTML with no secondary sanitization. When a victim opens a note containing a malicious Mermaid diagram, the Electron client fetches the URL. On Windows, a protocol-relative URL (//attacker.com/image.png) resolves as a UNC path (\\attacker.com\image.png). Windows attempts SMB authentication automatically, sending the victim's NTLMv2 hash to the attacker. Root Cause Mermaid initialization at app/src/protyle/render/mermaidRender.ts lines 28 and 33: mermaid.initialize({ securityLevel: "loose", flowchart: { htmlLabels: true, }, }); SVG injection at line 101: renderElement.lastElementChild.innerHTML = mermaidData.svg; No DOMPurify or other sanitization between the Mermaid output and DOM insertion. Mermaid v11.12.0 in "loose" mode strips active JavaScript (<script,…
Recommended action: Upgrade to 0.0.0-20260407035653-2f416e5253f1 (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-20260407035653-2f416e5253f1
Fixed in
0.0.0-20260407035653-2f416e5253f1· Vendor fix available
Issue
A malicious note synced to another user can trigger remote code execution in the SiYuan Electron desktop client. The root cause is that table caption content is stored without safe escaping and later unescaped into rendered HTML, creating a stored XSS sink. Because the desktop renderer runs with nodeIntegration enabled and contextIsolation disabled, attacker-controlled JavaScript executes with access to Node.js APIs. In practice, an attacker can import a crafted note into a synced workspace, wait for the victim to sync, and achieve code execution when the victim opens the note. Details The vulnerability exists in the table caption handling path. When a table block is parsed, the caption attribute is saved into the node's IAL properties without proper HTML escaping. Later, during rendering, that value is read back, passed through HTML unescaping, and written directly into the output DOM. This turns an attacker-controlled caption into active HTML inside the rendered note. I…
Recommended action: Upgrade to 0.0.0-20260407035653-2f416e5253f1 (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-20260330031106-f09953afc57a
Fixed in
0.0.0-20260330031106-f09953afc57a· Vendor fix available
Issue
The SanitizeSVG function introduced in v3.6.0 to fix XSS in the unauthenticated /api/icon/getDynamicIcon endpoint can be bypassed by using namespace-prefixed element names such as <x:script xmlns:x="http://www.w3.org/2000/svg". The Go HTML5 parser records the element's tag as "x:script" rather than "script", so the tag check passes it through. The SVG is served with Content-Type: image/svg+xml and no Content Security Policy; when a browser opens the response directly, its XML parser resolves the prefix to the SVG namespace and executes the embedded script. Details The getDynamicIcon route is registered without authentication: For type 8, the content query parameter is inserted directly into an SVG <text element using fmt.Sprintf with no HTML encoding: SanitizeSVG then parses the SVG with github.com/88250/lute/html and removes elements whose lowercased tag name matches a fixed list: The lute HTML parser stores the full qualified name including any namespace prefix in…
Recommended action: Upgrade to 0.0.0-20260330031106-f09953afc57a (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-20260329142331-918d1bd9f967
Fixed in
0.0.0-20260329142331-918d1bd9f967· Vendor fix available
Issue
A vulnerability allows crafted block attribute values to bypass server-side attribute escaping when an HTML entity is mixed with raw special characters. An attacker can embed a malicious IAL value inside a .sy document, package it as a .sy.zip, and have the victim import it through the normal Import - SiYuan .sy.zip workflow. Once the note is opened, the malicious attribute breaks out of its original HTML context and injects an event handler, resulting in stored XSS. In the Electron desktop client, this XSS reaches remote code execution because injected JavaScript runs with access to Node/Electron APIs. Details The issue is caused by a logic regression in escapeNodeAttributeValues in kernel/filesys/tree.go. Previously, the escaping logic converted node.KramdownIAL with parse.IAL2Map(...) before deciding whether a value needed escaping. That conversion unescaped existing entities first, so mixed values such as: were still recognized as unsafe and escaped correctly. The logic…
Recommended action: Upgrade to 0.0.0-20260329142331-918d1bd9f967 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: In kernel/model/publishaccess.go, FilterBlocksByPublishAccess allows access when c ==…
Recommended action: Upgrade to 3.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malicious website can achieve Remote Code Execution (RCE) on any desktop running SiYuan by exploiting the permissive CORS policy (Access-Control-Allow-Origin: + Access-Control-Allow-Private-Network: true) to inject a JavaScript snippet via the API. The injected snippet executes in Electron's Node.js context with full OS access the next time the user opens SiYuan's UI. No user interaction is required beyond visiting the malicious website while SiYuan is running. Details Vulnerable files: - kernel/server/serve.go, lines 960-963 — CORS middleware - kernel/api/snippet.go, lines 93-128 — snippet injection endpoint Root cause: The CORS middleware unconditionally sets: The Access-Control-Allow-Private-Network: true header explicitly opts into Chrome's Private Network Access specification, telling the browser that external websites are permitted to access this localhost service. Combined with Access-Control-Allow-Origin: , any website on the internet can make authenticated…
Recommended action: Upgrade to 3.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker who can place a malicious URL in an Attribute View mAsse field can trigger stored XSS when a victim opens the Gallery or Kanban view with “Cover From - Asset Field” enabled. The vulnerable code accepts arbitrary http(s) URLs without extensions as images, stores the attacker-controlled string in coverURL, and injects it directly into an <img src="..." attribute without escaping. In the Electron desktop client, the injected JavaScript executes with nodeIntegration enabled and contextIsolation disabled, so the XSS reaches arbitrary OS command execution under the victim’s account. Details The vulnerable flow is: 1. IsPossiblyImage(assetPath) accepts arbitrary http(s) URLs without validating that they are safe image URLs. 2. When an Attribute View card uses Cover From - Asset Field, the application copies asset.Content directly into galleryCard.CoverURL / kanbanCard.CoverURL. 3. The front-end renderer inserts coverURL directly into <img…
Recommended action: Upgrade to 3.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.