GHSA-pqh8-4pj7-32xx: Critical severity npm/obsidian-tc vulnerability
Impact The Streamable HTTP transport was constructed without enableDnsRebindingProtection/allowedHosts/allowedOrigins and performed no Origin-header validation. With the documented auth.mode: "none" loopback default, a drive-by web page could POST http://127.0.0.1/mcp and receive caller http-local with scopes [""] — full vault read/write — via DNS rebinding / a forged Origin.
Patches Fixed in 1.3.1. Upgrade to >= 1.3.1. The transport now enables DNS-rebinding protection and allowed hosts/origins and returns HTTP 403 on an invalid Origin (per MCP 2025-11-25).
Workarounds Do not expose the HTTP transport with auth.mode: "none"; require JWT auth, or bind to a non-loopback interface behind a proxy that validates Origin.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/obsidian-tcto a version that resolves this vulnerability.Fixed in 1.3.1 - Upgrade
Upgrade
Streamable HTTP transportto a version that resolves this vulnerability.Fixed in 1.3.1 - Configuration
Do not expose the HTTP transport with auth.mode set to none; require JWT authentication.
HTTP transport auth.mode = JWT - Compensating control
If JWT authentication is not used, bind the HTTP transport to a non-loopback interface behind a proxy that validates the Origin header.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Instances using the Streamable HTTP transport with the documented loopback default and auth.mode set to "none" are exposed. In that configuration, a malicious web page can target the local MCP endpoint.
What does an attacker need to exploit it?
An attacker needs a victim to visit a drive-by web page capable of reaching http://127.0.0.1/mcp through DNS rebinding or a forged Origin. No authentication is required when auth.mode is "none".
What access could successful exploitation provide?
Successful exploitation can obtain the http-local caller with wildcard scopes ["*"], allowing full vault read and write access.
What should be done if upgrading is not immediately possible?
Do not expose the HTTP transport with auth.mode set to "none". Require JWT authentication, or bind to a non-loopback interface behind a proxy that validates the Origin header.
How does the fixed release block this attack?
Version 1.3.1 enables DNS-rebinding protection and configures allowed hosts and origins. It also returns HTTP 403 for an invalid Origin header.