MCP 與應用安全
SiYuan MCP Endpoint Lacked Role Checks; Version 3.7.2 Fixes Flaw Allowing Low-Privilege Users to Invoke Core Tools
The newly disclosed CVE-2026-66012 shows that, before SiYuan 3.7.2, the `POST /mcp` endpoint checked only general authentication status, without enforcing an administrator role or read-only restrictions. Because MCP can expose core note-management capabilities to AI clients, accounts intended only to read content could potentially use it to perform state-changing operations.
The open-source knowledge management tool SiYuan has fixed an authorization flaw in its MCP endpoint in version 3.7.2. According to the public description of CVE-2026-66012, when the core service in earlier versions received a `POST /mcp` request, it performed only the generic `model.CheckAuth` validation, without additionally checking whether the caller was an administrator or applying read-only mode. As a result, low-privilege users who could pass general authentication might gain MCP tool capabilities beyond the scope of their assigned roles.
The technical impact extends beyond that of a conventional REST API vulnerability. MCP clients typically enumerate available tools before allowing a model to select and combine calls based on natural-language instructions. If the server performs role checks only at the login layer, an agent may be able to chain a single unauthorized capability into a multistep data-modification workflow. The risk is higher when SiYuan is exposed externally, used in a shared deployment, or when access credentials are provided to desktop assistants and remote agents, compared with a local environment used by a single trusted user.
The official 3.7.2 release notes state only in general terms that the release “fixes several security vulnerabilities,” without detailing each affected tool, the scope of data that could be modified, or the full attack prerequisites. The CVE description identifies version 3.7.2 as the remediation boundary. Administrators should therefore upgrade directly to version 3.7.2 or later, rotate tokens previously configured in MCP clients, and review reverse-proxy logs for calls to `/mcp`. If an immediate update is not possible, the path can be blocked at the network layer or restricted to trusted local hosts and administrative network segments.
The broader lesson is that authorization for identity, role, and resource access must be reevaluated both when MCP tools are enumerated and every time a tool is executed. Being “authenticated” must not be treated as equivalent to being authorized to use every tool. More complete information on the CVSS score, affected configurations, and whether a public proof of concept exists is still pending from the vendor or CNA. There is currently no reliable evidence that the vulnerability has been actively exploited.