CVE-2026-73608: SiYuan: missing authz exposes filtered DB rows

HIGHCISA: TRACK*
Published August 13, 2026
CISO Take

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.

Sources:NVDGitHub AdvisoryEPSSATLAS

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?

Reconnaissance
Attacker locates a publicly published SiYuan notebook page and extracts the embedded attribute-view (database) identifier from the page.
AML.T0003
Exploitation
Attacker sends an unauthenticated request to /api/av/getAttributeViewSearchTarget with the harvested database ID and a keyword, bypassing the missing publish-access and readonly checks.
AML.T0049
Impact
Server returns database rows that publish filters were meant to withhold, disclosing restricted note/database content to an anonymous reader.
AML.T0036

What systems are affected?

PackageEcosystemVulnerable RangePatched
siyuan——No patch

Do you use siyuan? You're affected.

How severe is it?

CVSS 3.1
8.6 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 23% 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?

AVACPRUISCIA
AVNetwork
ACLow
PRNone
UINone
SChanged
CHigh
INone
ANone

What should I do?

1 step
  1. 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 does CISA's SSVC say?

DecisionTrack*
Exploitationpoc
AutomatableYes
Technical Impactpartial

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:

NIST AI RMF
MEASURE 2.7-AI system security and resilience are evaluated and documented
OWASP LLM Top 10
LLM02:2025-Sensitive Information Disclosure

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

RAG pipelinesknowledge management platforms

MITRE ATLAS Techniques

AML.T0036Data from Information Repositories
AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

NIST AI RMF: MEASURE 2.7
OWASP LLM Top 10: LLM02:2025

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:N

Timeline

Published
August 13, 2026
Last Modified
October 29, 2026
First Seen
August 13, 2026

Related Vulnerabilities