SiYuan CVE-2026-73608

Requires that the target run a SiYuan build from the development branch containing commit 9b8e8956f (stable releases including v3.7.3, master, and v3.7.4 are not exploitable), that the SiYuan publish feature be in use so a page is anonymously reachable, and that the attacker obtain a valid attribute-view/database identifier - which is exposed via the published page itself. No authentication is required (PR:N) and no user interaction is needed (UI:N). The key limiting factor is the affected-version constraint: only self-built, network-exposed dev-branch instances with published content are at risk, which is why fleet-wide exposure is minimal despite the unauthenticated, low-complexity nature of the request.

The CVSS 4.0 base score of 9.2 reflects a network-reachable, low-complexity, unauthenticated read (AV:N/AC:L/PR:N/UI:N) with high confidentiality impact on a subsequent system (VC:H/SC:H) and no integrity or availability impact - an information-disclosure issue, not code execution. The single most important mitigating signal is that only the unreleased development branch is affected: no stable release ever shipped the vulnerable route, EPSS is effectively not meaningful here, there is no KEV listing, and no public PoC is identified, so the practical attack surface is limited to operators who deliberately build and expose dev-branch SiYuan with published pages enabled. For anyone actually running such a build the flaw is genuinely serious and trivially exploitable, so it should be patched to v3.7.4 promptly; for the overwhelming majority of SiYuan users on stable releases, real-world risk is negligible. Note the tension worth stating explicitly: the high CVSS is driven by the CVSS vector alone, while the description confirms exposure is confined to development builds - a case where raw score overstates fleet-wide priority.

An operator runs a dev-branch SiYuan instance with a publicly published page that references an attribute-view database. An anonymous visitor reads the database identifier exposed on the published page, then sends a request to /api/av/getAttributeViewSearchTarget with that ID and a keyword, and receives back matching database rows - including unpublished rows the publish filter was meant to withhold. No exploit code is publicly known at time of analysis; exploitation is straightforward given the low attack complexity and lack of authentication.