Threats tagged 'go'

SiYuan before version 3.7.4 contains an access control bypass vulnerability where static-file routes bypass the publish-access controls enforced on the REST API. This allows attackers with publish reader tokens or anonymous access in disabled-auth mode to read templates, snippets, and export artifacts by directly accessing static routes that lack the same restrictions as the REST API. The advisory is a duplicate and has been withdrawn in favor of GHSA-fgmr-7w36-9qfq. No patch links are provided in this data.

Siyuan versions up to 3.7.2 expose the session cookie signing key via the /api/system/getConf endpoint to unauthenticated users in publish mode. This exposure allows attackers to retrieve the CookieKey and forge valid session cookies, potentially impersonating users or gaining administrative access. The vulnerability is classified as critical with a CVSS score of 8.6. This advisory is a duplicate of GHSA-34fj-mwm6-fjfg and has been withdrawn to preserve external references.

SiYuan versions up to 3.7.2 have a vulnerability where embedded block content is returned without proper publish-access filtering. This allows unauthorized anonymous users to access private and password-protected document content via specific API endpoints. The advisory is a duplicate and references GHSA-h6w7-xxcf-w2mq for the original report.

SiYuan versions up to 3.7.3 have a vulnerability in the /api/system/getConf endpoint where sensitive configuration fields are not properly masked for non-administrator users. This allows anonymous or publish-reader users to access secrets including the session-cookie signing key, OS username via the pandoc path, and encrypted-notebook key material. Exploitation can enable attackers to forge session cookies and impersonate users, potentially escalating to administrator privileges on instances without access-auth codes.

SiYuan before version 3.7.4 has an information disclosure vulnerability where the /api/tag/getTag endpoint returns tag labels and occurrence counts from password-protected documents to unauthenticated users. This allows attackers to enumerate tag vocabulary and internal terminology without entering the document's password. The advisory is a duplicate and has been withdrawn in favor of GHSA-mp7r-57w4-5qm3. The vulnerability has a medium severity rating with a CVSS score of 5.8.

SiYuan versions up to 3.7.2 have a vulnerability that exposes encrypted-notebook key-derivation material and wrapped notebook keys through unauthenticated endpoints in publish mode. This exposure allows attackers to obtain Argon2id parameters and wrapped keys, enabling unlimited offline cracking of the master password without rate limiting. The vulnerability has a high severity score of 7.5 and affects confidentiality but not integrity or availability.

SiYuan versions before v3.7.4 have a vulnerability where the getAttributeViewKeysByID endpoint does not apply publish-access filtering, allowing authenticated readers to access complete database column schemas. Additionally, two endpoints, getBlockDefIDsByRefText and getBlockRelevantIDs, enumerate workspace-wide block IDs without publish scoping, potentially exposing identifiers from hidden or password-protected documents. This advisory is a duplicate and has been withdrawn in favor of GHSA-5fhr-f75j-8wr9.

