GHSA-c8r8-95hg-mp34 SiYuan: MCP file tool's blocklist is incomplete relative to the HTTP file API it claims to align with, exposing publish-mode passwords and other sensitive workspace files

• Go github.com/siyuan-note/siyuan/kernel: < 0.0.0-20260808051406-3542530c505f → fixed in 0.0.0-20260808051406-3542530c505f

Summary `kernel/mcp/tools/file.go`'s `resolvePath()` includes an explicit comment stating its sensitive-path blocklist is meant to align with the HTTP file API's established blacklist (`refuseToAccess()` in `kernel/api/file.go`), following the remediation for GHSA-cvhv-7xhj-xjp8 ("Unauthenticated Administrator takeover exfiltrated via the MCP"), which specifically recommended restricting this tool's scope. In practice, the MCP tool implements only 1 of the 4 static blocklist entries the HTTP API enforces. Comparison `kernel/api/file.go` `refuseToAccess()` blocks: 1. `conf/conf.json` (API token, cookie signing key, accessAuthCode) 2. `data/snippets/conf.json` 3. the entire `data/templates` directory 4. `data/.siyuan/publishAccess.json` 5. (dynamic, per-request) any path the current publish-mode session isn't authorized for `kernel/mcp/tools/file.go` `resolvePath()` blocks only: ```go confPath := filepath.Join(util.ConfDir, "conf.json") if abs == confPath { return "", fmt.Errorf("access to conf.json is forbidden") } ``` Items 2, 3, and 4 are absent. The tool's own `list`/`read`/`grep`/`find` actions remain fully functional against them. Impact An MCP client with access to the `file` tool (post-fix for GHSA-cvhv-7xhj-xjp8, i.e. a properly authenticated Administrator-level caller) can read `data/.siyuan/publishAccess.json` directly: ```go type PublishAccessItem struct { ID string `json:"id"` Visible bool `json:"visible"` Password string `json:"password"` // plaintext; empty string = no password Disable bool `json:"disable"` } ``` This exposes the plaintext access password for every publish-mode-shared notebook/document, letting the reader bypass password protection on any publish-mode share. This is a serious sibling issue given the volume of publish-mode access-control bugs already reported against this codebase — the passwords protecting exactly that feature are directly readable through a tool whose own description says "never use for workspace data." `data/templates` and `data/snippets/conf.json` are lower-severity but still inconsistent with the HTTP API's own precedent for what counts as sensitive. Why this is a distinct finding, not a duplicate GHSA-cvhv-7xhj-xjp8 was about *reachability* an unauthenticated Reader-tier JWT being forwarded to admin-scoped paths including `/mcp`. That has been fixed. This report is about the *tool's own scope* once reached by a legitimate, properly-authenticated caller, the remediation notes for that same advisory explicitly called for restricting `resolvePath` to `WorkspaceDir/temp/siyuan/*.log`, which was not implemented; instead the tool retains workspace-wide scope with only a single-file blocklist addition. Suggested fix Either replicate the full `refuseToAccess()` blocklist in `resolvePath()` (minimum fix, keeps parity with the HTTP API going forward by extracting `refuseToAccess`'s path list into a shared helper both call), or implement the originally-recommended allowlist restricting the tool to `WorkspaceDir/temp/siyuan/*.log` for read and disabling write/delete/rename/copy entirely unless the caller is Administrator, matching the tool's own advertised "debugging/log reading only" scope.