SiYuan MCP Endpoint Unauthorized Access: CVE-2026-66012, Fix in v3.7.2

A worst-case flaw rated at the maximum severity of 10.0 (CVSS, the 0-to-10 scale for how dangerous a flaw is) has been found in "SiYuan," a popular open-source note-taking app used to organize notes and knowledge. It is CVE-2026-66012. The six issues this article has tracked so far — all cases where a display hole lets someone take over your computer — were rated CVSS 9.0 to 9.9, and this one goes above that range. A fixed version, 3.7.2, is already available; if you use an earlier one, you need to update.

This flaw is different in nature from the previous six. What was targeted is a receptacle SiYuan recently added called "MCP," an entry point for being operated by AI. MCP (Model Context Protocol) is a common connector that lets an AI assistant, such as ChatGPT, call external apps as tools. SiYuan added this receptacle so that AI could read and organize your notes. But because that receptacle was open without properly checking "whose instruction is this", once certain conditions are met, a complete stranger who is not even logged in can remotely read and write your notes wholesale and ultimately take over the computer itself.

This article rounds up seven SiYuan vulnerabilities: the four in databases, CSS, and elsewhere (CVE-2026-50551 and others, fixed in 3.7.0) and the two in the "Bazaar" marketplace (CVE-2026-56395 / 56397, fixed in 3.6.1) that we reported in June, plus this one new MCP issue. To put the conclusion first: the seven issues covered here are all closed once you move to 3.7.2 or later (details in the quick-reference table later on).

Overview of CVE-2026-66012 (the AI-integration receptacle without authorization)

First, the essentials of CVE-2026-66012, the most severe of the seven. All values were confirmed against the developer's GitHub Security Advisory (GHSA-cvhv-7xhj-xjp8) and the NVD (the U.S. vulnerability database).

The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, a near-perfect line meaning "over the network, with no special privileges and no user interaction, an attacker can fully take confidentiality, integrity, and availability." The number pegs at 10.0 because, as described below, an unauthenticated remote attacker can go from reading and writing note contents to taking over the computer in one shot.

Who targets it, and what they take from your notes

A private journal, research notes, an internal design memo — whatever you have entrusted to SiYuan is the substance of your work and your life. So first, let's sketch who targets this hole, what they use it for, and what disappears from the hands of anyone caught by it. The frightening part this time is that, unlike the earlier six, it does not even require carelessly opening dubious data.

Exploiting this takes no knowledge of who you are. The realistic danger is not someone close to you, like a sharing partner, but an unfamiliar, remote attacker who mechanically sweeps around with port scans and the like, looking for people who have exposed SiYuan's publish feature to the internet or a corporate network. SiYuan has a "Publish" feature that shows your notes to others as a public page, and if you enable it without a password, anyone who can reach that address can talk to MCP, the AI receptacle, without logging in. What the attacker does is simply send a few requests to that receptacle in the prescribed steps and read and write the note storage folder from outside. No special tools, and no cooperation from the user, are required.

One of the 31 tools hanging behind that receptacle is named "file," and on its own it can list, read, write, delete, rename, and copy files. The attacker first reads the configuration file (conf/conf.json) and lifts out, in plaintext, the administrative passphrase (accessAuthCode), the API token, and the cookie signing key. With these they can impersonate the administrator. Further, by writing a crafted program into the plugin folder (data/plugins/), it starts running the moment SiYuan is next launched on that computer, leading to a full takeover.

What is taken is not abstract "data." The very contents you wrote in your notes — passwords, work drafts, confidential memos — are read wholesale, rewritten, and deleted. On top of that, once someone squats in the plugin folder, deleting the app alone does not undo it. For a person who has entrusted years of thinking to SiYuan, what truly hurts is not the app briefly malfunctioning but the accumulated notes, and the keys and passphrases mixed in among them, passing into someone else's hands while the computer itself is kept under watch.

CVE-2026-66012: the AI receptacle "/mcp" has no authorization, enabling remote takeover (CVSS 10.0)

Let's walk through the technical substance following the advisory. The origin of the problem is the POST /mcp receptacle in SiYuan's core program (the kernel). It is meant to be the entry point through which an AI assistant calls SiYuan as a tool, and 31 tools — file operations, database search, and so on — hang off it. Among them, the "file" tool is a powerful one that can list, read, write, delete, rename, and copy across the entire note storage folder (the workspace).

