CVE-2026-59853: SiYuan: broken access control leaks private note data

MEDIUM CISA: TRACK*
Published July 9, 2026
CISO Take

SiYuan's /api/storage/getCriteria endpoint fails to apply the same publish-access filter that sibling storage endpoints enforce, so any user granted a low-privilege "Reader" role in publish mode can pull saved search criteria out of criteria.json and see private document paths, notebook/document/block IDs, and search-and-replace keywords for content that was never published. There's no CVSS-driving availability or integrity impact (C:H/I:N/A:N), no CISA KEV listing, no public PoC or Nuclei template, and EPSS data isn't available, so mass exploitation is unlikely — this reads as a low-effort but real information-disclosure bug rather than an active threat. The realistic risk is to self-hosted or shared SiYuan deployments where a publish-mode Reader account is handed to semi-trusted or external users, where the leaked internal IDs and criteria expose knowledge-base structure or content hints that were meant to stay private. Upgrade to SiYuan 3.7.1 or later immediately; if you can't patch right away, restrict or disable publish-mode Reader accounts and audit access logs for calls to /api/storage/getCriteria from non-admin sessions.

Sources: NVD GitHub Advisory CISA KEV ATLAS

What is the risk?

Medium severity (CVSS 6.5, confidentiality-only impact) authorization bypass requiring only a low-privileged authenticated "Reader" account in publish mode — no user interaction and low attack complexity make it trivial to trigger once that access exists, but the low privilege bar and lack of write/execute impact keep it out of critical territory. No CISA KEV listing, no EPSS score, no public exploit code, and no Nuclei template exist, indicating no evidence of active or automated exploitation. Exposure is bounded to SiYuan instances that expose publish-mode Reader accounts to untrusted or semi-trusted users; fully private, single-user deployments are not exposed to this vector.

How does the attack unfold?

Access acquisition
Attacker obtains or is granted a low-privilege publish-mode 'Reader' account on a SiYuan instance.
Endpoint exploitation
Attacker calls /api/storage/getCriteria directly, bypassing the publish-access filter that sibling endpoints enforce.
AML.T0036
Information disclosure
Response leaks private document paths, notebook/document/block IDs, and saved search-and-replace keywords for unpublished content.
AML.T0036

What systems are affected?

Package Ecosystem Vulnerable Range Patched
siyuan No patch

Do you use siyuan? You're affected.

How severe is it?

CVSS 3.1
6.5 / 10
EPSS
0.2%
chance of exploitation in 30 days
Higher than 15% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
CISA SSVC: Public PoC
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C High
I None
A None

What should I do?

1 step
  1. Upgrade SiYuan to version 3.7.1 or later, which applies the missing publish-access filter to the getCriteria endpoint (see commit 0049d0f and GHSA-px3c-cf92-9g83). Until patched, avoid granting publish-mode Reader roles to untrusted users, or disable the publish/sharing feature entirely for workspaces containing sensitive notes. Review criteria.json contents and any exposed notebook/document/block IDs for information that may already have leaked, and audit server logs for unexpected calls to /api/storage/getCriteria from Reader-level sessions as a detection signal.

What does CISA's SSVC say?

Decision Track*
Exploitation poc
Automatable No
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2.3 - Data security and access control for AI system resources
OWASP LLM Top 10
LLM06 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-59853?

SiYuan's /api/storage/getCriteria endpoint fails to apply the same publish-access filter that sibling storage endpoints enforce, so any user granted a low-privilege "Reader" role in publish mode can pull saved search criteria out of criteria.json and see private document paths, notebook/document/block IDs, and search-and-replace keywords for content that was never published. There's no CVSS-driving availability or integrity impact (C:H/I:N/A:N), no CISA KEV listing, no public PoC or Nuclei template, and EPSS data isn't available, so mass exploitation is unlikely — this reads as a low-effort but real information-disclosure bug rather than an active threat. The realistic risk is to self-hosted or shared SiYuan deployments where a publish-mode Reader account is handed to semi-trusted or external users, where the leaked internal IDs and criteria expose knowledge-base structure or content hints that were meant to stay private. Upgrade to SiYuan 3.7.1 or later immediately; if you can't patch right away, restrict or disable publish-mode Reader accounts and audit access logs for calls to /api/storage/getCriteria from non-admin sessions.

Is CVE-2026-59853 actively exploited?

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

How to fix CVE-2026-59853?

Upgrade SiYuan to version 3.7.1 or later, which applies the missing publish-access filter to the getCriteria endpoint (see commit 0049d0f and GHSA-px3c-cf92-9g83). Until patched, avoid granting publish-mode Reader roles to untrusted users, or disable the publish/sharing feature entirely for workspaces containing sensitive notes. Review criteria.json contents and any exposed notebook/document/block IDs for information that may already have leaked, and audit server logs for unexpected calls to /api/storage/getCriteria from Reader-level sessions as a detection signal.

What systems are affected by CVE-2026-59853?

This vulnerability affects the following AI/ML architecture patterns: knowledge management systems, RAG pipelines.

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

CVE-2026-59853 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.24%.

What is the AI security impact?

Affected AI Architectures

knowledge management systemsRAG pipelines

MITRE ATLAS Techniques

AML.T0036 Data from Information Repositories

Compliance Controls Affected

ISO 42001: A.6.2.3
OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

SiYuan is an open-source personal knowledge management system. Prior to 3.7.1, the /api/storage/getCriteria endpoint returns saved search criteria from data/storage/criteria.json without the publish-access filtering used by sibling storage endpoints, allowing a publish-mode Reader to read private document paths, notebook, document, and block IDs, and search and replace keywords for unpublished documents. This issue is fixed in versions 3.7.1.

Exploitation Scenario

An attacker (or a semi-trusted collaborator) who has been granted a Reader account on a SiYuan instance operating in publish mode calls the /api/storage/getCriteria endpoint directly rather than through the normal UI flow, which would have filtered results to published content only. Because the endpoint omits that filter, the response returns saved search criteria including private document paths, notebook/document/block IDs, and search-and-replace keywords tied to unpublished documents. The attacker uses this leaked structural and identifier information to map out the private knowledge base, informing follow-on targeting or social-engineering against document owners even though no direct read of document content occurs through this endpoint alone.

Weaknesses (CWE)

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

  • [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Timeline

Published
July 9, 2026
Last Modified
July 10, 2026
First Seen
July 10, 2026

Related Vulnerabilities