CVE-2026-72794: Cryptographic Key Leakage and Session Forgery in SiYuan

SiYuan is an open-source personal knowledge management system. In default configurations, it exposes a local API server for managing notebooks, configuration settings, and data synchronization. The core application logic runs on a Go-based kernel, which routes internal and external administrative requests through a set of API endpoints.

The /api/system/getConf endpoint handles requests to retrieve the current application configuration. This endpoint is exposed to the network to allow clients to query user interface, language, and system configuration data. However, the endpoint is only protected by a general authentication check middleware (CheckAuth) which does not validate whether the requesting identity possesses administrative privileges.

Under specific system states, such as when the application operates in publish mode with public access allowed, unauthenticated users can access this endpoint. Furthermore, users with read-only roles (RoleReader) can successfully query the endpoint, exposing internal state variables. The lack of access-control differentiation represents the primary architectural exposure vector.

The root cause of CVE-2026-72794 lies in the failure to sanitize the AppConf.CookieKey struct field before serializing the configuration object into JSON. When a client queries /api/system/getConf, the handler calls GetMaskedConf() to filter sensitive attributes. The sanitization logic was implemented via a negative control list (blocklist) rather than a strict positive control list (allowlist).

In versions prior to v3.7.4, the sanitization chain included GetMaskedConf, HideConfSecret, and FilterConfByPublishIgnore. While these routines successfully masked high-profile fields like UserData, MCPOAuth, and specific credentials within AI and Repo configurations, they omitted CookieKey. Consequently, the raw bytes or string value of the cookie-signing key remained populated in the internal configuration struct.

When the Go struct is serialized to JSON using the default standard library encoder, the field CookieKey is transformed into cookieKey and transmitted over the network. This design flaw relies on client-side masking to hide details in the browser interface, failing to recognize that raw network payloads remain completely visible to any user or tool intercepting the JSON response.

To understand the structural flaw, we analyze the path of the configuration model serialization. The application initialization configures cookie session storage using CookieKey as the cryptographic HMAC signing secret. The session store configuration process uses the following sequence to assign the key:

Below is the comparative diff showing the vulnerable logic versus the patched implementation in kernel/model/conf.go. The patch directly intercepts the initialization and sanitization functions to strip CookieKey from the returned structure before serialization:

File: kernel/model/conf.go
@@ -1239,6 +1239,7 @@ func GetMaskedConf() (ret *AppConf, err error) {
 
 	ret.UserData = MaskedUserData
 	ret.MCPOAuth = ""
+	ret.CookieKey = ""
 	if "" != ret.AccessAuthCode {
 		ret.AccessAuthCode = MaskedAccessAuthCode
 	}
@@ -1250,6 +1251,7 @@ func GetMaskedConf() (ret *AppConf, err error) {
 func HideConfSecret(c *AppConf) {
 	c.AI = &conf.AI{}
 	c.MCPOAuth = ""
+	c.CookieKey = ""
 	c.Api = &conf.API{}
 	c.Flashcard = &conf.Flashcard{}
 	c.ServerAddrs = []string{}

The regression testing suite introduced in kernel/model/conf_secret_test.go verifies the state integrity of the patch. The test asserts that calling GetMaskedConf() strips the CookieKey while ensuring the live runtime configuration structure retains the legitimate key for session validation. This ensures that the configuration state is not permanently corrupted in memory while serving API requests.

An attacker exploits this vulnerability by sending a standard HTTP POST request to the /api/system/getConf endpoint. Because the application processes JSON inputs, the request body needs only to be an empty JSON object {}. The server processes the request, evaluates the authorization context, and returns a JSON payload containing the unmasked cookieKey attribute in plain text.

After extracting the cookieKey, the attacker can forge administrative session cookies. The SiYuan application uses the standard gorilla/securecookie codec via the Gonic session middleware. A forged session cookie requires the attacker to use the leaked HMAC key to sign custom session values. This allows the attacker to craft a cookie named siyuan containing authenticated session indicators.

Once the signed cookie is constructed, the attacker injects the cookie into their browser or HTTP client. When the server receives requests with the forged cookie, the cryptographic signature is validated against the known CookieKey. Because the signature matches, the server accepts the request as authenticated, granting the attacker the privileges associated with the forged identity.

The security impact of a leaked cryptographic session key is classified as High. An attacker who can forge sessions bypasses the fundamental authentication controls of the application. If the target instance is deployed with default configurations or lacks an access authentication code (AccessAuthCode), the attacker immediately obtains full administrative access to the notebook server.

A successful administrative compromise allows the attacker to read, modify, or delete all stored markdown notes, database content, and synchronized assets. This completely undermines the confidentiality and integrity of the user's data. Furthermore, depending on the environment, administrative access to the kernel API can lead to remote code execution through the abuse of system execution features or local path write capabilities.

The CVSS v3.1 score is evaluated at 8.6, representing high severity. The attack vector is Network, complexity is Low, and no privileges are required under publish mode configuration. The impact on confidentiality is high, whereas integrity and availability impacts depend on secondary access controls and configuration parameters.

The definitive solution to mitigate CVE-2026-72794 is to upgrade the SiYuan application to version 3.7.4 or later. This version implements explicit sanitization of the CookieKey field prior to serialization in the /api/system/getConf endpoint. Upgrading guarantees that unauthenticated queries and read-only users cannot access the cryptographic secret.

Merely updating the application software is insufficient if the key was historically exposed. System administrators must rotate the CookieKey stored within the configuration files (such as conf.json or within environment configurations). Generating a new random cryptographic secret invalidates any previously leaked keys and terminates all active sessions, forcing a secure state reset.

Organizations should also implement perimeter defense strategies. Restricting direct access to administrative ports via firewalls or reverse proxy access control lists limits the exposure of internal APIs. Additionally, ensuring that publish-mode authorization (Publish.Auth.Enable) is configured to require authentication reduces the surface area available to anonymous remote attackers.