According to the advisory, this receptacle is registered as ginServer.POST("/mcp", model.CheckAuth, handlePost), passing only CheckAuth, which checks "are you logged in." Neither CheckAdminRole, which verifies whether you are an administrator, nor CheckReadonly, which restricts to read-only, is attached. The tools' descriptions say "read-only" and "for debugging only," but those are just comments and are not enforced in code. In other words, even a party holding only Reader privileges can reach the 31 admin-equivalent tools. That is the core of the hole, classified as "missing authorization (CWE-862)."

On top of this, the design of the Publish feature pours more oil on the fire. When you run SiYuan's Publish feature without a password (Publish.Auth.Enable=false), the publishing relay (reverse proxy) unconditionally attaches an "anonymous Reader" pass (JWT) to every request coming from outside and forwards it inward. Because this anonymous pass clears CheckAuth, a remote attacker who is not logged in can reach /mcp directly. A hole that is merely "missing authorization" turns, by way of the Publish feature, into one that "does not even require authentication."

The advisory even includes working proof-of-concept (PoC) code. The flow is this. First, send the connection handshake (initialize) to /mcp to start a session, then use the "file" tool to read conf/conf.json in full. From there, lift the administrative passphrase accessAuthCode, the API token, and the cookie signing key in plaintext, and log back in as administrator at the admin port. Finally, write an index.js under data/plugins/, and it runs on the next desktop launch. Because SiYuan's desktop version runs plugins under the loose settings nodeIntegration:true / contextIsolation:false, require("child_process") can run any command on the computer, and an OS-level takeover follows directly. In the reporter's verification, credential extraction and plugin planting were confirmed on a fresh environment. This issue was responsibly reported by Nguyen Van Hiep (@hypnguyen1209) of MBBank in Vietnam.

Is your SiYuan reachable? (many people are out of scope here)

You may be alarmed by the number CVSS 10.0, but first, calmly check your setup. For this hole to be exploitable remotely, several conditions have to line up at once. Many individual users are, in fact, on the side that cannot be reached remotely.

SiYuan's mainstream use is "local-first," completed on your own single computer. In that case, SiYuan's listening address is limited to inside your own computer (127.0.0.1) and cannot be touched from outside networks. Moreover, this hole is premised on "having the Publish feature enabled." If you are not using the Publish feature and your listening address is limited to 127.0.0.1 in ordinary desktop use, a stranger cannot exploit this hole remotely. Right here, many people fall out of the "instant catastrophe" scope.

Conversely, people with the following setups are squarely in scope. One is a setup where you stand SiYuan up with Docker or the like, expose it to a corporate network or the internet, and use the Publish feature without a password (anonymous mode). This is a legitimate configuration adopted by people who want to show their notes as public documentation. Another is a setup where there are other people's devices on the same LAN and you have widened the listening address to something like 0.0.0.0. In both, the MCP receptacle is reachable from outside. Note that the advisory points out that even if you set a reader password on the Publish feature, anyone holding a legitimate reader account can perform the same operations (a reader can escalate to administrator). Do not conclude "I set a password, so I'm safe."

That said, even those out of scope need to update. You may use it only locally today, but you might publish it somewhere tomorrow. And as the next section shows, holes of this kind — missing authorization — keep turning up around SiYuan's Publish feature. It is safest to quietly move to the latest version while you still do not meet the exploit conditions.

"Missing authorization" keeps recurring in products that add MCP

From here is not a marshaling of facts but the author's view. I think CVE-2026-66012 is less a one-off oversight and more a fit for one pattern that is on the rise now: a product adds an MCP server feature for AI integration, and as a result the "entry point meant to be hit by AI" ends up open with the authorization check missing. SiYuan added this entry point to a knowledge-management app, but the entry point did not verify "whose instruction is this."

On this site, as I see it, we have already tracked this pattern four times: the mcp-grafana case where authorization was missing in a monitoring dashboard's MCP integration, the unauthenticated tool invocation in mcp-pinot, the mcp-server-kubernetes case for a Kubernetes-operation MCP server, and the command injection in LiteLLM that led to unauthenticated takeover via MCP. All share a common trait: an "entry point for AI to conveniently use" was added in a hurry, and the authorization check guarding that entry point was left for later.

