CVE-2026-72793 exposes a fundamental design flaw in SiYuan's API architecture: the /api/system/getConf endpoint returns security-critical secrets — including the session-cookie signing key, notebook encryption material, and the OS username via pandoc path — to anonymous users and the limited 'publish-reader' role. This isn't a cryptographic failure; it's a failure to apply least privilege to internal API contracts. The signing key should never be retrievable by ANY role, even admin. It belongs in process memory only, with no export path.
The vulnerability creates three independent attack paths. Possession of the signing key enables session cookie forgery, allowing horizontal or vertical privilege escalation to administrator. The notebook encryption material potentially exposes user data at rest. The OS username leak enables reconnaissance for local privilege escalation or lateral movement on the host. A single unauthenticated API call opens three failure cascades simultaneously.
This endpoint likely originated as a debugging artifact before authentication existed in SiYuan. Over time, as the session system, notebook encryption, and pandoc integration were added, developers incrementally dumped new configuration into this 'dump everything' endpoint without a security review of what should be visible. The mental model calcified — it was the debug endpoint, adding to it felt routine. The fix in version 3.7.4 added masking to sensitive fields, suggesting someone audited what needed hiding, but the core architectural problem persists: secrets stored in configuration rather than a dedicated secrets vault.
For defenders: verify that /api/system/getConf now requires authentication and returns masked values for any field used in cryptographic operations. If self-hosted, treat this as near-maximum severity — any visitor can forge administrator sessions. Search for similar unauthenticated configuration-dump endpoints in your stack; they're a common forgotten code path that accumulates secrets silently. The institutional fix isn't just patching this endpoint — it's establishing periodic review of what existing APIs return, or you'll ship the next feature and create a fourth blast radius.