**CVE:** This vulnerability corresponds to [CVE-2026-72809](https://nvd.nist.gov/vuln/detail/CVE-2026-72809). ### Summary The kernel's `CheckAuth` grants `RoleAdministrator` to any request whose `RemoteAddr` is loopback (`127.0.0.1`), for a specific set of endpoints, and these localhost bypasses sit **outside** the `accessAuthCode` gate so they apply even when an access auth code is configured. This is demonstrated live (Part A below). Separately, the fixed-port reverse proxy (`fixedport.go`) forwards requests to the kernel over loopback and injects no authentication token, and no `SetTrustedProxies` is configured, so gin does not derive the client address from forwarding headers. By code inspection, a request forwarded through this proxy would reach the kernel with `RemoteAddr = 127.0.0.1`. **If** the fixed-port proxy is bound to a network interface (via `NetworkServe`) and forwards remote requests to the kernel this way, the localhost bypass would grant a remote unauthenticated caller admin on those endpoints. This second step is established by reading the code but was **not reproduced end-to-end**, and I'm asking the maintainer to confirm the proxy's runtime forwarding behavior (Part B below). ### Details **Localhost-trust admin bypass (proven).** `CheckAuth` (`session.go:298-321`) contains localhost-only bypasses that key off `RemoteAddr` and grant `RoleAdministrator`. They sit outside the `accessAuthCode` gate i.e. they apply even when an access auth code is set and cover `/api/system/exit`, `getNetwork`, `getWorkspaceInfo`, `/assets/*`, and `/export/*`. **Fixed-port proxy behavior (code inspection).** `fixedport.go` is a plain reverse proxy that dials the kernel at `127.0.0.1` and injects no token unlike the publish proxy, which injects a `RoleReader` JWT. There is no `SetTrustedProxies` call, so gin does not rewrite `RemoteAddr` from `X-Forwarded-For`. On this reading, a request forwarded through the fixed-port proxy reaches the kernel with `RemoteAddr = 127.0.0.1`. **The composition (conditional).** If both hold at runtime, then: remote request → fixed-port proxy on a network interface → forwarded to kernel at `127.0.0.1` (no token) → kernel sees `RemoteAddr = 127.0.0.1` → localhost bypass grants admin for the endpoints above. I have proven the final link (localhost → admin) and read the code for the forwarding link, but have not confirmed at runtime that the fixed-port proxy is instantiated and forwards remote requests as loopback in a shipped configuration. **Distinct from the previously-dismissed localhost→admin observation.** That observation concerned the *publish* proxy path, where the injected `RoleReader` JWT causes `CheckAuth` to early-return before reaching the localhost bypasses. The fixed-port proxy injects no token, so a request through it would fall through to the `RemoteAddr`-keyed bypass instead. Different proxy, different code path. ### Proof of Concept **Part A: the localhost bypass grants admin without auth, outside the auth-code gate (demonstrated live).** On a local instance with an access auth code configured, the same no-token `getWorkspaceInfo` request returns different results depending on the source address the kernel sees: - From a non-loopback source (kernel sees a non-127.0.0.1 address): `HTTP 401`. - From `127.0.0.1` (kernel sees loopback): `{"code":0,"data":{"workspaceDir":"/siyuan/workspace",…}}` admin data, no auth, despite `accessAuthCode` being set. This confirms the localhost-trust bypass grants admin for these endpoints and is not gated by the access auth code. **Part B: remote → proxy → loopback (code inspection only; NOT reproduced).** By reading `fixedport.go`, the proxy dials `127.0.0.1`, injects no token, and no `SetTrustedProxies` is set. I was not able to reproduce this end-to-end: the `serve` CLI in the container image tested exposes only `--port` and `--accessAuthCode`, not a flag that instantiates the fixed-port proxy in the `NetworkServe`-on-a-non-default-port shape, so the remote→proxy→loopback chain was not exercised at runtime. I did not invoke the destructive `/api/system/exit` endpoint. **I'm asking the maintainer to confirm: under what conditions is the fixed-port proxy instantiated, does it bind a non-loopback interface under `NetworkServe`, and does it forward to the kernel preserving the client address or as loopback?** That determines whether Part A's bypass is remotely reachable. ### Impact **Confirmed (Part A):** on any deployment where a caller can cause the kernel to see a loopback `RemoteAddr`, the endpoints `/api/system/exit`, `getNetwork`, `getWorkspaceInfo`, `/assets/*`, and `/export/*` are reachable with admin rights without the access auth code i.e. the auth code does not protect these endpoints against a loopback-sourced caller. On its own this is a local/adjacent bypass of the access-code control for those endpoints. If the fixed-port proxy forwards remote requests to the kernel as loopback (to be confirmed by the ma

**CVE:** This vulnerability corresponds to [CVE-2026-72808](https://nvd.nist.gov/vuln/detail/CVE-2026-72808). ### Summary The `/api/asset/getFileAnnotation` endpoint returns the content of `.sya` PDF-annotation files with no publish-access check. It is gated by `CheckAuth` only, so it is reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. Its sibling, the `/assets/*` asset route does enforce publish access, including the publish password. An anonymous reader who knows an asset path can therefore read the private PDF annotations (highlights, notes) attached to assets in publish-forbidden, password-protected, or unpublished documents. ### Details `getFileAnnotation` resolves the annotation file via `GetAssetAbsPathInBox` (no path traversal) and returns the `.sya` content. Unlike the `/assets/*` route, which applies the publish-access filter including password enforcement before serving asset bytes, `getFileAnnotation` applies no publish-access, publish-ignore, or password check. The guarded-sibling asymmetry indicates the boundary is meant to apply to this data and was omitted here. `.sya` files for encrypted-box assets are fail-closed and not exposed. The gap is limited to non-encrypted assets. **Route / auth tier.** `getFileAnnotation` is registered `CheckAuth`-only. `CheckAuth` admits `RoleReader`; the publish proxy forwards port-6808 traffic with a Reader JWT (anonymous when publish auth is disabled). ### Proof of Concept Reproduced on a local instance (publish mode on 6808, Basic Auth off). **Setup (admin, 6806):** 1. `createNotebook{name:"AnnotPoc"}` → box 2. `createDocWithMd{notebook, path:"/annot-victim", markdown:"doc with a pdf"}` → doc 3. `POST /api/asset/upload` (multipart `id=<doc>`, `file[]=@secret.pdf`) → `assets/secret-...pdf` 4. `setFileAnnotation{path:"<asset>.sya", data:"{annotSecret:ANNOT_SECRET_4471,note:private highlight}"}` 5. `setPublishAccess{id:<doc>, visible:false, password:"", disable:true}` → doc forbidden **Exploit (anonymous reader, 6808, no token):** ``` POST http://127.0.0.1:6808/api/asset/getFileAnnotation {"path":"assets/secret-...pdf.sya"} ``` Returns: ``` {"code":0,"data":{"data":"{\"annotSecret\":\"ANNOT_SECRET_4471\",\"note\":\"private highlight\"}"}} ``` The annotation content of a publish-forbidden document is returned to an anonymous reader with no publish-access check, while the `/assets/*` route serving the same asset class enforces publish access and password. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read the private PDF annotations (highlights and notes) of assets belonging to publish-forbidden, password-protected, or unpublished documents, given the asset path. This defeats the publish-access/password boundary for annotation data. Scope is limited to annotated PDFs in non-encrypted notebooks; encrypted-box annotations are not exposed. Confidentiality-only. ### Suggested fix Apply the same publish-access check the `/assets/*` route uses to `getFileAnnotation` resolve the asset's owning document and enforce the publish-access/publish-ignore / password check before returning `.sya` content.

**CVE:** This vulnerability corresponds to [CVE-2026-72807](https://nvd.nist.gov/vuln/detail/CVE-2026-72807). ### Summary Attribute-view (AV) template columns are live-evaluated on every render and expose the `queryBlocks` template function, which runs raw SQL on the read-write database handle (`SelectBlocksRawStmt`, using `?`→argument string substitution rather than parameter binding). AV mutations are admin-gated, so this is not directly reader-injectable but it is a second-order vector: an attacker distributes a SiYuan document or AV package whose template column contains `.action{queryBlocks "<arbitrary SQL>"}` when a victim imports the package and renders the AV, the attacker's SQL executes on the victim's kernel (read and, via statement stacking, write). ### Details Doc-level `{{…}}` templates are rendered at insert-time and become static, so they are not re-evaluated on reader view. The residual is AV template columns, which are live-evaluated at render. `queryBlocks` passes its argument to `SelectBlocksRawStmt` with `?`→arg string substitution, not a bound parameter, on the main read-write handle (`88250/go-sqlite3` fork, statement-stacking capable) so an attacker-controlled template argument becomes arbitrary SQL. The SSTI surface is otherwise hardened: `BuiltInTemplateFuncs` deletes `env`, `expandenv`, and `getHostByName` so there is no environment/host/file/exec SSTI. `queryBlocks`-to-SQL is the remaining live-evaluated sink. ### Proof of Concept An AV template column set to `.action{queryBlocks "<sql>"}` executes `<sql>` against the read-write handle when the AV is rendered. Delivered second-order: a shared/imported document or AV package carrying such a column runs the embedded SQL on any kernel that imports and renders it. ### Proof of Concept Reproduced on a live instance. **1. Host doc + AV (admin, 6806):** ``` POST /api/filetree/createDocWithMd {notebook, path:"/ssti-poc", markdown:"host"} → DOC POST /api/av/renderAttributeView {id:"<AV>"} # materializes the AV ``` **2. Plant the malicious template column (one performTransactions call):** ```json {"reqId":1,"session":"poc","transactions":[{"doOperations":[ {"action":"addAttrViewCol","avID":"<AV>","id":"<COL>","name":"tpl","type":"template"}, {"action":"updateAttrViewColTemplate","avID":"<AV>","id":"<COL>","type":"template", "data":".action{range queryBlocks \"SELECT * FROM blocks WHERE root_id='<PROTECTED_DOC_ID>'\"}.action{.Markdown} .action{end}"}, {"action":"insertAttrViewBlock","avID":"<AV>","isDetached":true} ]}]} ``` **3. Trigger (render evaluates the template):** ``` POST /api/av/renderAttributeView {id:"<AV>"} ``` Result: the template cell renders `## LockedSection TOP_SECRET…` the `queryBlocks` SQL executed and returned the password-protected document's content, arbitrary SQL via template reading across the publish/password boundary. `queryBlocks` uses `?`→arg string substitution (not parameterized), so UNION and stacked writes are also possible. Delivered second-order, the same column executes on any kernel that imports and renders the AV. ### Impact An attacker who gets a victim to import a crafted document/AV package and render it achieves arbitrary SQL execution on the victim's kernel cross-notebook read and via stacking, write. Precondition is content delivery plus render (import of an attacker-supplied package), which bounds severity to Medium. Not directly reachable by an anonymous reader (AV creation is admin-gated); the injection travels in stored/imported template content. ### Suggested fix Parameterize `queryBlocks` bind the argument rather than substituting it into the SQL string or restrict the template function set available in AV columns as was done for the doc-template functions. Treat imported template content as untrusted at render time.

**CVE:** This vulnerability corresponds to [CVE-2026-72806](https://nvd.nist.gov/vuln/detail/CVE-2026-72806). ### Summary `FilterViewByPublishAccess`, the filter `renderAttributeView` applies for Reader sessions drops rows using only the hidden/forbidden check and never checks the publish password. Its three sibling filters all check both tiers. As a result, a publish `RoleReader` (or the anonymous account when `Publish.Auth.Enable` is `false`) who has not entered a document's password still receives every database/attribute-view row bound to that password-protected document, the primary cell (title/ID) and all column values. ### Details `FilterViewByPublishAccess` (`model/publish_access.go:290`) drops rows on the hidden/forbidden tier only: ```go // Table (line 311), Gallery (348), Kanban (385), all identical: if !CheckPathAccessableByPublishIgnore(bt.BoxID, bt.Path, publishIgnore) { row = nil // hidden/forbidden dropped, but password NEVER checked } ``` The three sibling filters all check both the hidden/forbidden tier and the password tier (`password == "" || CheckPublishAuthCookie(...)`): - `FilterBlockAttributeViewKeysByPublishAccess` (line 412) - `FilterBlockInfoByPublishAccess` (line 457) - `FilterContentByPublishAccess` (line 474) So the password (protected) tier is enforced everywhere except this AV/database-view filter. Table layout masks nothing; Gallery and Kanban mask only the cover, keeping the card and its non-cover values. Reachable via `renderAttributeView`, `getAttributeViewKeys`, and `renderSnapshotAttributeView`, all `CheckAuth`-only. ### Proof of Concept Reproduced on a live instance (publish mode on 6808, anonymous Reader, no password cookie), against a password-protected document with a database/AV row. | Check | Path | Result | |---|---|---| | Control | `getDoc(secretDoc)` | 🔒 placeholder, body withheld password gate works normally | | Test | `renderAttributeView(AV)` | row leaked : `blockID=…rk7jofz`, title `secret-db-row` | | Differential (`disable=true`) | same filter | 0 rows : hidden tier correctly enforced | | Differential (password set) | same filter | 1 row : password tier bypassed | Same filter, same document, same Reader: the hidden tier drops the row, the password tier leaks it isolating the omission. ### Impact An anonymous/Reader publish user who has not supplied a protected document's password receives all attribute-view/database rows bound to that document titles, block IDs, and column values defeating the publish-password control for database views. Confidentiality-only. The hidden/forbidden tier is unaffected (correctly enforced). ### Suggested fix Add the password check to the drop condition in all three layout branches (Table, Gallery, Kanban), mirroring the sibling filters: ```go if !CheckPathAccessableByPublishIgnore(...) || !(password == "" || CheckPublishAuthCookie(c, passwordID, password)) { row = nil } ```

**CVE:** This vulnerability corresponds to [CVE-2026-72805](https://nvd.nist.gov/vuln/detail/CVE-2026-72805). ### Summary Three block endpoints return document content snippets and metadata without any publish-access check, while their sibling `getBlockInfo` which returns comparable data does enforce one. All three are `CheckAuth`-only, so they are reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. An anonymous reader supplying a block ID receives content and metadata belonging to publish-forbidden and password-protected documents. ### Details `getBlockInfo` (`kernel/api/block.go`) gates on the publish boundary: ```go if !checkBlockPublishAccess(c, id, ret) { return } ``` The following siblings in the same file perform no equivalent check: | Endpoint | Returns | Publish check | |---|---|---| | `getBlockInfo` | root/title/path metadata | `checkBlockPublishAccess`: present | | `getBlockBreadcrumb` | `BlockPath.Name` : root document title plus every ancestor block's content snippet | none | | `getRefText` | the block's reference/anchor text (document content) | none | | `getBlockTreeInfos` | root/title/path metadata for arbitrary block IDs | none | `getBlockBreadcrumb` returns the full ancestor chain including each ancestor block's content snippet, and `getRefText` returns block anchor text both are document content, not just metadata. `getBlockTreeInfos` returns root/title/path for any caller-supplied ID set via `model.GetBlockTreeInfosInBox(...)` with no gate. `getBlockBreadcrumb` and `getRefText` additionally accept a client-supplied notebook argument that routes to the `*InBox` variants, so the same unguarded path applies to encrypted-notebook reads while the notebook is unlocked. The correct primitive already exists in the codebase and is used by `getBlockInfo`; these three handlers simply do not call it. ### Proof of Concept Precondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. A document `D` is marked publish-forbidden (or password-protected) and contains a block `BLOCK_ID` under a heading with distinctive content. **Control: the gated sibling correctly refuses:** ``` POST http://127.0.0.1:6808/api/block/getBlockInfo {"id":"BLOCK_ID"} ``` Blocked by `checkBlockPublishAccess`. **Disclosure: the ungated siblings return the data anyway:** ``` POST http://127.0.0.1:6808/api/block/getBlockBreadcrumb {"id":"BLOCK_ID"} → ancestor chain including the forbidden document's title and ancestor block content snippets POST http://127.0.0.1:6808/api/block/getRefText {"id":"BLOCK_ID"} → the block's reference/anchor text (content of the forbidden document) POST http://127.0.0.1:6808/api/block/getBlockTreeInfos {"ids":["BLOCK_ID"]} → root ID, title, and path for the forbidden document ``` Verified by code inspection at `origin/master` (`eef10568`): `getBlockInfo` contains the `checkBlockPublishAccess` call; `getBlockBreadcrumb`, `getRefText`, and `getBlockTreeInfos` contain no publish-access, publish-ignore, or readonly-role check in their bodies. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read, for documents explicitly excluded from publishing or protected by a publish password: - the document title and full ancestor chain, including ancestor block content snippets (`getBlockBreadcrumb`); - block reference/anchor text, i.e. document content (`getRefText`); - root ID, title, and path metadata for arbitrary block IDs (`getBlockTreeInfos`). Because `getBlockBreadcrumb` and `getRefText` accept a notebook argument routing to the `*InBox` variants, the same disclosure applies to encrypted notebooks while unlocked. Confidentiality-only; the precondition is a block ID, obtainable from other reader-reachable endpoints. ### Suggested fix Call `checkBlockPublishAccess` (as `getBlockInfo` does) in `getBlockBreadcrumb`, `getRefText`, and `getBlockTreeInfos` before returning data for `getBlockTreeInfos`, apply it per ID and drop unauthorized entries. Confirm the `*InBox` variants (`GetBlockRefTextInBox`, `BuildBlockBreadcrumbInBox`) enforce the same boundary so the notebook-argument path is covered.

**CVE:** This vulnerability corresponds to [CVE-2026-72804](https://nvd.nist.gov/vuln/detail/CVE-2026-72804). ### Summary `getGraph` and `getLocalGraph` filter reader sessions against the *visibility* tier only and never check the publish password. Password-protected documents are `Visible = true`, so their graph nodes survive the filter and graph nodes are block-level and carry the block's actual content. An anonymous reader who has never supplied a document's password can therefore retrieve that document's per-block content and its reference/backlink topology. Both endpoints are `CheckAuth`-only, so they are reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. ### Details Both handlers filter with the invisible-tier set only: ```go publishIgnore := model.GetInvisiblePublishAccess(publishAccess) // Visible tier ONLY nodes, links = model.FilterGraphByPublishIgnore(publishIgnore, nodes, links) ``` `FilterGraphByPublishIgnore` (`kernel/model/publish_access.go:849`) drops a node only when `!CheckPathAccessableByPublishIgnore(node.Box, node.Path, publishIgnore)`. There is no password evaluation anywhere in the graph code grepping `graph.go` for `CheckPublishAuthCookie` or `password` returns nothing. Because password-protected documents are `Visible = true`, their nodes pass the filter unchanged. **The nodes carry content, not just titles.** `genTreeNodes` emits one node per block, and `nodeTitleLabel` sets `node.Title = node.Label = block.Content` (`kernel/model/graph.go:673-678`). So each surviving node exposes the block's text. This is materially broader than the by-design listing behaviour: `listDocsByPath` intentionally exposes protected document *titles* (protected means "publicly visible, password required to access"), but the graph endpoints expose per-block *content* and the full link/reference topology, which listing never does. Verified at `origin/master`: `FilterGraphByPublishIgnore` contains only the `CheckPathAccessableByPublishIgnore` call; `graph.go` contains no password check; both routes are registered `CheckAuth` without `CheckAdminRole`. ### Proof of Concept Precondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. A document is marked **protected** (visible, password set) and contains blocks with distinctive content. No password is supplied in any request below. **Targeted: one protected document's content and reference structure:** ``` POST http://127.0.0.1:6808/api/graph/getLocalGraph {"id":"<PROTECTED_DOC_ID>"} ``` Returns nodes whose `Title`/`Label` contain the protected document's per-block content, plus its links/backlinks. **Workspace-wide: every protected document:** ``` POST http://127.0.0.1:6808/api/graph/getGraph {} ``` Returns block-level nodes for every protected document in the workspace, together with the complete link graph. **Control:** requesting the same document through the normal content path returns the password placeholder confirming the password gate is enforced elsewhere and omitted here. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read the block-level content of every password-protected document in the workspace, plus the full reference/backlink topology, without ever supplying a password. This defeats the publish-password control for the graph subsystem. Confidentiality-only, no modification. ### Suggested fix Extend the graph filter to evaluate the password tier in addition to visibility: in `FilterGraphByPublishIgnore`, drop a node unless the document's publish password is unset or the caller presents a valid publish-auth cookie for it (`password == "" || CheckPublishAuthCookie(...)`), matching the sibling filters that enforce both tiers. Consider also excluding block content from node `Title`/`Label` for reader sessions, so the graph conveys structure without document text.

**CVE:** This vulnerability corresponds to [CVE-2026-72803](https://nvd.nist.gov/vuln/detail/CVE-2026-72803). ### Summary `POST /api/attr/getBlockAttrs` and `POST /api/attr/batchGetBlockAttrs` return a block's full attribute set (IAL) with no publish-access check. Both are `CheckAuth`-only, so they are reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. An anonymous reader supplying a block ID receives the block's name, alias, memo, bookmark, tags, and every `custom-*` attribute including for blocks in publish-forbidden and password-protected documents. The batch variant accepts an ID list, making it a bulk extraction primitive. ### Details Neither handler applies a filter: ```go // /api/attr/getBlockAttrs (router line 301) ret.Data = sql.GetBlockAttrs(id) // /api/attr/batchGetBlockAttrs (router line 302) ret.Data = sql.BatchGetBlockAttrs(idList) ``` `sql.GetBlockAttrs` is a direct database read returning the block's entire IAL: `name`, `alias`, `memo`, `bookmark`, `tags`, and any `custom-*` key/value the user has set. Several of these are user-authored free text memos in particular are freeform notes attached to a block so this is document content, not merely structural metadata. `batchGetBlockAttrs` takes an arbitrary list of block IDs in a single request, so an attacker holding a set of block IDs can sweep attributes across the entire workspace in one call. **Guarded-sibling asymmetry.** The sibling metadata endpoint `getBlockInfo` calls `checkBlockPublishAccess(c, id, ret)` before returning; `getBlockAttrs` and `batchGetBlockAttrs` call nothing. Verified at `origin/master`: both handler bodies contain no publish-access, publish-ignore, or readonly-role check, and both routes are registered `CheckAuth` without `CheckAdminRole`. ### Proof of Concept Precondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. A document is marked publish-forbidden (or password-protected) and contains a block with a memo and a custom attribute set. **Single-block disclosure:** ``` POST http://127.0.0.1:6808/api/attr/getBlockAttrs {"id":"<BLOCK_ID_IN_PROTECTED_DOC>"} ``` Returns the block's IAL: `name`, `alias`, `memo`, `bookmark`, `tags`, and all `custom-*` values. **Bulk disclosure:** ``` POST http://127.0.0.1:6808/api/attr/batchGetBlockAttrs {"ids":["<ID1>","<ID2>","<ID3>"]} ``` Returns the attribute sets for every supplied ID in one response, with no per-ID authorization. **Control:** the sibling `getBlockInfo` with the same block ID is refused by `checkBlockPublishAccess`, confirming the boundary is enforced elsewhere and omitted here. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read block attributes belonging to publish-forbidden and password-protected documents, including user-authored memos and arbitrary `custom-*` values. The batch endpoint turns this into a bulk primitive: given a set of block IDs, an attacker retrieves attributes across the whole workspace in a single request. Confidentiality-only. ### Suggested fix Call `checkBlockPublishAccess` in `getBlockAttrs` before returning, matching `getBlockInfo`. For `batchGetBlockAttrs`, apply the check per ID and drop unauthorized entries from the response rather than failing the whole batch.

**CVE:** This vulnerability corresponds to [CVE-2026-72802](https://nvd.nist.gov/vuln/detail/CVE-2026-72802). ### Summary `POST /api/asset/resolveAssetPath` returns the resolved **absolute** filesystem path of an asset, unmodified. The route is `CheckAuth`-only, so it is reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. An anonymous reader who knows any asset's relative path trivially harvested from an `<img src="assets/…">` in any published document receives the server's absolute workspace path, disclosing the operating-system username and the installation layout. ### Details ```go // kernel/api/asset.go: resolveAssetPath p, err := model.GetAssetAbsPathInBox(path, "") // boxID="" → absolute workspace path ... ret.Data = p // returned raw, no stripping ``` `GetAssetAbsPathInBox(path, "")` resolves under `util.DataDir` / `util.WorkspaceDir`, producing a full host path such as `C:\Users\<username>\SiYuan\data\assets\foo.png` or `/home/<user>/…`. The handler returns it directly with no redaction and no publish-scope check. **This is data the project already treats as sensitive.** `getConf` explicitly zeroes `System.WorkspaceDir`, `AppDir`, `ConfDir`, `DataDir`, and `HomeDir` when `util.IsBrowserRequest(c)`, a change made specifically to avoid leaking the username (issue #17410). `resolveAssetPath` performs no equivalent stripping, so it re-exposes precisely the values `getConf` was patched to hide. **Related unfiltered siblings** in the same file, also `CheckAuth`-only with no publish scoping: - `getMissingAssets`: workspace-wide list of missing asset references - `getUnusedAssets`: every unused asset filename in the assets directory Both return asset inventory spanning all documents, including publish-forbidden ones. Verified at `origin/master`: `resolveAssetPath` returns the absolute path with no redaction, `getConf` contains the `IsBrowserRequest` stripping; all three routes are registered `CheckAuth` without `CheckAdminRole`. ### Proof of Concept Precondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. **1. Harvest an asset path**: open any published document and read a relative asset path from its markup, e.g. `assets/foo-20260101120000-abcdefg.png`. **2. Resolve it as an anonymous reader:** ``` POST http://127.0.0.1:6808/api/asset/resolveAssetPath {"path":"assets/foo-20260101120000-abcdefg.png"} ``` **3. Result:** the response returns the absolute host path, e.g. `C:\Users\<username>\SiYuan\data\assets\foo-...png` disclosing the OS username and the full workspace/installation layout. **Control:** `getConf` from the same anonymous session returns `WorkspaceDir`/`DataDir`/`HomeDir` blanked, confirming the project intends these values to be withheld from browser requests. **Related:** ``` POST http://127.0.0.1:6808/api/asset/getUnusedAssets {} POST http://127.0.0.1:6808/api/asset/getMissingAssets {} ``` Return workspace-wide asset inventory with no publish scoping. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` obtains the server's absolute workspace path, which typically embeds the OS username, plus the installation directory layout. This is useful for targeting subsequent attacks (path construction, user enumeration, social engineering) and directly contradicts the redaction the project applies in `getConf`. The related endpoints additionally disclose workspace-wide asset inventory, including assets referenced only by publish-forbidden documents. Confidentiality-only. ### Suggested fix Apply the same redaction `getConf` uses: for browser/reader requests, return the asset path relative to the workspace root rather than the absolute host path (or omit it entirely). Add publish-access scoping to `getUnusedAssets` and `getMissingAssets` so their results are limited to documents the caller may see.

**CVE:** This vulnerability corresponds to [CVE-2026-72801](https://nvd.nist.gov/vuln/detail/CVE-2026-72801). ### Summary Two `CheckAuth`-only endpoints disclose the complete offline attack material for the encrypted-notebook master password, plus the wrapped per-notebook key needed to use it. Both are reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. An unauthenticated remote client can retrieve the Argon2id salt and cost parameters, a verifier that confirms a correct password offline, and the encrypted per-notebook data key reducing the security of every encrypted notebook to the master password's resistance to offline GPU cracking. ### Details **(1) `POST /api/system/getConf` leaks `NotebookCrypto`.** `getConf` → `GetMaskedConf()` marshals the full configuration including `NotebookCrypto *conf.NotebookCrypto` (JSON tag `notebookCrypto`, not `-`, so it survives the deep copy). For non-administrators `HideConfSecret()` is applied, which nulls a dozen secret-bearing fields like AI, MCPOAuth, Api, Flashcard, Publish, Repo, Sync, Secrets, Variables, System paths but contains **no reference to `NotebookCrypto`**. `FilterConfByPublishIgnore()` for readers only touches `UILayout`. The reader therefore receives: | Field | What it is | |---|---| | `MasterSalt` | global Argon2id salt | | `KDFParams` | Argon2id memory/time/parallelism cost | | `KEKVerifier` + `VerifierNonce` | AES-GCM-encrypted fixed magic, the in-code comment states it exists for offline master-password verification | | `KEKMAC` | HMAC-SHA256 of the KEK | Either `KEKVerifier` or `KEKMAC` is a self-contained offline oracle: ``` KEK = Argon2id(guess, MasterSalt, KDFParams) correct if AES-GCM-decrypt(KEKVerifier, VerifierNonce) == magic or HMAC(KEK) == KEKMAC ``` No server round-trips are required, so there is no rate limiting, lockout, or logging on guesses, and the work is fully GPU-parallelisable. **(2) `POST /api/notebook/getNotebookConf` leaks the wrapped data key.** `box.GetConf()` returns the full `BoxConf` including `BoxCrypt.WrappedDEK`, the per-notebook data-encryption key wrapped under the KEK via AES-GCM together with `WrapNonce`. `getNotebookInfo` is the same class. Once (1) yields the master password, the attacker derives the KEK, decrypts `WrappedDEK` to recover the real data-encryption key, and decrypts every `.sy` file in that notebook. **Why this matters beyond the at-rest threat model.** Storing verifier and KDF material alongside the ciphertext is reasonable against a *local* attacker who already has filesystem access. Serving `MasterSalt` + `KDFParams` + `KEKVerifier` + `WrappedDEK` to an *anonymous remote reader* converts that at-rest assumption into a remote pre-authentication cracking opportunity. **Guarded-sibling asymmetry.** `HideConfSecret` nulls a dozen secret fields but omits `NotebookCrypto`. `lsNotebooks` filters notebook visibility for readers, while `getNotebookConf` and `getNotebookInfo` apply no reader filter at all. Verified at `origin/master` (`eef105683`): handler bodies as described; `HideConfSecret` contains zero `NotebookCrypto` matches; `FilterConfByPublishIgnore` touches only `UILayout`; all relevant struct JSON tags are non-`-`; all three routes are registered `CheckAuth` without `CheckAdminRole`. ### Proof of Concept Precondition: publish mode enabled (default port 6808) with at least one encrypted notebook configured; anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. **1. Retrieve the key-derivation material as an anonymous reader:** ``` POST http://127.0.0.1:6808/api/system/getConf {} ``` The response's `notebookCrypto` object contains `MasterSalt`, `KDFParams`, `KEKVerifier`, `VerifierNonce`, and `KEKMAC` while the same response has the other secret fields (Api, Repo, Sync, Publish, System paths) correctly blanked, demonstrating the omission. **2. Retrieve the wrapped notebook key:** ``` POST http://127.0.0.1:6808/api/notebook/getNotebookConf {"notebook":"<NOTEBOOK_ID>"} ``` The response contains `BoxCrypt.WrappedDEK` and `WrapNonce`. **3. Offline:** candidate passwords are verified locally against `KEKVerifier`/`KEKMAC` using `MasterSalt` and `KDFParams`, with no further server interaction. A recovered password yields the KEK, which unwraps `WrappedDEK` to the notebook's data-encryption key. *Verification status:* the leak paths are confirmed by code inspection at `origin/master`. A live end-to-end demonstration requires a build from HEAD with an encrypted notebook enabled; the test instance available predates the encrypted-notebook feature, so no runtime reproduction is claimed here. ### Impact An unauthenticated remote client (publish mode with auth disabled) or any publish `RoleReader` obtains everything needed to mount an unlimited, unthrottled, GPU-parallel offline attack on the encrypted-notebook master password, plus the wrapped data key to decrypt notebook contents o

**CVE:** This vulnerability corresponds to [CVE-2026-72800](https://nvd.nist.gov/vuln/detail/CVE-2026-72800). ### Summary `POST /api/av/getAttributeViewKeysByID` returns a database's full column schema with no publish-access filtering, while its sibling `getAttributeViewKeys` applies the filter for reader sessions. Two further endpoints, `getBlockDefIDsByRefText` and `getBlockRelevantIDs` return workspace-wide block IDs with no publish scoping. All three are `CheckAuth`-only, so they are reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. ### Details **(a) `getAttributeViewKeysByID`: ungated column-schema disclosure** The entire handler (`kernel/api/av.go`, router line 548): ```go ret.Data = model.GetAttributeViewKeysByID(avID, keyIDs...) // no publish gate ``` With an empty `keyIDs`, `GetAttributeViewKeysByID` calls `av.ParseAttributeView(avID)` and returns every column's `*av.Key`: | Field | Discloses | |---|---| | `Name`, `Desc` | column title and user-authored description | | `Options` | the full single/multi-select vocabulary and colours (e.g. status labels such as "Fired", "Confidential") | | `Template` | the column's Sprig template expression — logic and field references | | `Relation` | the target `avID`, allowing pivot to another database | | `Rollup`, `NumberFormat`, date config | further schema | **Guarded-sibling asymmetry, same file:** `getAttributeViewKeys` (router line 526) runs `FilterBlockAttributeViewKeysByPublishAccess(...)` when `IsReadOnlyRoleContext`. `getAttributeViewKeysByID` applies nothing. A reader who knows an `avID` — trivially harvested from the `data-av-id` attribute of any published document embedding a database obtains the schema of any database in the workspace, including those whose host documents are hidden, password-protected, or publish-forbidden. `Relation` targets allow walking to sibling databases. **(b) Two unscoped block-ID enumeration oracles** Both `CheckAuth`-only with no publish gate. Neither returns content of its own, but both yield valid block IDs that other endpoints turn into content: - `getBlockDefIDsByRefText` (router line 237) → `GetBlockDefIDsByRefText(anchor)` returns the block IDs, workspace-wide and including private documents, whose reference/anchor text equals a caller-supplied string: a ref-text → ID oracle. - `getBlockRelevantIDs` (router line 274) → `GetBlockRelevantIDsInBox(id, <notebook from request>)` returns parent/previous/next block IDs and traverses decrypted encrypted-notebook structure while the notebook is unlocked, a tree-walk oracle. Verified at `origin/master` (`eef105683`): all three handler bodies contain no publish-access, publish-ignore, or readonly-role check; all three routes are registered `CheckAuth` without `CheckAdminRole`. ### Proof of Concept Precondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. A database exists whose host document is publish-forbidden or password-protected. **(a) Column schema of any database:** ``` POST http://127.0.0.1:6808/api/av/getAttributeViewKeysByID {"avID":"<AV_ID>"} ``` Returns every column's key object names, descriptions, select vocabularies, template expressions, and `Relation` target `avID`s for a database whose host document the reader may not access. **Control:** the sibling `getAttributeViewKeys` with the same `avID` returns filtered results for the same reader session, confirming the boundary is enforced there and omitted here. **(b) ID oracles:** ``` POST http://127.0.0.1:6808/api/block/getBlockDefIDsByRefText {"anchor":"<known ref text>"} → block IDs workspace-wide, including blocks in private documents POST http://127.0.0.1:6808/api/block/getBlockRelevantIDs {"id":"<BLOCK_ID>","notebook":"<BOX_ID>"} → parent/previous/next block IDs; traverses encrypted-notebook structure when unlocked ``` ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read the complete column schema of any database in the workspace, including column descriptions, select-option vocabularies (which frequently encode sensitive category labels), template logic, and relation targets that permit pivoting to further databases regardless of whether the host document is hidden, password-protected, or excluded from publishing. The two enumeration endpoints additionally supply valid block IDs across the publish boundary, including from encrypted notebooks while unlocked. This removes the "attacker must already know a valid ID" precondition from other block-read endpoints, converting ID knowledge into content disclosure. Confidentiality-only. ### Note getAttributeViewKeysByID is a distinct handler from getAttributeView; although column definitions also appear within the latter's response payload, a fix applied to one handler does not remediate the other, and getAttributeViewKeysByID has its own filtered si

**CVE:** This vulnerability corresponds to [CVE-2026-72799](https://nvd.nist.gov/vuln/detail/CVE-2026-72799). ### Summary Five filetree endpoints resolve arbitrary document IDs and paths with no publish-access check of any kind. All are `CheckAuth`-only, so they are reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. An anonymous reader can map the complete private document tree every notebook, folder, and document title, and which notebook holds each document for documents marked hidden, password-protected, or publish-forbidden, and can resolve titles to document IDs. ### Details None of the following handlers invokes `IsReadOnlyRoleContext`, `CheckBlockIdAccessableByPublishAccess`, or `CheckPathAccessableByPublishIgnore`: | Endpoint | Returns | Discloses | |---|---|---| | `getFullHPathByID` (router 159) | `GetFullHPathByID(id)` | full title path including notebook, e.g. `/MySecretNotebook/Confidential/Q3 Layoffs Plan` | | `getHPathByID` (router 157) | `GetHPathByID(id)` | document-relative title path | | `getPathByID` (router 158) | `{path, notebook}` | which notebook a document lives in, plus its `.sy` storage path | | `getIDsByHPath` (router 160) | `GetIDsByHPath(path, notebook)` | title-path → document-ID enumeration | | `getHPathByPath` (router 155) | HPath from a storage path | title path from a storage path | Each accepts an arbitrary ID or HPath and resolves it identically for hidden, publish-forbidden, and password-protected documents. This enables two operations for an unauthenticated caller: 1. **Map the private document tree**: `getFullHPathByID` and `getPathByID` yield every notebook/folder/document title and its containing notebook. 2. **Resolve titles to IDs**: `getIDsByHPath` converts a known or guessed title path into document IDs, which are the required input for other block-read endpoints. Document titles and HPaths are precisely the block metadata that the project's block-metadata restriction (commit `ffde3b21e`) set out to protect; that change gated `getBlockInfo`, `getDocInfo`, and `getDocsInfo` but left this entire path-resolution family open. **Guarded-sibling asymmetry.** `getRecentDocs` (`FilterRecentDocsByPublishAccess`), `getCriteria` (`FilterCriteriaByPublishAccess`), and `getLocalStorage` (`FilterLocalStorageByPublishAccess`) all filter document references for reader sessions. The codebase clearly publish-scopes reader-visible metadata elsewhere; these five endpoints do not. Verified at `origin/master` (`eef105683`): all five handler bodies contain no publish-access call; the storage-family siblings contain their filters; all five routes are registered `CheckAuth` without `CheckAdminRole`. ### Proof of Concept Precondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. A document exists in a notebook marked publish-forbidden or password-protected. **Resolve a private document's full title path:** ``` POST http://127.0.0.1:6808/api/filetree/getFullHPathByID {"id":"<DOC_ID>"} → /MySecretNotebook/Confidential/Q3 Layoffs Plan ``` **Identify its notebook and storage path:** ``` POST http://127.0.0.1:6808/api/filetree/getPathByID {"id":"<DOC_ID>"} → {"path":"/....sy","notebook":"<BOX_ID>"} ``` **Enumerate IDs from a title path:** ``` POST http://127.0.0.1:6808/api/filetree/getIDsByHPath {"path":"/Confidential","notebook":"<BOX_ID>"} → document IDs under a folder the reader cannot otherwise access ``` Each returns data for documents excluded from publishing; no password or membership is required. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can enumerate the complete private document structure: notebook names, folder hierarchy, and document titles for content the administrator marked hidden, password-protected, or excluded from publishing. Document titles alone are frequently sensitive (project names, personnel actions, client identifiers). The ID-resolution direction additionally supplies valid document IDs, removing the "attacker must know an ID" precondition for other block-read endpoints. Confidentiality-only. ### Suggested fix For `IsReadOnlyRoleContext` sessions, gate each of the five handlers with `CheckBlockIdAccessableByPublishAccess` (or restrict resolution to publish-visible documents), mirroring the treatment already applied in `getRecentDocs`, `getCriteria`, and `getLocalStorage`.

**CVE:** This vulnerability corresponds to [CVE-2026-72798](https://nvd.nist.gov/vuln/detail/CVE-2026-72798). ### Summary `renderAttributeView` correctly applies the reader publish-access filter, but the filter's row-accessibility decision is keyed solely to the row's **first cell**, and it never inspects the remaining cells' values. Relation and Rollup cells carry mirrored content from a *different* database, so a row belonging to a published database can hand an anonymous reader the contents of a related database whose host document is hidden, publish-forbidden, or password-protected. Separately, when the first column is not a block value the accessibility check is skipped entirely and the row is returned unchecked. ### Note: This is distinct from the previously reported password-tier omission in the same function that concerns the row's own primary block, whereas these two defects concern (a) other cells' related-database content, which no row-level check covers and (b) rows where the first cell is not a block at all. A fix to the row-drop condition alone would close neither. ### Details `renderAttributeView` applies the filter (`kernel/api/av.go:68`): ```go retDataMap["view"] = model.FilterViewByPublishAccess(c, publishAccess, retDataMap["view"].(av.Viewable)) ``` Inside `FilterViewByPublishAccess` (`kernel/model/publish_access.go`): ```go if row.Cells[0].Value.Block != nil { bt = treenode.GetBlockTree(row.Cells[0].Value.Block.ID) } if bt != nil { if !CheckPathAccessableByPublishIgnore(bt.BoxID, bt.Path, publishIgnore) { row = nil // drop } } // every other cell in the row is returned as-is ``` **(a) Relation and Rollup cells leak the related database.** These value types carry mirrored content, not just references: ```go type ValueRelation struct { BlockIDs []string; Contents []*Value } type ValueRollup struct { Contents []*Value } ``` The render pipeline populates them from a different attribute view e.g. `kernel/model/attribute_view.go:2731`: ```go v.GroupVal.Relation.Contents = []*av.Value{ relationDestAv.GetBlockValue(groupValue) } ``` `relationDestAv` is a separate database that may live in a hidden, publish-forbidden, or password-protected document. When a published database's row survives the filter (because its column-0 document is public), its Relation and Rollup columns return the related, non-published database's content block text, titles, and mirrored column values. `FilterViewByPublishAccess` performs no publish-access evaluation on `Relation.Contents` or `Rollup.Contents`. **(b) Fail-open when column 0 is not a block.** `bt` is assigned only when `row.Cells[0].Value.Block != nil`. If the first column is a non-block type (Relation, Text, …) or the row is detached, `bt` remains `nil`, the `if bt != nil` guard is skipped, and the row is returned with no accessibility check at all. Column order is user-reorderable, so any database whose first column is not the document block bypasses row filtering entirely. Verified at `origin/master` (`eef105683`). ### Proof of Concept Precondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`. Two databases: **DB-A** hosted in a published document, **DB-B** hosted in a publish-forbidden or password-protected document, with a Relation column in DB-A pointing at DB-B and containing a distinctive marker value. **(a) Related-database content disclosure:** ``` POST http://127.0.0.1:6808/api/av/renderAttributeView {"id":"<DB_A_AV_ID>"} ``` Rows of DB-A are returned (correctly, since its host document is public), and their Relation/Rollup cell `Contents` include DB-B's block text and mirrored column values, despite DB-B's host document being excluded from publishing. **(b) Fail-open row:** Reorder DB-A so its first column is a non-block type (or use a detached row), mark its host document publish-forbidden, and request the same endpoint the row is returned without any accessibility evaluation. *Verification status:* both defects are confirmed by code inspection at `origin/master`. A live demonstration requires a build from HEAD with two linked databases; available on request. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read content from databases whose host documents are hidden, publish-forbidden, or password-protected, by requesting a *published* database that relates to them. Because relation graphs are commonly used to link a public index to private detail records, this exposes exactly the data the publish boundary is meant to withhold. The fail-open path additionally returns rows with no accessibility check whenever the first column is not a block value, which is a user-controlled layout property. Confidentiality-only. ### Suggested fix In `FilterViewByPublishAccess`: 1. For each retained row, evaluate every `Relation.Contents` and `Rollup.Contents` entry against `CheckBlockIdAccessableByPublishAccess` (including the pub

**CVE:** This vulnerability corresponds to [CVE-2026-72797](https://nvd.nist.gov/vuln/detail/CVE-2026-72797). ### Summary `POST /api/notebook/getEncryptedNotebookStatus` returns the identifier, name, and current lock state of every encrypted notebook, with no publish-access filtering. The route is registered `CheckAuth` only, no `CheckReadonly`, no `CheckAdminRole` so it is reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. Encrypted notebooks are private by design; their names frequently reveal the sensitive topic that motivated encrypting them. ### Details Route registration (`kernel/api/router.go:131`): ```go ginServer.Handle("POST", "/api/notebook/getEncryptedNotebookStatus", model.CheckAuth, getEncryptedNotebookStatus) ``` The handler (`kernel/api/notebook.go`) accepts no arguments and contains no `IsReadOnlyRoleContext` branch and no publish-access filter of any kind. It returns, for every encrypted notebook, `{id, name, unlocked}`, the notebook's `box.Name` and its live lock state together with `enabled`, `count`, `migrationPending`, `migrationBoxes`, and `hasHistoryDependency`. **Guarded-sibling asymmetry.** The primary notebook listing `lsNotebooks`, in the same file and also reader-reachable, *does* filter: it skips notebooks that are `Closed` and any notebook whose `publishAccess` entry is not `Visible`. The project therefore publish-scopes notebook listings but `getEncryptedNotebookStatus` enumerates all encrypted notebooks unconditionally. **Still unfixed at HEAD.** The encrypted-notebook hardening series (issue #18034 idle auto-lock, lock-on-background, key handling, atomic unlock) is local-threat work. Commit `f2d966659` ("Expose encrypted notebook unlock status to plugins") introduced this exposure, and no subsequent commit gates it for the publish/reader boundary. **Secondary effect.** `unlocked: true` is a live indicator of exactly when an encrypted notebook's plaintext is resident in memory, the window during which reader-reachable code paths that accept a notebook argument can read its decrypted content. ### Proof of Concept Precondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. At least one encrypted notebook exists. ``` POST http://127.0.0.1:6808/api/notebook/getEncryptedNotebookStatus {} ``` Returns the full set of encrypted notebooks with their IDs, names, and current `unlocked` state including notebooks that `lsNotebooks` withholds from the same reader session. No arguments and no privileged access are required. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` learns which encrypted notebooks exist, what they are called, and whether each is currently unlocked. Notebook names are themselves sensitive: a user encrypts a notebook precisely because its subject matter is private, and the name commonly states that subject. Disclosing existence and naming to unauthenticated parties defeats that expectation, and the live lock state additionally reveals when the notebook's contents are decrypted in memory. Confidentiality-only. ### Suggested fix For `IsReadOnlyRoleContext` sessions, either reject the request or restrict the response to notebooks that are publish-visible, mirroring the filtering already applied in `lsNotebooks`. Encrypted notebooks arguably should never be enumerated to a reader at all.