What makes SiYuan's MCP different from these infrastructure-leaning products is that what gets targeted is an individual's most private data — the notes themselves. Putting AI's hands into a knowledge-management app is a natural trend, but that hand's entry point should, in my view, be guarded as strictly as, or more strictly than, a human administrator. When choosing a product that advertises AI integration, we are now at a point where "can anyone touch the MCP entry point?" is fair to add to your checklist. Likewise, you can check whether the open-source components you use have known holes with the OSS Supply Chain Scanner.

One more thing, and this too is my read: the very fact that a seventh issue was later added to this article feels like corroboration that vulnerabilities keep coming out of SiYuan. In fact, even after this one issue, advisories flagging information disclosure to readers and missing privilege checks around the Publish feature were published one after another in late July, and many are closed in 3.7.3 or 3.7.4. Turned around, that also means the developer keeps steadily fixing what is reported. The best a user can do is not to feel safe on one particular version but to keep following the latest stable release.

Quick reference for all seven SiYuan issues (how far up do you need to go?)

The table lists the seven issues covered here by location, severity, and fixed version. To conclude: the seven issues here are all closed at 3.7.2 or later. That said, as the previous section noted, additional fixes around the Publish feature continue in 3.7.3 and 3.7.4, so if you can, going all the way to the latest stable release is safest.

Note that even people who updated to 3.6.1 or 3.7.0 as earlier countermeasures are still unfixed against this CVE-2026-66012. You can check your version from the app's settings screen (e.g. "Settings" → "About"). Anyone on a 3.6.x build, or on 3.7.0 / 3.7.1, needs to update again to 3.7.2 or later.

Close off the /mcp entry point and update to the latest release

1. Update SiYuan to 3.7.2 or later (ideally the latest stable release). This is the top-priority and surest fix. Get the latest version from the official releases page and update the desktop, mobile, and server versions alike. 3.7.2 closes all seven issues in this article, but additional fixes around the Publish feature continue in 3.7.3 and 3.7.4, so following the latest release is recommended.

2. Review the Publish feature. CVE-2026-66012 is exploitable remotely only when the Publish feature is enabled. Until you've updated, leave the Publish feature disabled if you don't use it, and set a reader password if you do (though, as noted above, a password alone does not fully prevent escalation, so the update is the real answer). If you expose it directly to the internet, consider temporarily halting publishing until the update is done.

3. Check your listening address. If you use it alone on the desktop, confirm that the listening address is limited to inside your own computer (127.0.0.1). If you have widened it to 0.0.0.0 or to the LAN without reason, revert it if you don't need it.

4. Regenerate credentials if anything rings a bell. If you recall exposing the Publish feature externally before updating, or saw unfamiliar behavior (a window launching on its own), regenerate the administrative passphrase (accessAuthCode) and API token stored in the config file, and also change the passwords written in your notes and the keys used to connect to servers (SSH keys). Also inspect the plugin folder (data/plugins/) for any folders you don't recognize.

The earlier four: takeover via XSS in databases, CSS, and the marketplace (fixed in 3.7.0)

From here, we keep the earlier six issues reported in June together. First, the four fixed in 3.7.0. In all of them, the cause was that the sanitization step in the processing that displays a string on screen was missing, and because SiYuan's desktop-version Electron settings are loose, a small display hole (cross-site scripting, or XSS for short) leaped all the way to a takeover of the computer (RCE). The report and verification are published in the developer's GitHub security advisories. The frightening part of these four was that you could be hit just from displaying data delivered through sharing or syncing, even without using the marketplace.

CVE-2026-50551: Takeover via a database attachment field (CVSS 9.9)

The first is an issue where the processing that displays information about a file attached to a cell in SiYuan's database (attribute view) — the rendering of the attachment cell — was missing the sanitization that strips out malicious programs (GHSA-56mp-4f3v-fgj2). An attacker can plant a crafted string in the attachment field of a shared table. When a user opens that table and the cell in question is drawn on screen, the planted program starts running, and on the Electron version it leads straight to a takeover of the computer (RCE). Because it is distributed through sharing and syncing, you can be hit even without going out of your way to install a malicious package.

