SiYuan CVE-2026-105205

Exploitation requires the SiYuan instance to be running in publish mode with at least one published document, and that published document must be the target of backlinks/references from documents that are password-protected or have publishing disabled. The attacker must know or enumerate a valid published document ID, then invoke /api/block/getDocInfo or /api/block/getDocsInfo against it. Limiting factors: only metadata (refIDs and refCount of hidden referencing blocks) is exposed, not the protected document content; the instance must actually be deployed in publish mode (not local-only use); and the flaw is fixed in SiYuan 3.8.5, so patched or pre-publish deployments are not affected.

This is a genuine but modest-severity confidentiality issue, not a critical priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N) scoring 6.9 correctly reflects a remotely reachable, low-complexity, unauthenticated flaw with only LOW confidentiality impact and no integrity or availability impact. PR:N is credible here because SiYuan's publish mode is intentionally exposed to anonymous readers, so the 'unauthenticated' characterization aligns with the documented attack surface. However, the real-world risk is bounded by what actually leaks: only backlink block IDs (refIDs) and reference counts of hidden referencing blocks - metadata, not the protected document contents themselves. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so there is no signal of active or widespread exploitation; this places it as a credible-but-not-urgent issue. The signals are internally consistent (no conflict between the network vector and the described remote API abuse), so the primary caveat is simply that exploitation yields limited metadata disclosure rather than full content compromise.

An anonymous reader of a SiYuan site running in publish mode identifies the internal ID of a published document, then sends a crafted POST request to /api/block/getDocInfo or /api/block/getDocsInfo for that ID. The response leaks the refIDs and reference counts of blocks in password-protected or publish-disabled documents that link to it, letting the attacker infer the existence, structure, and linkage of content that was meant to remain hidden. No public exploit code was identified in the input, but the attack requires only standard HTTP requests against the network-facing publish API (AV:N/AC:L).