CVE-2026-59853: SiYuan API Authorization Bypass Exposes Private Document Metadata

Technical summary

The vulnerability resides in the /api/storage/getCriteria endpoint, which retrieves saved search criteria from the data/storage/criteria.json file. Unlike its sibling storage endpoints that implement publish-access filtering, this endpoint lacks equivalent authorization controls. A user with publish-mode Reader privileges can invoke the endpoint to exfiltrate private document metadata (paths, notebook IDs, document IDs, block IDs) and saved search/replace keywords associated with unpublished documents. The root cause is an authorization bypass due to inconsistent access control implementation across the storage API surface. This falls under CWE-862 (Missing Authorization), where a security-relevant action lacks proper permission verification.

Business impact

For SiYuan deployments supporting multi-user collaboration with role-based access (particularly those hosting sensitive knowledge bases or team wikis), this vulnerability enables information disclosure to lower-privileged users. An attacker with Reader access can discover the structure and keywords of private or restricted documents without modification rights, compromising confidentiality. Organizations using SiYuan for collaborative knowledge management where document structures or content outlines are themselves sensitive face an elevated risk. The impact is limited to confidentiality; the vulnerability does not enable data modification or system compromise.

Affected systems

SiYuan versions prior to 3.7.1 are affected. This includes all 3.x releases up to and including 3.7.0, as well as any earlier 2.x or 1.x versions. Organizations should verify their deployed version in the about or settings section. The vulnerability requires network access to the /api/storage/getCriteria endpoint and valid user credentials with at least publish-mode Reader role; it is not a unauthenticated flaw.

Exploitability

Exploitation requires valid authentication as a publish-mode Reader user—a common role in multi-user SiYuan deployments. No user interaction is needed once a user has valid credentials; the attack is automated via a single API call. Network accessibility is required; local-only installations are not at network risk, though administrative users with access to the filesystem can always read the criteria.json file directly. The low complexity and lack of privilege escalation requirements make this straightforward to exploit by any legitimately authenticated Reader, though the attacker must be someone with existing user credentials. It is not listed on the CISA Known Exploited Vulnerabilities catalog.

Remediation

Upgrade SiYuan to version 3.7.1 or later. This patch applies the same publish-access filtering to the /api/storage/getCriteria endpoint that protects other storage APIs, ensuring that Reader users only retrieve criteria associated with documents they have permission to see. Organizations unable to upgrade immediately should consider temporarily restricting publish-mode Reader roles or disabling the storage API for untrusted users if their deployment permits such controls. No workaround is available without code modification.

Patch guidance

Review your SiYuan deployment for current version (Settings > About or check the installed package/docker image tag). If running 3.7.0 or earlier, prioritize upgrading to 3.7.1. For self-hosted installations, update via the official releases page or package manager. For Docker deployments, pull the 3.7.1+ image tag and redeploy. Verify the update by confirming the new version number after restart. No migration or data changes are required; this is a pure security fix. Test in a non-production environment first if feasible, though the patch scope is narrow and low-risk for data integrity.

Detection guidance

Monitor access logs and API request logs for repeated or unusual calls to the /api/storage/getCriteria endpoint, especially from Reader-role accounts. In SiYuan logs, look for authentication events followed by storage API calls from accounts with publish-mode Reader restrictions. If you have deployed SiYuan with a reverse proxy or WAF, consider logging requests to /api/storage/* endpoints and alerting on anomalous patterns. Network-based detection is difficult without context; focus on application-level logging and periodic audits of who accessed the criteria storage API and when. Verify that all users accessing this endpoint have legitimate need to view saved search criteria.

Why prioritize this

Prioritize this for timely but not emergency remediation. The CVSS 6.5 (Medium) rating reflects that exploitation requires valid authentication and impacts only confidentiality. However, in collaborative multi-user environments with sensitive or competitive documents, information disclosure through API misuse can be strategically damaging. The fix is simple and non-disruptive, making upgrade feasible within a standard patch cycle. Organizations with strict access controls (limiting Reader roles) face lower practical risk; those with many Reader users should prioritize upgrade sooner.

Risk score, explained

CVSS 3.1 score of 6.5 (Medium) is derived from: Attack Vector Network (AV:N), Attack Complexity Low (AC:L), Privileges Required to exploit as an authenticated user (PR:L), no User Interaction (UI:N), Scope Unchanged (S:U), high Confidentiality impact (C:H), no Integrity (I:N) or Availability impact (A:N). The score reflects that an attacker with minimal privileges can access sensitive data, but cannot modify data or degrade service. In environments where information disclosure is highly sensitive or compliance-relevant, the real-world severity may warrant accelerated response despite the Medium CVSS rating.

Frequently asked questions