CVE-2026-54158: Takeover via database cells (text, URL, phone, attachment) (CVSS 9.9)

The second is also in the same database feature, but here the processing that builds a cell's contents (genAVValueHTML) failed to properly escape any of four cell types: text, URL, phone, and attachment (mAsset) (GHSA-5xfx-xj4h-5p7r). Concretely, putting a string like </textarea><img src=x onerror="..."> into a cell lets the malicious program break out of its intended container (tag) and execute. Once an attacker with write permission plants it, the trap stays resident and fires on every device that opens that table, so the more people use a database, the more dangerous it is. On the Electron version it reaches all the way to takeover (RCE).

CVE-2026-54067: Even a "disabled" script runs from a look-changing CSS (CVSS 9.9)

The third is an issue in the processing that loads a "CSS snippet" for changing the app's look (renderSnippet()) (GHSA-mvjr-vv3c-w4qv). CSS is meant to specify only the look — colors, spacing, and so on — and is not supposed to run programs. But when SiYuan inserts the CSS contents into the screen (insertAdjacentHTML), it let the "closing" of the <style> tag that surrounds the CSS (</style>) pass through even when it was written inside the body. Abusing this, an attacker can pose as CSS, break out partway through with </style>, and then continue with a malicious program after it. The tricky part is that even if the user has chosen "disable script execution" in the settings, this path slips past it and still fires. The more someone has deliberately turned the feature off for safety, the easier they are to catch off guard, and on the Electron version it leads to takeover (RCE).

CVE-2026-55570: Takeover via a name planted in a marketplace listing card (CVSS 9.0)

