SiYuan CVE-2026-74799

The SiYuan process must be running with its runtime --mode flag NOT set to exactly the string 'prod' (including the default case where the flag is omitted), which causes the net/http/pprof handlers to be registered, and the HTTP listener must be reachable by the attacker (bound to a non-loopback interface or exposed via a proxy). No authentication, credentials, or user interaction are needed against such an instance (CVSS PR:N/UI:N). Limiting factors: an instance explicitly launched with --mode=prod is not vulnerable, and deployments bound only to localhost or behind a proxy that blocks /debug/pprof are not remotely exploitable; successful secret theft also requires the target secrets (AccessAuthCode, AI API keys) to be present in process memory at dump time.

The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VC:H, VA:L, SC:H/SA:L, score 9.2) describes a remote, low-complexity, unauthenticated read of high-value confidentiality data, with the subsequent-system metrics reflecting that stolen AI API keys and the AccessAuthCode enable follow-on compromise of other systems and the SiYuan instance. The dependence on runtime mode is the main mitigating nuance, but because the vulnerable state is the default (anything other than an explicit --mode=prod), real-world exposure is broad for any instance bound to a reachable interface. No EPSS score was supplied and the CVE is not in CISA KEV, so there is no evidence of active exploitation, and no public POC is referenced, so it is not confirmed weaponized. The gap between a critical CVSS and the absent exploitation/EPSS signals indicates the score is driven by ease of access and secret sensitivity rather than observed attacks-still a genuine high priority for internet-exposed deployments given trivial exploitability, but lower urgency for instances bound to localhost.

An attacker who can reach a SiYuan instance's HTTP port (started without --mode=prod, e.g. a home lab or small-team server exposed to a LAN or the internet) sends an unauthenticated GET to /debug/pprof/heap and downloads the heap profile. They parse the returned memory dump offline to extract the AccessAuthCode and AI provider API keys, then use those keys to access the workspace or pivot into the linked AI accounts. No authentication, user interaction, or special tooling beyond a profile parser is required; no public POC is referenced at this time.