GHSA-99rq-75j6-5j9f: Stored and Reflected XSS in SiYuan via SVG Sanitizer Bypass

The SiYuan application kernel (github.com/siyuan-note/siyuan/kernel) provides core synchronization and data storage capabilities for the note-taking application. To handle customized assets safely, the application exposes endpoints that process and serve SVG content. Because SVGs can natively execute JavaScript inside browsers via inline tags and attributes, the application relies on an SVG sanitization function, util.SanitizeSVG, to clean incoming graphics. This function is tasked with removing unsafe elements prior to storage or display.

Historically, the application utilized an HTML-based sanitization parser. While this logic successfully stripped common malicious tags under standard HTML conditions, it introduced a significant parser differential when handling SVG document structures. The mismatch between the Go-based HTML parser and the browser's XML-based renderer created a structural blind spot that allowed attackers to inject executable script components.

The vulnerability is classified under CWE-79 (Improper Neutralization of Input During Web Page Generation) and carries a CVSS 3.1 base score of 8.7. The impact of successful exploitation is severe, as it permits unauthorized script execution within the application's origin, which enables local file access, workspace cloning, and administrative API calls.

The root cause of this vulnerability lies in a parser differential between the server-side HTML parser (html.Parse in Go) and the browser-side XML/SVG parser. The original sanitization routine in kernel/util/misc.go processed incoming SVGs by treating them as HTML documents. It traversed the resulting node tree to locate and drop blacklisted tags. Because the parser operated on HTML syntax rules, it followed distinct element-nesting behaviors defined by the HTML5 specification.

In the HTML specification, tags such as <desc> and <title> represent HTML integration points. When an HTML parser encounters these tags, it temporarily transitions back to standard HTML parsing. Inside this HTML context, tags like <style>, <noscript>, and <xmp> are defined as raw text elements. The parser processes their inner content as a literal, unparsed string rather than as child nodes. As a result, if an attacker nested a <script> tag inside a <style> tag, which was further nested inside a <desc> tag, the backend HTML parser did not recognize the nested script as an element node. The sanitizer saw only a harmless text block inside a <style> element and allowed the structure to pass through unchanged.

Conversely, when a modern web browser receives the sanitized SVG payload, it renders the content as image/svg+xml using a strict XML parser. Under XML rules, raw text elements like <style> inside <desc> do not trigger literal parsing exceptions. The browser evaluates the structure of the entire document node-by-node. It parses the nested <script> tag as a valid executable element and runs the payload within the target origin.

The vulnerability was resolved in commit f08dee71ba8e087a395d74f121de11e6a997ef14 by restructuring the parsing architecture of util.SanitizeSVG to eliminate the differential.

The developers abandoned the HTML-based parsing logic and implemented a strict, token-based XML decoder using Go's standard library encoding/xml. This ensures that the server evaluates SVG elements using the same hierarchical structure that the browser's XML parser utilizes.

// Patched logic in kernel/util/misc.go
func SanitizeSVG(svgInput string) (string, error) {
    decoder := xml.NewDecoder(strings.NewReader(svgInput))
    decoder.Strict = true
 
    var buf bytes.Buffer
    encoder := xml.NewEncoder(&buf)
    
    // The parser now tracks nested tokens sequentially and rejects blacklisted tags.
    for {
        token, err := decoder.Token()
        if err == io.EOF {
            break
        }
        if err != nil {
            return "", err
        }
        
        switch se := token.(type) {
        case xml.StartElement:
            // Unsafe tags are rejected explicitly
            if _, unsafe := unsafeSVGElements[strings.ToLower(se.Name.Local)]; unsafe {
                continue
            }
            se.Attr = sanitizeSVGAttributes(se.Attr)
            token = se
        }
        encoder.EncodeToken(token)
    }
    encoder.Flush()
    return buf.String(), nil
}

Additionally, defense-in-depth measures were introduced in kernel/api/icon.go to explicitly escape dynamic inputs and inject a strict Content Security Policy (CSP). The header Content-Security-Policy: script-src 'none'; object-src 'none'; base-uri 'none' is now returned when serving inline SVGs, preventing script execution even if a bypass occurs within the parsing engine.

An attacker can exploit this parser differential using two primary delivery mechanisms.

Vector 1: Reflected Attack via Dynamic Icons The /api/icon/getDynamicIcon endpoint allows clients to retrieve dynamically generated SVGs. When the parameter type is set to 8, the endpoint injects the user-provided string inside the content parameter into the SVG template. Because the original input sanitization parsed this with the vulnerable HTML sanitizer, an attacker could supply a crafted string that triggers the parser differential. When a victim loads the engineered link, the payload executes instantly in their browser context.

curl -sk -G 'http://127.0.0.1:6806/api/icon/getDynamicIcon' \
  --data-urlencode 'type=8' \
  --data-urlencode 'content=</text><desc><style><script>alert(document.domain)</script></style></desc><text>'

Vector 2: Stored Attack via Assets Directory Alternatively, an attacker can upload or synchronize a malicious SVG file (such as evil.svg) directly into the data/assets/ folder. This is achieved via authorized workspace synchronization, template importing, or zip-based restore functions. When any user attempts to view the resource through /assets/evil.svg, the browser interprets the XML structure, bypassing the sanitizer and running the script. The script can perform silent backend requests, capture application data, and send it to an external controller.

The impact of arbitrary script execution within the SiYuan application is significant due to its system architecture. SiYuan often runs locally as an Electron application or a self-hosted server with extensive REST API endpoints. The web origin has access to local kernel APIs that manage file systems, cloud synchronization, and system configurations.

A successful exploit can allow an attacker to make authorized POST requests to /api/system/getConf to obtain API keys, database credentials, and sync passwords. The execution scope allows the attacker to read, modify, or delete any markdown document within the workspace. Because the application processes requests with local user permissions, an attacker can also leverage the compromised web context to exfiltrate database records to external command-and-control servers, achieving complete workspace takeovers.