Summary
SiYuan before v3.7.3 contains stored and reflected cross-site scripting vulnerabilities in its SVG sanitization logic, allowing attackers to smuggle executable script content through seemingly safe SVG elements.
When crafted SVGs are served as image/svg+xml, browsers execute the embedded scripts in the application's origin, enabling privileged actions wherever the malicious SVG is rendered.
SiYuan before v3.7.3 contains stored and reflected cross-site scripting vulnerabilities in its SVG sanitization logic, allowing attackers to smuggle executable script content through seemingly safe SVG elements.
When crafted SVGs are served as image/svg+xml, browsers execute the embedded scripts in the application's origin, enabling privileged actions wherever the malicious SVG is rendered.
Affected context
This vulnerability occurs when SiYuan processes user-supplied SVG content and attempts to sanitize it using an HTML parser-based cleaner.
The issue is most relevant in contexts where authenticated users can upload, embed, or otherwise store SVGs that are later rendered as image/svg+xml in the browser.
It relies on a mismatch between how the sanitizer interprets certain SVG sub-elements (like desc, style, and noscript) as inert text and how browsers interpret the same content as executable script when served with an SVG MIME type.
This vulnerability occurs when SiYuan processes user-supplied SVG content and attempts to sanitize it using an HTML parser-based cleaner.
The issue is most relevant in contexts where authenticated users can upload, embed, or otherwise store SVGs that are later rendered as image/svg+xml in the browser.
It relies on a mismatch between how the sanitizer interprets certain SVG sub-elements (like desc, style, and noscript) as inert text and how browsers interpret the same content as executable script when served with an SVG MIME type.
Exploit preconditions
- Attack surface: Web UI endpoints that accept, store, or reflect user-supplied SVG content.
- Required access: Authenticated access sufficient to create or modify content containing SVG (e.g., notes, attachments, custom assets).
- Trigger point: Viewing or rendering a compromised SVG resource in a browser where it is served with the image/svg+xml content type.
- Why exploitation is possible: The sanitizer relies on HTML parsing rules that treat certain elements as raw text, but browsers apply SVG-specific parsing rules that re-enable script execution, allowing attacker-controlled script to run in the application's origin.
- Attack surface: Web UI endpoints that accept, store, or reflect user-supplied SVG content.
- Required access: Authenticated access sufficient to create or modify content containing SVG (e.g., notes, attachments, custom assets).
- Trigger point: Viewing or rendering a compromised SVG resource in a browser where it is served with the image/svg+xml content type.
- Why exploitation is possible: The sanitizer relies on HTML parsing rules that treat certain elements as raw text, but browsers apply SVG-specific parsing rules that re-enable script execution, allowing attacker-controlled script to run in the application's origin.
Why this happens
The underlying bug class is cross-site scripting caused by insufficient sanitization of markup content.
The sanitization pipeline uses an HTML parser-based cleaner that assumes elements such as desc, style, and noscript are safe text containers and does not fully account for SVG-specific execution semantics.
In the SVG context, these elements can carry or reference script-like data that browsers interpret as active content when served with an image/svg+xml MIME type.
This mismatch between the sanitizer's trust model and the browser's SVG execution model maps directly to CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-Site Scripting).
The underlying bug class is cross-site scripting caused by insufficient sanitization of markup content.
The sanitization pipeline uses an HTML parser-based cleaner that assumes elements such as desc, style, and noscript are safe text containers and does not fully account for SVG-specific execution semantics.
In the SVG context, these elements can carry or reference script-like data that browsers interpret as active content when served with an image/svg+xml MIME type.
This mismatch between the sanitizer's trust model and the browser's SVG execution model maps directly to CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-Site Scripting).
Potential impact
- Authenticated attackers may execute arbitrary JavaScript in the context of affected SiYuan users.
- Malicious scripts could access or modify user notes, documents, and metadata.
- Attackers can perform actions on behalf of victims, such as configuration changes or data manipulation.
- Session data or other sensitive information accessible to scripts can be exfiltrated to attacker-controlled endpoints.
- Further compromise may be possible via browser-based pivoting or abuse of trusted integrations.
- Authenticated attackers may execute arbitrary JavaScript in the context of affected SiYuan users.
- Malicious scripts could access or modify user notes, documents, and metadata.
- Attackers can perform actions on behalf of victims, such as configuration changes or data manipulation.
- Session data or other sensitive information accessible to scripts can be exfiltrated to attacker-controlled endpoints.
- Further compromise may be possible via browser-based pivoting or abuse of trusted integrations.
General mitigation guidance
Effective mitigation focuses on treating SVG as active content and aligning sanitization with browser SVG semantics rather than only HTML rules.
Defensive patterns typically include:
- Using specialized SVG-aware sanitizers that explicitly whitelist safe elements and attributes while stripping or rewriting anything that can trigger script execution.
- Normalizing content types so that inline or user-supplied SVG is not served as image/svg+xml unless it has passed strict validation.
- Applying a default-deny policy for SVG features commonly abused for XSS, such as script elements, external resource references, and dynamic styles.
- Segregating user-generated SVG to a less-privileged origin or sandboxed rendering context when feasible, limiting the impact of any execution.
- Reducing trusted input surfaces by restricting where and how SVG can be embedded in user content.
Effective mitigation focuses on treating SVG as active content and aligning sanitization with browser SVG semantics rather than only HTML rules.
Defensive patterns typically include:
- Using specialized SVG-aware sanitizers that explicitly whitelist safe elements and attributes while stripping or rewriting anything that can trigger script execution.
- Normalizing content types so that inline or user-supplied SVG is not served as image/svg+xml unless it has passed strict validation.
- Applying a default-deny policy for SVG features commonly abused for XSS, such as script elements, external resource references, and dynamic styles.
- Segregating user-generated SVG to a less-privileged origin or sandboxed rendering context when feasible, limiting the impact of any execution.
- Reducing trusted input surfaces by restricting where and how SVG can be embedded in user content.
How teams detect issues like this
Detection typically hinges on recognizing unsafe handling of SVG content in web applications:
- Static analysis rules can flag flows where user-controlled SVG or markup is stored and later rendered without an SVG-aware sanitization layer or strict content-type controls.
- Code reviews should look for reliance on generic HTML sanitizers or DOM cleaners applied to SVG input, especially where elements like style, desc, or noscript are passed through unchanged.
- Security testing and fuzzing can use crafted SVG payloads to verify whether application endpoints can be coerced into executing script when content is served as image/svg+xml.
- Policy enforcement in CI/CD pipelines can require that any new feature involving SVG upload or rendering includes a vetted sanitizer and explicit origin/Content-Type handling.
- Automated tools that simulate browser behavior with SVG MIME types can help identify sanitization bypasses that do not appear in HTML-only contexts.
Detection typically hinges on recognizing unsafe handling of SVG content in web applications:
- Static analysis rules can flag flows where user-controlled SVG or markup is stored and later rendered without an SVG-aware sanitization layer or strict content-type controls.
- Code reviews should look for reliance on generic HTML sanitizers or DOM cleaners applied to SVG input, especially where elements like style, desc, or noscript are passed through unchanged.
- Security testing and fuzzing can use crafted SVG payloads to verify whether application endpoints can be coerced into executing script when content is served as image/svg+xml.
- Policy enforcement in CI/CD pipelines can require that any new feature involving SVG upload or rendering includes a vetted sanitizer and explicit origin/Content-Type handling.
- Automated tools that simulate browser behavior with SVG MIME types can help identify sanitization bypasses that do not appear in HTML-only contexts.
