SiYuan EUVD-2026-57454

The target SiYuan instance must be running in publish mode and be network-reachable by the attacker, and the /api/system/getConf endpoint must be accessible without authentication (the default behavior in vulnerable versions, per the description). Given the CVSS 4.0 vector (PR:N/UI:N/AC:L/AT:N), no credentials, user interaction, or special timing are required once those conditions hold. The principal limiting factor is deployment: instances that are not in publish mode, or that are not exposed to the attacker's network (e.g., localhost-only, VPN-gated, or behind an authenticating proxy), are not reachable via this path. Successful impersonation also assumes valid target accounts/sessions exist to forge cookies against.

The signals align toward genuine, high-priority risk: the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VC:H, SC:H, base 9.2) describes a network-reachable, low-complexity, unauthenticated attack whose disclosed secret produces a subsequent high-confidentiality impact, and the SSVC-style read is that technical impact is total account/workspace takeover once the key is known. The one meaningful gating factor is deployment posture - the endpoint is exploitable specifically when an instance is exposed in publish mode - so the effective population is smaller than the raw score implies. No EPSS value was supplied and the CVE is not in CISA KEV, and no POC was provided, so there is currently no evidence of active or automated exploitation; the near-trivial exploitation path (a single unauthenticated GET plus cookie forging) nonetheless means any operator running a publicly reachable publish-mode SiYuan node should treat patching as urgent rather than routine. In short, this is a real priority for exposed instances, not a high-CVSS-but-low-real-risk artifact, though its blast radius is bounded by how many SiYuan servers are actually internet-facing in publish mode.

An attacker discovers an internet-exposed SiYuan server running in publish mode, sends a single unauthenticated GET to /api/system/getConf, and reads the CookieKey value from the returned configuration. Using that signing key, the attacker forges a valid session cookie for an administrative account and connects as that user, gaining full control of the workspace. No exploit code has been published, but the technique requires only an HTTP client and standard cookie-signing logic.