CVE-2026-93922: SiYuan Stored XSS Risk
TL;DR - CVE-2026-93922 is a high-severity stored XSS vulnerability in SiYuan through version 3.8.4. - Malicious notebook names may execute JavaScript in the Electron renderer, which reportedly has Node.js access. - The issue could enable host command execution, although no confirmed in-the-wild exploitation or public proof of concept has been established. - Restrict untrusted notebook-name changes, monitor endpoint activity, and install the first vendor-confirmed fixed release.
Vulnerability at a Glance
| Field | Details |
|---|---|
| CVE ID | CVE-2026-93922 |
| Product | SiYuan |
| Vulnerable versions | Through 3.8.4, expressed as <= 3.8.4 |
| CVSS | 8.8, High |
| Attack vector | Not exposed in the supplied authoritative record; verify the complete NVD vector |
| Authentication required | Not exposed in the supplied record |
| Patch available | No verified fixed version identified in the available data |
| CISA KEV | Not listed |
| Primary impact | Stored cross-site scripting with potential operating-system command execution |
CVE-2026-93922 affects SiYuan’s handling of notebook names in the Daily Note picker dialog. The issue is classified as stored cross-site scripting, or stored XSS, because attacker-controlled content is saved as a notebook name and later rendered when the picker is opened.
The reported CVSS base score of 8.8 places the vulnerability in the High severity category. However, the complete CVSS vector was not available in the supplied NVD result. Organizations should not reconstruct the vector from assumptions. Verify the authoritative NVD record before comparing this vulnerability with internal severity thresholds.
What Is CVE-2026-93922?
The apparent root cause is insufficient output encoding or sanitization of notebook names before they are inserted into the Daily Note picker’s HTML-rendering path. A user who can create or modify a notebook name may place HTML or JavaScript content in that name. When another user opens the relevant picker, the application may render the name as active content instead of treating it as plain text.
The impact could extend beyond browser-based XSS. SiYuan is an Electron application, and the reported vulnerable renderer has Node.js access. If that execution context is available to the payload as described, JavaScript could potentially:
- Invoke local operating-system functionality
- Launch processes
- Modify files
- Access resources available to the application account
- Create or alter content within the user’s environment
The NVD references identify relevant implementation areas in the SiYuan source tree:
app/src/util/mount.ts, referenced around line 72kernel/model/file.go, referenced around lines 2446–2454
These locations should be reviewed alongside the vendor’s GitHub Security Advisory to validate the complete data flow and exact remediation change. The central defensive issue is the use of attacker-controlled notebook metadata in an HTML-rendering context without adequate escaping.
Who Is Affected?
The affected product is SiYuan, a note-taking and knowledge-management application. The available CVE description identifies all versions through and including 3.8.4 as affected. Defenders should treat the vulnerable range as:
SiYuan <= 3.8.4
The supplied vulnerability data does not identify operating-system-specific exclusions. Organizations should therefore review supported SiYuan installations running 3.8.4 or earlier, regardless of whether they are deployed on Windows, macOS, or Linux.
The issue is especially relevant where users:
- Share notebooks
- Synchronize content
- Import notebooks from external sources
- Allow one user to influence notebook names viewed by another user
- Open workspaces obtained from untrusted locations
Single-user deployments also require review. A malicious notebook name could be introduced through an untrusted backup, synchronized workspace, imported content, or compromised account. If you regularly exchange backups, review guidance on what a backup is before restoring content from an untrusted source.
A verified fixed version was not identified in the available NVD data, repository pages, or research note. Do not describe a later SiYuan release as fixed unless the project advisory or release notes explicitly confirm it.
CVSS Score Breakdown
CVE-2026-93922 has a reported CVSS base score of 8.8 High. The supplied NVD result did not expose the complete vector string or its individual components. Consequently, the exact attack vector, privileges required, user interaction, scope, and confidentiality, integrity, and availability values cannot be stated reliably from the available record.
This limitation matters operationally. A CVSS score alone does not establish whether exploitation requires network access, an authenticated SiYuan account, a specific user action, or local access to the application. Security teams should retrieve the authoritative NVD record and vendor advisory, record the complete vector, and then adjust prioritization based on deployment architecture and trust boundaries.
The technical impact described by the sources remains significant even without the vector components. A stored script executing inside an Electron renderer with Node.js access may cross the normal boundary between application content and the host operating system. Defenders should assess the privileges of the SiYuan process and the data accessible to the logged-in operating-system account.
Exploitation Status
CISA does not currently list CVE-2026-93922 in its Known Exploited Vulnerabilities catalog. The supplied assessment also found no confirmed evidence of exploitation in the wild and no ransomware campaign information associated with this CVE.
The absence of a KEV entry is not proof that exploitation cannot occur. It means only that CISA has not included this CVE in that catalog at the time of assessment.
No separate public proof-of-concept repository was verified in the available research. The vulnerability is nevertheless technically understandable from the published description: an attacker creates a notebook with an HTML or JavaScript payload, causes the Daily Note picker to render the name, and executes the payload in the Electron renderer. Because the reported renderer has Node.js access, defenders should treat successful exploitation as potentially capable of local command execution.
Risk assessments should distinguish between “no confirmed exploitation” and “not exploitable.” Organizations with exposed or shared SiYuan deployments should monitor for abuse rather than waiting for a public exploit. Recheck threat intelligence, vendor advisories, and the CISA KEV catalog after remediation guidance becomes available.
How to Detect CVE-2026-93922
Detection should combine application inventory, notebook metadata review, endpoint telemetry, and user reports.
First, identify SiYuan installations and confirm whether any run version 3.8.4 or earlier. Next, review notebook names for:
- Suspicious HTML elements
- Event handlers
- Script fragments
- Encoded JavaScript
- References to local process execution
- Unexpected external URLs
Such content is not by itself proof of exploitation, but it can identify malicious input requiring containment.
Endpoint monitoring is particularly important because the described impact may extend beyond the application. Look for SiYuan or its Electron helper processes spawning shells, scripting engines, interpreters, download utilities, or unexpected child processes. Also investigate:
- File modifications
- Credential-store access
- Persistence changes
- New scheduled tasks or services
- Outbound connections shortly after the Daily Note picker is opened
- Unexpected access to sensitive user files
For personal endpoints, reputable endpoint security software such as Get Malwarebytes → may help identify suspicious child processes or malicious files. Endpoint protection is a supplemental control and does not patch the SiYuan vulnerability.
Technical Detection Notes
A generic process-creation query can identify suspicious descendants of SiYuan. Adapt executable names and field names to the EDR or SIEM in use:
process.parent.name IN ("siyuan", "SiYuan", "siyuan.exe")
AND process.name IN (
"cmd.exe", "powershell.exe", "pwsh.exe", "bash", "sh",
"zsh", "python", "python3", "curl", "wget", "osascript"
)
On Linux systems using auditd, a temporary rule can help identify process execution by the SiYuan account or binary. Replace the path with the actual installation location:
sudo auditctl -a always,exit -F arch=b64 \
-S execve -F exe=/opt/SiYuan/siyuan -k siyuan_process
sudo ausearch -k siyuan_process -i
A useful investigation pattern is a SiYuan process followed by a shell or scripting interpreter within a short time window. Also search endpoint telemetry for command lines containing:
-c-Command-EncodedCommandcurlwget- References to newly created files
These indicators are behavioral heuristics, not definitive signatures for CVE-2026-93922.
Mitigation and Patching
The affected range is SiYuan through 3.8.4, and the available data does not provide a verified fixed release number. Upgrade to the first version explicitly identified as fixed by the SiYuan security advisory or release notes. Do not claim that an arbitrary newer release resolves the issue without vendor confirmation.
Until a verified fix is available:
- Prevent untrusted users from creating or modifying notebook names.
- Review existing notebook names for HTML and JavaScript payloads.
- Avoid opening the Daily Note picker against untrusted workspaces.
- Isolate affected endpoints from sensitive systems where practical.
- Monitor SiYuan for unexpected child-process creation.
- Restrict access to shared notebooks and synchronization locations.
- Treat imported backups and workspaces as untrusted until reviewed.
These controls reduce exposure but do not remove the vulnerability.
If exploitation is suspected, preserve endpoint and application evidence before deleting suspicious notebook names. Quarantine the affected host when appropriate, identify the operating-system account running SiYuan, review child-process activity and file changes, and rotate credentials that may have been accessible to that account. Use a reputable password manager, such as Try 1Password →, to generate and store replacement credentials where appropriate.
Technical Patching Notes
After the vendor confirms a fixed version, use the project’s documented installation method. For a package or binary deployment, the operational procedure should resemble the following, with <FIXED_VERSION> replaced only after verification:
# Record the current version and stop the application
siyuan --version
sudo systemctl stop siyuan
# Install the vendor-confirmed fixed release
# Use the official SiYuan package, updater, or release artifact.
sudo install -m 0755 ./siyuan-<FIXED_VERSION> /usr/local/bin/siyuan
sudo systemctl start siyuan
siyuan --version
Do not execute this example with an unverified version number. For desktop deployments, use the official SiYuan updater or release package and verify that the installed version is at or above the vendor-confirmed fixed release.
The immediate workaround is administrative rather than a configuration toggle: restrict notebook-name modification to trusted users, segregate shared workspaces, and avoid rendering untrusted notebooks in the Daily Note picker. Because the vulnerable behavior is an application rendering flaw, network filtering alone is unlikely to provide complete protection for a locally opened malicious workspace.
Incident Response Considerations
If suspicious notebook content or unexpected process activity is identified:
- Disconnect the affected host from sensitive networks while preserving evidence.
- Record the SiYuan version, installation path, operating-system account, and workspace locations.
- Preserve relevant notebook files, application logs, endpoint telemetry, and process trees.
- Identify any shells, scripting engines, download utilities, or other child processes launched by SiYuan.
- Review recently modified files, persistence mechanisms, and outbound connections.
- Rotate credentials accessible to the affected operating-system account.
- Reinstall or upgrade SiYuan only after collecting the evidence needed for investigation.
- Restore notebooks from trusted backups after validating their contents.
If the application ran with access to sensitive files or credentials, assume those resources may have been exposed until the investigation demonstrates otherwise.
References
The primary reference is the NVD record for CVE-2026-93922. It provides the affected product and version range, the 8.8 High severity rating, the stored-XSS description, and links to the vendor’s security advisory and source-code references:
- NVD: CVE-2026-93922
- SiYuan GitHub Security Advisory
- SiYuan source:
mount.tsat version 3.8.4 - SiYuan source:
file.goat version 3.8.4
Additional context is available from the SiYuan project repository and the VulnCheck advisory. Check these references for a confirmed remediation release because the available data does not identify a fixed version:
CVE-2026-93922 should be treated as a high-priority application and endpoint risk for organizations using affected SiYuan versions. No confirmed in-the-wild exploitation or public proof of concept is established, but the reported Electron and Node.js execution context makes timely containment, monitoring, and verified patching important.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.