CVE-2026-82653: stored XSS — HIGH

CISO Take

SiYuan before v3.8.1 fails to escape package and notebook names before injecting them into innerHTML inside confirmDialog(), letting an attacker who publishes a malicious bazaar plugin or crafts a booby-trapped encrypted notebook execute arbitrary JavaScript in a victim's browser session. The scope-changed CVSS 8.9 (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:L) reflects that a single click during uninstall or notebook-unlock can compromise confidentiality and integrity beyond the vulnerable component itself, and there is no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, so this looks like a fresh, low-noise disclosure rather than an actively weaponized bug. SiYuan is used as a personal/team knowledge base and increasingly as a local-first note store that AI workflows (RAG ingestion, note-to-LLM pipelines) read from, so a compromised session can leak notebook contents or pivot into connected tooling. Patch to v3.8.1 or later immediately; until then, treat the bazaar plugin marketplace as untrusted input, restrict who can publish or install plugins, and avoid opening notebooks or uninstalling packages from unverified sources. Security teams should watch for anomalous outbound requests or DOM manipulation originating from the SiYuan desktop/web client shortly after a plugin install or notebook unlock action.

Sources: NVD GitHub Advisory

What is the risk?

High severity primarily due to the scope change (S:C) — the XSS payload executes in the security context of the SiYuan client/browser and can affect resources beyond the vulnerable dialog component, with high confidentiality and integrity impact. Exploitability is moderate: it requires user interaction (uninstalling a package or unlocking an encrypted notebook) and low privileges, but attack complexity is low once a malicious package or notebook name is crafted and placed where a victim will encounter it (e.g., published to the public bazaar). No evidence of active exploitation, no KEV listing, no public PoC/exploit code, and no EPSS score — this is a disclosed-but-not-yet-weaponized vulnerability, which lowers near-term urgency but does not remove it given the low bar to exploit once a malicious bazaar entry is published.

How does the attack unfold?

Malicious package publication

Attacker publishes a bazaar plugin (or crafts an encrypted notebook) with an HTML/script payload embedded in the name field.

AML.T0011.001

Victim interaction

Victim installs the plugin or opens the shared notebook, then later triggers confirmDialog() by uninstalling the package or unlocking the notebook.

AML.T0011

Script execution

The unescaped name is interpolated into innerHTML, executing the attacker's script within the victim's SiYuan session.

Impact

The script can exfiltrate locally stored notebook content or session data, breaching confidentiality and integrity of the victim's knowledge base.

Malicious package publication

Attacker publishes a bazaar plugin (or crafts an encrypted notebook) with an HTML/script payload embedded in the name field.

AML.T0011.001

Victim interaction

Victim installs the plugin or opens the shared notebook, then later triggers confirmDialog() by uninstalling the package or unlocking the notebook.

AML.T0011

Script execution

The unescaped name is interpolated into innerHTML, executing the attacker's script within the victim's SiYuan session.

Impact

The script can exfiltrate locally stored notebook content or session data, breaching confidentiality and integrity of the victim's knowledge base.

How severe is it?

CVSS 3.1

8.9 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI Required

S Changed

C High

I High

A Low

What should I do?

1 step

Upgrade SiYuan to v3.8.1 or later immediately, where confirmDialog() properly escapes interpolated names. Until patched: disable or restrict installation of bazaar plugins to a vetted allowlist, avoid uninstalling packages or unlocking notebooks of unknown provenance, and educate users not to import notebooks or install plugins from untrusted sources. For detection, monitor for unusual DOM/script execution or outbound network activity immediately following plugin uninstall or notebook unlock actions in SiYuan logs, and review bazaar package submissions for HTML/script payloads in name fields. Apply standard XSS defenses where feasible (CSP hardening in the Electron/web shell) as defense-in-depth.

How is it classified?

Supply Chain Code Execution Plugin AML.T0011 - User Execution AML.T0011.001 - Malicious Package

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.3 - Third-party and customer requirements

NIST AI RMF

MAP-3.4 - Third-party resources and processes

OWASP LLM Top 10

LLM03 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-82653?

SiYuan before v3.8.1 fails to escape package and notebook names before injecting them into innerHTML inside confirmDialog(), letting an attacker who publishes a malicious bazaar plugin or crafts a booby-trapped encrypted notebook execute arbitrary JavaScript in a victim's browser session. The scope-changed CVSS 8.9 (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:L) reflects that a single click during uninstall or notebook-unlock can compromise confidentiality and integrity beyond the vulnerable component itself, and there is no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, so this looks like a fresh, low-noise disclosure rather than an actively weaponized bug. SiYuan is used as a personal/team knowledge base and increasingly as a local-first note store that AI workflows (RAG ingestion, note-to-LLM pipelines) read from, so a compromised session can leak notebook contents or pivot into connected tooling. Patch to v3.8.1 or later immediately; until then, treat the bazaar plugin marketplace as untrusted input, restrict who can publish or install plugins, and avoid opening notebooks or uninstalling packages from unverified sources. Security teams should watch for anomalous outbound requests or DOM manipulation originating from the SiYuan desktop/web client shortly after a plugin install or notebook unlock action.

Is CVE-2026-82653 actively exploited?

No confirmed active exploitation of CVE-2026-82653 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-82653?

Upgrade SiYuan to v3.8.1 or later immediately, where confirmDialog() properly escapes interpolated names. Until patched: disable or restrict installation of bazaar plugins to a vetted allowlist, avoid uninstalling packages or unlocking notebooks of unknown provenance, and educate users not to import notebooks or install plugins from untrusted sources. For detection, monitor for unusual DOM/script execution or outbound network activity immediately following plugin uninstall or notebook unlock actions in SiYuan logs, and review bazaar package submissions for HTML/script payloads in name fields. Apply standard XSS defenses where feasible (CSP hardening in the Electron/web shell) as defense-in-depth.

What systems are affected by CVE-2026-82653?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, plugin marketplaces, local knowledge/RAG ingestion pipelines.

What is the CVSS score for CVE-2026-82653?

CVE-2026-82653 has a CVSS v3.1 base score of 8.9 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksplugin marketplaceslocal knowledge/RAG ingestion pipelines

MITRE ATLAS Techniques

AML.T0011 User Execution

AML.T0011.001 Malicious Package

Compliance Controls Affected

ISO 42001: A.6.2.3

NIST AI RMF: MAP-3.4

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

SiYuan before v3.8.1 contains a stored cross-site scripting vulnerability in confirmDialog() where unescaped package names and notebook names are interpolated directly into innerHTML assignments. Attackers can submit malicious bazaar packages with HTML/script payloads in the name field that execute in users' browsers when uninstalling packages or unlocking encrypted notebooks.

Exploitation Scenario

An attacker publishes a plugin to the SiYuan bazaar with a name field containing a crafted HTML/script payload (e.g., an img tag with an onerror handler). A victim browsing the bazaar installs the plugin out of curiosity, and later decides to uninstall it — triggering confirmDialog(), which interpolates the malicious package name directly into innerHTML and executes the embedded script in the victim's SiYuan session. The script can then read locally stored notebook content, exfiltrate it to an attacker-controlled endpoint, or attempt to pivot to any API keys or tokens accessible within the app's context. A parallel path exists via encrypted notebook names shared with a victim, triggering on the unlock dialog instead of uninstall.

Weaknesses (CWE)

CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Primary

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
[Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.