SiYuan EUVD-2026-91420

Exploitation requires that the target SiYuan instance (before v3.8.5) has the publish/sharing feature enabled and exposes at least one publish-visible notebook. Full anonymous exploitation additionally requires that NO reader password is configured - when a reader password IS set, an attacker must first be a legitimate read-only publish reader, which limits exposure. The flaw is reached purely through the getNotebookInfo API endpoint; the limiting factors are therefore deployment of the publish mode and the reader-password configuration, while no user interaction, no privilege escalation, and no special platform are needed against a password-less published instance.

This is a genuine but modest-severity information-disclosure issue, not a high-urgency priority. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) shows a network-reachable, low-complexity, unauthenticated attack path, and the description confirms anonymous visitors can exploit it when no reader password is set - so the no-auth claim is consistent across both the vector (PR:N) and the narrative. However, impact is deliberately scoped low: VC:L with VI:N/VA:N, and the leaked data is only metadata (document count, size, modification timestamps) of hidden documents, not their contents. There is no EPSS score, no CISA KEV listing, and no public exploit referenced, so there is no evidence of active or widespread exploitation; this means the 6.9 score reflects easy reachability rather than severe consequence. Overall this is a low-real-risk, high-reachability bug: worth patching on exposed publish instances but not an emergency. One nuance to verify: exploitation is limited when a reader password is configured, which the raw PR:N vector does not capture.

An anonymous visitor browses a SiYuan publish instance that has no reader password set, then issues a request to the getNotebookInfo API endpoint against a publish-visible notebook. The response leaks document count, total size, and modification timestamps for documents the owner explicitly excluded from publishing, allowing the attacker to infer the existence and activity of hidden content. No public exploit code is identified at time of analysis, but exploitation requires only a single crafted API call with no authentication.