CVE-2026-73608: SiYuan: missing authz exposes filtered DB rows
HIGHCISA: TRACK*SiYuan, the open-source note-taking and knowledge-base app, shipped a database search endpoint in its development branch that enforces authentication but skips the authorization checks that gate access to published, filtered content — so any anonymous reader who has viewed a published page can pull the underlying database identifier and query it directly to retrieve rows that publish-access filters were meant to hide. The practical exposure is narrow: the flaw only exists in code introduced after commit 9b8e8956f and was fixed in v3.7.4 before any stable release shipped it, so instances running the official v3.7.3 release or earlier are unaffected, and only self-built/master-branch or nightly deployments are exposed. That narrow window is reflected in the numbers — EPSS sits at 0.24% (a low absolute probability despite ranking in the 84th percentile), the CVE isn't in CISA KEV, CISA's own SSVC verdict is TRACK_STAR (lowest urgency tier), and there's no public exploit or Nuclei template. For teams self-hosting SiYuan from source or nightly builds with publish/sharing enabled, the fix is to upgrade to v3.7.4 or later immediately since the exploit requires no credentials and no user interaction; teams on the official stable v3.7.3 release have nothing to patch but should confirm their deployment branch before assuming safety.
What is the risk?
CVSS 3.1 rates this 8.6 (High), reflecting network-reachable, low-complexity, no-auth-required access to confidentiality-impacting data (C:H, I:N, A:N — no integrity or availability impact). Real-world risk is lower than the score suggests: the vulnerable endpoint only exists between an unreleased development commit and the v3.7.4 patch, meaning production instances running official stable releases were never exposed. EPSS (0.24%, 84th percentile) and CISA's SSVC TRACK_STAR verdict both corroborate low near-term exploitation likelihood, and no public PoC or scanner template exists. Residual risk concentrates on organizations self-hosting SiYuan from source/master or nightly/dev builds with the publish/sharing feature enabled — for that subset, exploitation is trivial: a single unauthenticated HTTP request with a harvested database ID and keyword.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| siyuan | — | — | No patch |
Do you use siyuan? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 stepUpgrade to SiYuan v3.7.4 or later, where /api/av/getAttributeViewSearchTarget now enforces the same CheckReadonly/publish-access/encrypted-notebook gating as other database endpoints. Organizations running SiYuan from source, nightly builds, or the master branch between commit 9b8e8956f and the v3.7.4 tag should treat this as urgent since no authentication or interaction is required to exploit it. Instances running the official v3.7.3 stable release (or earlier) are not affected and require no action beyond confirming their actual deployment branch/commit. As a compensating control until patched, disable public 'publish' sharing on notebooks containing sensitive attribute-view databases, or restrict access to published pages via network-level controls (VPN, IP allowlist, reverse-proxy auth). Detection: monitor access logs for repeated or scripted calls to /api/av/getAttributeViewSearchTarget from unauthenticated/anonymous sessions, particularly using database IDs scraped from published pages.
What does CISA's SSVC say?
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:
Frequently Asked Questions
What is CVE-2026-73608?
SiYuan, the open-source note-taking and knowledge-base app, shipped a database search endpoint in its development branch that enforces authentication but skips the authorization checks that gate access to published, filtered content — so any anonymous reader who has viewed a published page can pull the underlying database identifier and query it directly to retrieve rows that publish-access filters were meant to hide. The practical exposure is narrow: the flaw only exists in code introduced after commit 9b8e8956f and was fixed in v3.7.4 before any stable release shipped it, so instances running the official v3.7.3 release or earlier are unaffected, and only self-built/master-branch or nightly deployments are exposed. That narrow window is reflected in the numbers — EPSS sits at 0.24% (a low absolute probability despite ranking in the 84th percentile), the CVE isn't in CISA KEV, CISA's own SSVC verdict is TRACK_STAR (lowest urgency tier), and there's no public exploit or Nuclei template. For teams self-hosting SiYuan from source or nightly builds with publish/sharing enabled, the fix is to upgrade to v3.7.4 or later immediately since the exploit requires no credentials and no user interaction; teams on the official stable v3.7.3 release have nothing to patch but should confirm their deployment branch before assuming safety.
Is CVE-2026-73608 actively exploited?
No confirmed active exploitation of CVE-2026-73608 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-73608?
Upgrade to SiYuan v3.7.4 or later, where /api/av/getAttributeViewSearchTarget now enforces the same CheckReadonly/publish-access/encrypted-notebook gating as other database endpoints. Organizations running SiYuan from source, nightly builds, or the master branch between commit 9b8e8956f and the v3.7.4 tag should treat this as urgent since no authentication or interaction is required to exploit it. Instances running the official v3.7.3 stable release (or earlier) are not affected and require no action beyond confirming their actual deployment branch/commit. As a compensating control until patched, disable public 'publish' sharing on notebooks containing sensitive attribute-view databases, or restrict access to published pages via network-level controls (VPN, IP allowlist, reverse-proxy auth). Detection: monitor access logs for repeated or scripted calls to /api/av/getAttributeViewSearchTarget from unauthenticated/anonymous sessions, particularly using database IDs scraped from published pages.
What systems are affected by CVE-2026-73608?
This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, knowledge management platforms.
What is the CVSS score for CVE-2026-73608?
CVE-2026-73608 has a CVSS v3.1 base score of 8.6 (HIGH). The EPSS exploitation probability is 0.30%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0036Data from Information RepositoriesAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
SiYuan's development branch (endpoint introduced by commit 9b8e8956f, not present in v3.7.3 or master, patched in v3.7.4-alpha.3) contains a missing-authorization vulnerability in the /api/av/getAttributeViewSearchTarget endpoint. The route is registered with CheckAuth only and performs no authorization checks (no CheckReadonly, no publish-access or encrypted-notebook gating). Given a database identifier taken from a published page and a keyword, an anonymous reader can query the endpoint to retrieve matching database row content, including rows that publish filters (FilterAttributeViewByPublishAccess) would otherwise withhold. No released stable version is affected.
Exploitation Scenario
An attacker browses a SiYuan-hosted, publicly published notebook page — for example a team's public documentation or project database shared via SiYuan's publish feature — and inspects the page source or network requests to extract the attribute-view (database) identifier embedded in that published content. Using that identifier along with a guessed or observed keyword, the attacker sends an unauthenticated request to /api/av/getAttributeViewSearchTarget. Because the route only checks that a valid session exists (CheckAuth) and skips the publish-access and readonly gating other endpoints enforce, the server returns matching rows from the database — including rows the notebook owner explicitly filtered out of the public view, such as internal notes, PII fields, or draft content columns. The attacker repeats this with different keywords to enumerate the full hidden dataset behind the published page, achieving a confidentiality breach with zero credentials and a single crafted HTTP call.
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:N/UI:N/S:C/C:H/I:N/A:NReferences
Timeline
Related Vulnerabilities
CVE-2025-512010.0smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Data LeakageCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same attack type: Data LeakageCVE-2025-282810.0LangChain RequestsToolkit: SSRF exposes cloud metadata
Same attack type: Auth BypassCVE-2025-5376710.0Azure OpenAI: SSRF EoP, no auth required (CVSS 10)
Same attack type: Auth BypassCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same attack type: Auth Bypass