The fourth is a flaw in the marketplace listing cards, directly continuous with the earlier Bazaar issues (GHSA-x88j-wgpr-h22x). The cards for packages lined up in the marketplace display the name, version, author, and description, but the processing that embeds these into the HTML parts was sloppy, and simply mixing a single quote (') into a package name was enough to break out of the intended container and inject arbitrary HTML. It fires the moment a user opens the marketplace and that listing is drawn. Because the Electron version has settings that let it call the computer's basic functions (nodeIntegration: true / contextIsolation: false), the display hole turns straight into a takeover. It is the only one of the four that requires the user to open the marketplace, so its severity is one notch lower at CVSS 9.0, but the danger is no different.

Why a "note app" leads all the way to takeover (the Electron settings)

What the earlier four, and the final stage of this MCP takeover, have in common is the settings of "Electron," the foundation SiYuan's desktop version is built on. Electron is a foundation that lets you build a desktop app in the web's way, and plenty of apps are built on it today. On the other hand, misconfigure it and you create the danger of "the contents of a web page being able to operate the computer." In these settings, SiYuan enabled nodeIntegration (true), which lets the screen call the computer's basic functions directly, and disabled contextIsolation (false), which separates the screen from the computer side.

With this combination, a program slipped into the screen can reach past the browser frame straight to the computer's command-execution functions (such as child_process). In the earlier Bazaar verification, a single line, require('child_process').exec(...), ran an arbitrary command. This MCP takeover, too, is completed when the program written into the plugin folder runs under these settings. The structure where a small display hole, or a write hole, leaps by way of the Electron settings to a full takeover of the computer (RCE) is common to this whole SiYuan series.

This "loose Electron settings turn a small hole straight into takeover" pattern is not unique to SiYuan; it is a weakness common to many apps that build desktop software with web technology. On this site we continually cover cases where a display hole turns into major damage, such as TinyMCE's stored XSS, where a small hole in the editor screen led straight to seizing administrator privileges, the DOM-based XSS in the AI agent AutoGPT, and a flaw in a sanitization library itself.

The first two: stored XSS in the "Bazaar" marketplace (CVE-2026-56395 / 56397, fixed in 3.6.1)

The series began with two issues reported in June 2026. The problem was in a feature bundled with SiYuan called the "Bazaar." It is an in-app marketplace where anyone can publish and distribute themes (looks) and plugins (added features). An attacker could plant a malicious program (script) — invisible to the eye — in the description text or introduction page (README) of a package they register in this marketplace. The cause of both was the same: when displaying a package's information on screen, the sanitization step that strips out malicious programs was missing (specifically, it called lute.New() without SetSanitize(true)). The report and verification are published in the developer's GitHub security advisory (GHSA-v3mg-9v85-fcm7).

CVE-2026-56395: Stored XSS via display name / description (CVSS 9.6, effectively zero-click)

The first is the issue where a malicious program planted in a package's "display name (displayName)" or "description" was used in building the screen without being sanitized. Because these are the basic information lined up in the marketplace listing, they can fire just from a user opening the Bazaar and looking at the package list. It is an effectively zero-click path that does not even require opening an introduction page. A published example of an attacker's package definition slips a contrivance like <img src=x onerror="..."> into the display name.

CVE-2026-56397: Stored XSS via introduction page (README) (CVSS 9.6, one-click)

The second is the issue where the contents of a package's introduction page (README) were displayed on screen without being sanitized. A README is meant to be explanatory text written in Markdown, but even if you mix raw HTML or scripts into it, they are not stripped and run as-is. This is a one-click path that fires the moment a user opens a package that caught their eye and views its introduction page. Both are the "stored" type, where the attack code is saved in the package information on the server side and affects everyone who opens it, so the damage spreads widely. These were closed in the fixed version 3.6.1, but preventing the five issues found afterward requires a newer version.

Status in Japan, exploitation observations, and EPSS

As of July 29, 2026, none of the seven issues, including this CVE-2026-66012, is registered as an individual alert with JVN (Japan's vulnerability database), JPCERT/CC, or IPA, and no Japanese-language reporting can be found. This article is the first detailed explanation in Japanese. Nor are any of the seven listed in the U.S. CISA "Known Exploited Vulnerabilities (KEV)" catalog of flaws actually being attacked (as of catalog version 2026.07.27). We keep the latest status of confirmed-exploited CVEs updated on our CISA KEV dashboard.

EPSS, the estimated probability of being attacked within the next 30 days, is about 0.4% for CVE-2026-66012 (as of July 28, 2026), which is not high at present. But because working proof-of-concept (PoC) code is public in the advisory, this value can change. In terms of scale, setups that stand SiYuan up on the internet with the Publish feature are not the majority. Even so, for the small number of operators who fit that configuration, the contents of CVSS 10.0 land directly on their environment. "Not many are affected, but for those who are, it is the worst" is the honest picture.

Summary

CVE-2026-66012 is a flaw where the "POST /mcp" receptacle SiYuan added for AI integration was missing the authorization check that verifies "whose instruction is this." When you run the Publish feature without a password, an unauthenticated remote attacker reaches the 31 tools through this receptacle, lifts the passphrase from the config file, writes a contrivance into the plugin folder, and ultimately takes over the computer. The severity is CVSS 10.0, exceeding the six existing issues this article has tracked. A fixed version, 3.7.2, is already available.

That said, remote exploitation is limited to setups that have the Publish feature enabled. If you use it alone on the desktop with the listening address limited to inside your own computer, a stranger cannot exploit it remotely. First check your own setup, and then update to 3.7.2 or later (ideally the latest stable release), which closes all seven issues in this article. As products that add AI-integration entry points proliferate, "can anyone touch that entry point?" will, in my view, become a checkpoint for those choosing products too.

Update history

References

• ▸ NVD - CVE-2026-66012 (missing authorization on the MCP endpoint)
• ▸ SiYuan Security Advisory - Unauthenticated Administrator takeover via the MCP (GHSA-cvhv-7xhj-xjp8)
• ▸ VulnCheck - SiYuan before v3.7.2 Unauthenticated Administrator Takeover via MCP
• ▸ NVD - CVE-2026-50551 (database attachment cell)
• ▸ NVD - CVE-2026-54158 (database cell rendering)
• ▸ NVD - CVE-2026-54067 (CSS snippet)
• ▸ NVD - CVE-2026-55570 (marketplace listing card)
• ▸ NVD - CVE-2026-56395 (display name / description)
• ▸ NVD - CVE-2026-56397 (README)
• ▸ siyuan-note/siyuan - Releases (3.7.2 and others)
• ▸ SiYuan Official Repository (GitHub)
• ▸ CISA - Known Exploited Vulnerabilities Catalog