CVE-2026-60083 — 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:

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.