A nil pointer dereference vulnerability in SiYuan versions before 3.8.9 allows authenticated attackers to crash the note-taking application’s kernel process by sending a specially crafted MCP resources/read request.
Quick Take
- What: Nil pointer dereference in SiYuan’s privateCacheMiddleware when handling MCP resources/read requests for nonexistent resources
- Who is affected: SiYuan users running versions 3.8.7 and 3.8.8; attackers need a valid API token
- CVSS score: 4.9 (Medium) according to NVD; 6.9 according to VulnCheck
- Fixed version: 3.8.9
- What to do: Upgrade to SiYuan 3.8.9 or later
In plain English
SiYuan is a note-taking application that supports MCP (Model Context Protocol) for AI integrations. A bug in versions 3.8.7 and 3.8.8 causes the program to crash when someone with a valid login token asks it to read a resource that does not exist. When the crash happens, the SiYuan server stops working for a few seconds (about 2.6 seconds in Docker) and restarts automatically. During that time, anyone using the app loses their connection.
What you should do: If you run SiYuan and use its MCP features, upgrade to version 3.8.9. If you do not use SiYuan or do not have MCP enabled, this does not affect you.
What happened
The vulnerability exists in SiYuan’s privateCacheMiddleware function in kernel/mcp/server.go. When an authenticated client sends a resources/read request for a nonexistent MCP resource in an initialized session, the go-sdk v1.8.0 library returns a typed nil pointer (*ReadResourceResult with a nil value) along with an error.
The middleware performs a type switch on the result and unconditionally dereferences the pointer to set cacheable.CacheScope = “private” without checking if the pointer is nil. This triggers a SIGSEGV panic (segmentation violation at address 0x18, the offset of the CacheScope field), causing the kernel process to exit immediately with exit code 2.
The issue was reported by xy3xy3 and documented in GitHub Security Advisory GHSA-2x3p-x74g-442x. The reporter observed the crash in Docker deployments, where the container exits and restarts automatically. During the restart window, all client connections are interrupted.
SiYuan does not register any MCP resources by default (the capabilities object is empty and resources/list returns an empty array), but the go-sdk always registers the resources/read method handler. The SDK’s checkRequest function only validates that the method name is known, not whether resources are actually available, allowing the request to reach the vulnerable code path.
What you should do
Upgrade to SiYuan version 3.8.9, which patches the nil pointer dereference. The fix adds a nil check before dereferencing the result pointer in privateCacheMiddleware.
If you cannot upgrade immediately, restrict access to API tokens to trusted users only, as the vulnerability requires a valid API token to exploit.
What it means
This is a denial-of-service vulnerability that requires authentication. An attacker with a valid API token can repeatedly crash the SiYuan kernel, disrupting service for all users. In Docker deployments, the container restarts automatically, but the interruption lasts several seconds. In non-Docker deployments, the process exits and may require manual restart, potentially causing data loss if unsaved edits exist.
The vulnerability affects automated workflows that use MCP to write content to SiYuan (such as ChatGPT or openai-mcp integrations). Failed write operations may be caused by the connection being terminated mid-request rather than receiving a proper error response.
The issue does not affect users who do not use MCP features or who do not expose their SiYuan API to untrusted parties.
