On this page (7 sections)
obsidian-tc, an npm package that runs a Model Context Protocol (MCP) server for Obsidian vaults, shipped its HTTP transport without Host or Origin validation. In versions before 1.3.1, a malicious web page opened in your browser could talk to the local server and reach your notes. The maintainers fixed it in 1.3.1.
If you run obsidian-tc on a workstation, a shared dev box or a server, and especially if you followed the documented loopback setup with authentication off, you should check your version today. The GitHub advisory is the primary source for the details below.
What happened
obsidian-tc exposes an Obsidian vault to AI agents through MCP. Its Streamable HTTP transport was built without DNS-rebinding protection, without lists of allowed hosts or origins, and without any check of the Origin header. According to the advisory, the documented loopback default uses auth.mode set to none. In that setup, a web page could send a request to the local /mcp endpoint and be treated as the caller http-local with scopes of ["*"], which means full read and write access to the vault.
The advisory was first published on the project's repository on July 3, 2026. It reached the National Vulnerability Database and the GitHub Advisory Database on October 12 and October 23, 2026. The reporter is credited as suavecito585.
Why a local server can be attacked from a web page
Binding a service to 127.0.0.1 feels safe because other machines cannot connect. But your browser runs on that same machine and will happily make requests to it on behalf of any site you visit. Two things normally stop abuse: the server checks that the Host and Origin headers are expected, or it requires authentication.
DNS rebinding abuses the gap. An attacker-controlled domain first resolves to the attacker's server, then is re-pointed at 127.0.0.1. The browser still believes it is talking to the attacker's site, so its same-origin rules do not block the calls, while the request really lands on your local service. A forged or unchecked Origin has the same effect. With authentication off and no header validation, the local server cannot tell a legitimate agent from a hostile page. This is a drive-by risk: it needs a user to load a page, but no password, token or local access.
Who is realistically exposed
- Users running obsidian-tc below 1.3.1 with the HTTP transport enabled and auth.mode set to none (the documented loopback configuration).
- Teams that run the server on shared developer machines or remote desktops where a browser is also in use.
- Anyone who has stored sensitive material in the vault, since the access granted is read and write across the whole vault, not a single folder.
- The risk is lower if you use only a non-HTTP transport or already require JWT authentication, though upgrading is still the clean fix. The research does not describe those cases in detail, so verify your own configuration.
How to check your version
Run this from the project directory that depends on obsidian-tc. It lists the installed version of the package; anything below 1.3.1 is affected.
npm ls obsidian-tcIf you installed it globally, this lists the global version instead.
npm ls -g obsidian-tcThen review your server configuration. If it uses the HTTP transport and auth.mode is none, treat the instance as exposed until it is upgraded.
What to do now
The fix is to upgrade to 1.3.1 or later. According to the advisory, the transport now enables DNS-rebinding protection with allowed hosts and origins, and returns HTTP 403 on an invalid Origin, following the MCP 2025-11-25 specification.
npm install obsidian-tc@latestConfirm the result with npm ls obsidian-tc; it should report 1.3.1 or higher.
0 of 7 done
Detection and follow-up
The advisory does not describe indicators of compromise, and no exploitation is reported in the research, so there is no known signature to search for. Practical checks are to compare vault contents against a backup or version history, look for unexpected note edits or new files, and review any request logs your proxy or server keeps for /mcp calls with unfamiliar Origin values.
If you expose any tooling through a reverse proxy, a free security headers check and the guide on what a WAF does are useful background for validating what reaches your services. For internet-facing sites, regular security scans help catch exposed services, but they cannot see a loopback-only service on a personal machine.
Severity: why two scores
The sources disagree on the score. The GitHub advisory rates it Critical at 9.6, using a network attack vector, low complexity, no privileges, required user interaction and a changed scope. The CVE record in the research shows 8.8 (high). Both reflect the same flaw and the same fix. Plan around the higher rating, since a full read and write of a vault is a serious outcome and the patch is simple.
Note that only one independent publisher, the project's own advisory channel on GitHub, covers this story so far, so details may be refined. Check the project release notes for updates.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.