Description

SiYuan is a self-hosted personal knowledge management system. In versions 3.8.0 through 3.8.3, the MCP file tool's sensitive-path guard (util.IsForbiddenAbsPath(), invoked from resolvePath()) is applied only to the allowed root of recursive operations and not to each resolved descendant path — an incomplete fix for GHSA-c8r8-95hg-mp34. An authenticated administrator using the in-app Agent or the external MCP server can therefore bypass the protected-workspace-file denylist: file.grep can return matching lines from non-hidden protected descendants (for example conf/conf.json, TLS keys, data/snippets/conf.json, data/templates/, data/.siyuan/publishAccess.json, notebook .siyuan internals, or the kernel log), file.copy can copy protected descendants to an ordinary path where file.read can then retrieve them, and unzip can overwrite protected descendants using ordinary, lexically contained ZIP member names. Because file.grep is globally classified as a safe action, it receives no per-call confirmation, and the confirmation cards for file.copy and unzip show only the allowed root arguments. This issue is fixed in version 3.8.4. Suggested title: SiYuan 3.8.0 through 3.8.3 Sensitive-Path Guard Bypass in Recursive MCP File Operations.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-26T14:16:44.687Z",
  "pubdate": "2026-09-26T14:16:44.687Z",
  "executiveSummary": "SiYuan versions 3.8.0 through 3.8.3 are vulnerable to a sensitive-path guard bypass within the MCP (Model Context Protocol) file toolset. This vulnerability arises from an incomplete fix for GHSA-c8r8-95hg-mp34, where the utility function util.IsForbiddenAbsPath() is improperly applied only to the root of recursive file operations rather than individual descendant paths.\nThe vulnerability allows an authenticated administrator to interact with protected system files and sensitive configuration data that should be strictly off-limits. By exploiting this logic flaw, an attacker can use file.grep, file.copy, and unzip operations to access, exfiltrate, or overwrite critical system files, including TLS keys, configuration files (conf/conf.json), kernel logs, and notebook internals.\nThe impact is significant, as these actions bypass the intended security constraints of the application's workspace isolation. Because certain operations like file.grep are classified as safe and lack granular confirmation, and because confirmation prompts for file.copy and unzip display only the root path, unauthorized access can occur stealthily. This flaw mandates immediate attention, as it provides a pathway for full system compromise for any actor with administrative access to the in-app Agent or external MCP server.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper implementation of path validation logic within the resolvePath() function. In SiYuan versions 3.8.0-3.8.3, the sensitive-path security guard, util.IsForbiddenAbsPath(), is invoked at the initiation of a recursive operation against a designated root directory. However, the system fails to validate individual descendant paths resolved during the recursion, effectively nullifying the denylist for nested file structures.\nThe attack flow relies on the discrepancy between initial root-level validation and actual file access. An authenticated administrator can invoke MCP tool functions—specifically file.grep, file.copy, and unzip—providing a root path that passes the initial validation check. Once the operation begins, the engine resolves paths to protected resources such as 'conf/conf.json', 'data/.siyuan/publishAccess.json', or system-level TLS keys. Because the system does not re-verify the forbidden status of these resolved paths during the recursive process, it performs the requested operation on protected files.\nExploitation vectors are diverse: 1) file.grep: Allows for the exfiltration of sensitive information from protected files by returning matching lines directly to the user, bypassing security classification because the operation is treated as safe and requires no confirmation. 2) file.copy: Enables an attacker to copy sensitive files, such as internal keys or configuration data, into an accessible path where they can be subsequently retrieved via file.read. 3) unzip: Permits an attacker to manipulate archives to overwrite critical system files by crafting ZIP member names that resolve to protected target locations outside the intended sandbox.\nThis vulnerability is exacerbated by inadequate user feedback. Confirmation cards presented to the administrator only validate the root directory provided in the initial request, hiding the malicious intent of interacting with descendant protected paths. This lack of transparency facilitates the stealthy execution of unauthorized operations. The vulnerability is restricted to authenticated users with administrative privileges, but within that context, it represents a complete breakdown of the intended workspace isolation and file-system protection mechanisms."
}