CVE-2026-73606

This CVE exposes a fundamental conceptual failure in how password protection boundaries were designed, not an isolated coding oversight. The core issue is that SiYuan's security model treats 'password-protected document' as an atomic unit, while the API architecture leaks relationship metadata that should be gated by that same protection. When `/api/block/getRefIDs` was added—presumably to support back-link discovery and graph view features—it was built against a data layer that correctly handles document-level authentication, but the API endpoint itself was never integrated into that auth flow. This is a decomposition failure: the security boundary was enforced at the data retrieval layer but not enforced at the API exposure layer, suggesting the threat model never addressed what metadata about protected content can be inferred through non-protected endpoints. The CVSS vector likely reflects confidentiality impact (block ID disclosure) but doesn't capture the architectural debt this represents. Block IDs in a knowledge graph aren't static lookup keys—they're navigation vectors and relationship anchors. An attacker who can enumerate block references across password-protected documents gains structural intelligence about what the target considers sensitive, what knowledge clusters together, and potentially which blocks are referenced across protection boundaries. This is a 'metadata side-channel' vulnerability: developers correctly protect primary content (the document body) but treat structural metadata—IDs, references, relationship graphs—as non-sensitive infrastructure. That categorization error has recurred across decades of web application vulnerabilities, from directory traversal revealing file existence to timing attacks revealing key structure. The question is whether this is a single missing `checkPasswordAccess()` call or evidence that the permission model was never coherently mapped across the API surface. If one endpoint missed this check, the pattern suggests others may too. The fix to this specific endpoint is trivial; the harder question is whether SiYuan will audit every other endpoint that enumerates, lists, or returns counts about protected resources. That's the real test—not whether one line was added, but whether the assumption that 'metadata about protected content isn't protected content' has been reconsidered.

Reviewed through automated stages and approved by a human before publication.