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-20260726020813-a25c2dd06aae | 0.0.0-20260726020813-a25c2dd06aae |
Miggo AIRoot Cause AnalysisThe vulnerability exists because of a flawed authorization model for published content. The system uses an opt-out mechanism (publishAccess.json) to restrict access to notebooks. However, the encrypted notebook feature did not integrate with this system, meaning encrypted notebooks were never added to this deny list. The core authorization function, CheckPathAccessableByPublishIgnore, defaults to allowing access if a notebook is not explicitly listed, so it treated all encrypted notebooks as public.
The exploit chain begins when an attacker, as an anonymous or low-privileged user in publish mode, calls the lsNotebooks API endpoint. In the vulnerable version, this endpoint would return a list of all notebooks, including any encrypted ones that were currently unlocked by a legitimate user. With the encrypted notebook's ID, the attacker could then call listDocsByPath to enumerate all the document IDs within that notebook. Finally, the attacker would use the getDoc or getBlockKramdown API endpoints with a document ID to retrieve the full, decrypted content. At no point in this chain did the backend check if the target notebook was encrypted and therefore should be inaccessible to a publish-mode reader.
The patch addresses this by changing the logic to be 'fail-closed' for encrypted notebooks. It introduces checks in all relevant API endpoints (lsNotebooks, listDocsByPath, getDoc, getBlockKramdown, and many others) to explicitly deny access if the target is an encrypted notebook and the user is a publish reader. This is done by adding encrypted notebooks to the deny list dynamically in memory, ensuring they are always blocked from being published, regardless of the publishAccess.json configuration or their lock state.
lsNotebookskernel/api/notebook.go
listDocsByPathkernel/api/filetree.go
getDockernel/api/filetree.go
getBlockKramdownkernel/api/block.go
checkBlockTreeAccessableByPublishAccesskernel/model/publish_access.go
Neither core gate rejects them. On both eef105683 and v3.7.4-alpha.1:
func checkBlockTreeAccessableByPublishAccess(...) bool {
return CheckPathAccessableByPublishIgnore(bt.BoxID, bt.Path, publishIgnore) &&
(password == "" || CheckPublishAuthCookie(c, passwordID, password))
}
For an encrypted notebook the first term is true because it is unlisted, and the second is true because encrypted notebooks carry no publish password. The conjunction returns true.
IsEncryptedBox does not appear in kernel/model/publish_access.go at all on master. On the development branch it appears once, inside parseAttributeViewForPublishAccess, where it routes into encrypted boxes rather than excluding them. The publish authorization layer has no concept of an encrypted notebook.
The chain. Verified on the development branch, which is the harder target because the block-metadata, attribute-view, path-resolution and encrypted-notebook-status fixes have all landed there.
lsNotebooks calls ListNotebooks(), which includes encrypted notebooks and reports Encrypted: boxConf.Encrypted without filtering on it. The reader filter skips only notebooks that are Closed or publish-invisible. An unlocked encrypted notebook is neither, so it is returned to an anonymous reader together with its identifier.listDocsByPath{notebook: <encrypted box id>, path: "/"} applies only CheckPathAccessableByPublishIgnore, which passes, returning the document identifiers and titles inside the encrypted notebook.getDoc routes to GetDocInBox(...), after which FilterContentByPublishAccess(...) returns the content unmodified because the box is unlisted. The response is the fully decrypted document. getBlockKramdown reaches GetBlockKramdownInBox for the same result in Markdown.Handlers reach the decrypted store through encryptedNotebookFromArg(arg) on a client-supplied notebook argument. This function predates the current release and is not a recent addition.
The precondition is the unlock window. GetBlockTreeInBox returns nil while a notebook is locked, treating it as nonexistent, and non-nil once unlocked. So the exposure is bounded to the period during which the legitimate user has the notebook open, which is precisely the period in which they are working in it. No action by the attacker triggers or extends that window, but no unusual condition is required either.
On endpoints previously assessed as correctly gated. getBlockDOM and getBlockKramdown apply password and visibility checks. exportPreview applies FilterContentByPublishAccess. Those assessments are accurate and this report does not contradict them. The checks execute and return true, because the visibility term resolves to accessible for an unlisted box and the password term is vacuous for a notebook that has no publish password. Patching any individual handler would not change that result.
Precondition: publish mode enabled (default port 6808), anonymous when Publish.Auth.Enable is false, otherwise any publish reader account. An encrypted notebook that is currently unlocked by the legitimate user.
Step 1, obtain the encrypted notebook's identifier:
POST http://127.0.0.1:6808/api/notebook/lsNotebooks
{}
→ 200. The list includes the encrypted notebook, with encrypted: true and its id.
Step 2, enumerate its documents:
POST http://127.0.0.1:6808/api/filetree/listDocsByPath
{"notebook":"<encrypted box id>","path":"/"}
→ 200, document identifiers and titles from inside the encrypted notebook
Step 3, retrieve decrypted content:
POST http://127.0.0.1:6808/api/filetree/getDoc
{"id":"<document id from step 2>"}
→ 200, the fully decrypted document
getBlockKramdown returns the same content as decrypted Markdown. Repeating step 3 while the notebook is locked returns not-found, which confirms the unlock window is the only thing standing between an anonymous reader and the plaintext.
The confidentiality guarantee of the encrypted-notebook feature is defeated against a remote, unauthenticated attacker for as long as the notebook is unlocked. A user who encrypts a notebook is expressing that its contents should be protected beyond the ordinary publish boundary. The publish gate does not recognise that intent, and instead treats the notebook as publicly readable because nobody added it to an opt-out list that the encryption feature does not write to.
The exposure is full document content rather than metadata, and it applies to every document in the notebook. It requires no key material, no password, no offline work and no interaction with the encryption subsystem at all.
Fail closed on encryption, independently of publishAccess.json:
if IsEncryptedBox(bt.BoxID) {
return false
}
in both checkBlockTreeAccessableByPublishAccess and CheckBlockTreeMetadataAccessableByPublishAccess, and exclude encrypted notebooks from lsNotebooks and listDocsByPath for read-only roles.
The broader point is the default. An opt-out authorization list means every future notebook type, storage backend or content class is publicly accessible until somebody remembers to add it. Encrypted notebooks are the case where that default is most clearly wrong, but they are unlikely to be the only one.