CVE-2026-60083: SiYuan: MCP file tool leaks publish-share passwords

## 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.

An attacker obtains an administrator-level token or MCP session, for example through a leaked token or an AI agent compromised by indirect prompt injection in a synced document. They call the MCP file tool's read action on data/.siyuan/publishAccess.json and receive the plaintext passwords for every protected publish share. They then open the password-protected published notebooks directly, or sell or reuse the passwords, bypassing the share-level access control without touching the main application login.