CVE-2026-60083: 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 in github.com/siyuan-note/siyuan/kernel

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.