SiYuan patches two AI agent tool flaws in note-taking app

Two security advisories published on 2 October 2026 describe flaws in the AI agent tooling of SiYuan (思源笔记), an open-source note-taking application. Both affect all versions up to and including 3.8.0 and are fixed in 3.8.1. Both were reported on 13 August 2026 by an outside researcher, according to the GitHub Security Advisory entries.

The first issue, tracked as GHSA-p23f-cm6q-2qp8, concerns SiYuan's native MCP tool asset.upload. MCP, the Model Context Protocol, is the interface that lets an AI agent call application functions. The advisory says the tool's files argument takes a comma-separated list of absolute file paths, and the handler only normalises each entry with Go's filepath.Abs. It performs no workspace boundary check and no sensitive-path check. A downstream function then opens each path and copies the bytes into the workspace assets/ directory.

According to the advisory, asset.upload is the only AI tool in SiYuan that accepts arbitrary absolute paths without validation; the file and unzip tools resolve paths relative to the workspace. An attacker who can steer the agent through prompt injection — malicious instructions hidden in web pages or notes the agent reads — could have it copy files such as SSH private keys, cloud credentials or /etc/passwd into the workspace, where they are reachable through notes, export or sync. The user does see a confirmation prompt, but the advisory says it is category-level and does not display the specific source path, so the approval is "effectively blind to the actual file being read". The advisory describes the flaw as a residual gap left by an earlier MCP fix, CVE-2026-66012, which added an admin check on the /mcp endpoint but did not restrict which files asset.upload could read.

The second advisory, GHSA-x8gv-g2g3-65fj, covers the http_request and web_fetch agent tools. Their only protection against server-side request forgery is a function called CheckHostSSRF, which resolves the hostname once and rejects private, loopback or link-local addresses. The actual connection then performs a second, independent DNS lookup with no connect-time check. Because the two lookups are not pinned to the same result, an attacker-controlled domain can return a public address to the guard and a private one to the connection. The advisory calls this a classic DNS-rebinding time-of-check/time-of-use bypass and says it can reach cloud instance metadata at 169.254.169.254 and internal services.

The researcher says the behaviour was dynamically verified on v3.8.0 using a process-level DNS hijack: a test domain returned a public IP on guard lookups and 127.0.0.1 on connection lookups, and both tool functions returned content from a loopback-only service. The advisory describes this as an incomplete fix of an earlier SSRF remediation, noting that the agent paths received the parse-time check but not the connect-time SSRFSafeDialer, which in any case only blocks private addresses when SafeMode is enabled, and SafeMode defaults to off.

Neither issue is listed in CISA's Known Exploited Vulnerabilities catalogue, the advisories state. The recommended fixes are to enforce workspace and sensitive-path checks in asset.upload, show the real source path in the confirmation dialog, and mount a connect-time address check on the agent HTTP paths.