Mitigating PHP2Shell: Everything You Need to Know
Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| github.com/siyuan-note/siyuan/kernel | go | < 0.0.0-20260725123945-77421530be4a | 0.0.0-20260725123945-77421530be4a |
Miggo AIRoot Cause AnalysisThe vulnerability (CVE-2026-72794) in SiYuan allows for the disclosure of the session-cookie signing key (Conf.CookieKey) via the /api/system/getConf endpoint. The analysis of the provided commit 77421530be4ab1f43310d0f50fbab05d16c38675 clearly shows modifications to two key masking functions: model.GetMaskedConf and model.HideConfSecret in kernel/model/conf.go. Before the patch, these functions did not explicitly set CookieKey to an empty string, meaning the actual value was retained and returned. The getConf function, which is the handler for the /api/system/getConf route, relies on these masking functions to sanitize the configuration before returning it. Therefore, the getConf function is the direct point of exposure, while model.GetMaskedConf and model.HideConfSecret are the specific internal functions whose insufficient implementation directly led to the vulnerability by failing to mask the sensitive CookieKey. An attacker exploiting this would trigger the system.getConf function, which in turn would call the unpatched model.GetMaskedConf and model.HideConfSecret functions, resulting in the CookieKey being included in the API response.
system.getConfkernel/api/system.go
model.GetMaskedConfkernel/model/conf.go
model.HideConfSecretkernel/model/conf.go
VariablesCookieKeyFilterConfByPublishIgnore touches UILayout only.The key is live, not vestigial. It is passed straight into the session store at startup:
cli/cmd/serve.go:67 go server.Serve(false, model.Conf.CookieKey)
kernel/server/serve.go:152 sessionStore = cookie.NewStore([]byte(cookieKey))
kernel/server/serve.go:159 ginServer.Use(sessions.Sessions("siyuan", sessionStore))
gin-contrib/sessions/cookie.NewStore constructed with a single key uses that key as the gorilla/securecookie HMAC key. The siyuan session cookie is therefore signed with the value the endpoint hands out. An attacker holding it can mint and modify session cookies that the server accepts as authentic.
Guarded sibling, in the same file. exportConf (kernel/api/system.go:299) clones the configuration before returning it and explicitly clears both secrets:
kernel/api/system.go:360 clonedConf.CookieKey = ""
clonedConf.NotebookCrypto = nil
The project has already classified CookieKey as a value that must not leave the server. The getConf masking path omits the same field.
Ceiling is environment-dependent, floor is not. Escalating a forged session to administrator additionally requires the forged SessionData to carry the matching AccessAuthCode, which GetMaskedConf does mask or the instance to have no access-auth code configured, which is a common deployment. The unconditional impact, present on every instance, is the disclosure of a persistent cryptographic secret to an unauthenticated party together with the cookie-forgery capability that follows from it. Rotating the key invalidates all existing sessions, so this is not a secret that can be quietly refreshed.
Precondition: publish mode enabled (default port 6808); anonymous when Publish.Auth.Enable is false, otherwise any publish reader account.
POST http://127.0.0.1:6808/api/system/getConf
{}
→ 200
The response body's conf object contains a cookieKey field holding the
server's session-signing key in cleartext.
Differential check against the endpoint that does strip it:
POST http://127.0.0.1:6808/api/system/exportConf
→ cookieKey is empty, notebookCrypto is null
The same value is withheld by one endpoint and returned by the other.
An anonymous reader in publish mode or any publish RoleReader obtains the server's session-cookie signing key. This is a persistent cryptographic secret whose disclosure cannot be remediated without invalidating every active session. Possession of the key permits forging and tampering with siyuan session cookies that the server will validate as authentic. On instances with no access-auth code configured, or where a forged session's contents otherwise satisfy the server's checks, this extends to authenticating as a privileged user.
Clear CookieKey in HideConfSecret for all non-administrator responses. The more durable fix is to route non-administrator getConf through the exportConf cloner, which already handles CookieKey, NotebookCrypto, Account, Stat, System.ID, Export.PandocBin and the AI keys replacing the current blocklist, which fails open on every field nobody thought to add, with the allowlist-style cloner the project already maintains.