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:

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:

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.